SOA + Information Architecture = Code Reuse (Finally!)
Before the Industrial Revolution, virtually every human work product was handmade and crafted by artisans — clothing, vehicles, buildings, anything people consumed. Then came the Revolution, ushering in mass production, which changed the fundamental economics of manufacturing and consumption forever. Software, on the other hand, is still essentially handmade to this day, where every piece is crafted by an IT “artisan” to fit a specific need. And so, software has so far failed to provide the same revolutionary economics to IT that the Industrial Revolution provided for manufactured goods. Now, while mass production of software may still be a ways off, the ability to reuse pieces of software is in our grasp, providing at least a glimmer of the profound economic benefits that mass-produced software could provide.
Code Reuse: A Holy Grail?
Code reuse has long been one of the holy grails of software development. Writing code once and using it many times is an obvious way to save money and reduce risk, according to conventional wisdom. In practice, however, writing reusable code can be far more challenging to the developer than writing code for a single-use application. There are three main problems with attempting to write reusable code:
- Writing reusable code takes more time than writing single use code — the developer must think through how to generalize each feature in order to optimize the reusability of the code.
- There is no guarantee that the code produced will actually be reusable — in many cases, the initial set of assumptions fails to meet the ongoing needs for that software functionality, or it may simply be the case that nobody will have the desire to reuse the code.
- Coding for reusability poses a problem in that the developer is coding beyond specific customer requirements — just how general should the developer make the functionality? How does the developer know when to stop coding?
One increasingly popular development approach shuns attempting to code for reusability in favor of coding only what the user actually needs at the time. If extraneous functionality creeps in, then developers refactor the code. When developers refactor, they streamline the code until it is general enough to handle all the cases where there was redundant code before. In essence, refactoring means building for a kind of reuse, because the final code addresses multiple situations. However, refactoring is different from traditional coding for reusability, because its aim is to create code that is flexible and broadly applicable, rather than generalizing the functionality of the code in the absence of a current user requirement.
Refactoring makes a lot of sense when building Web Services that will be exposed in a Service-oriented architecture (SOA). In an SOA, developers should construct the Services to be as simple as possible, where they refactor them so that they are as broadly applicable as is practical. The resulting services are then reusable at runtime — nuggets of software functionality (both fine- and coarse-grained) that can be used in a variety of situations, as contrasted to trying to solve the issue of reuse at design-time. An important result of this principle is that Web Services should be “right grained” — that is, of the appropriate level of granularity. Generally speaking, in an SOA, fine-grained, atomic Services should be composed into coarse-grained, business Services, but in practice, different Services should have different levels of granularity depending upon their functionality.
There is an additional, related concept to broad applicability that goes even further: the concept of consumability. It’s not enough for a Service to have the potential to be used in a variety of situations, it must actually be usable. Not only must the Service’s functionality be technically applicable to various situations, but people must know about the Service, understand its use, and be able to find it when they need it. Consumability and broad applicability, therefore, combine technical concepts of reuse with human concepts. For example, standardizing semantic rules and interface guidelines for accessing Services in the enterprise is a technical approach for facilitating broad applicability, while implementing a knowledge management solution that provides user education on available Services is a human-oriented technique for promoting consumability. Software asset management tools that facilitate the sharing of the artifacts associated with an SOA (WSDL files, Service models, etc.) are also essential for promoting consumability. In addition, tools that can identify and flag Service dependencies also can facilitate the identification of Services that are being consumed, and thus capable of being refactored to be even more broadly applicable.
Getting Started with Reusable Web Services: Get the Information Architect Involved
Building Web Services to be broadly applicable and consumable is clearly one of the key efficiencies that lead to the overall value proposition for SOAs, but that doesn’t mean that it’s easy to build such Services. In fact, in many ways, figuring out the specifics of the Services an enterprise needs is where the real work of SOA implementation occurs. In order to make the correct decisions on issues of granularity, data formats, Service naming, delivery contracts, and the like, a company must first understand how they use and access information in their organization, and how that information flows among people and technology. By understanding the flow of information, companies can begin to specify the Services they will need.
Fortunately, many organizations already have professionals on staff who are experts in understanding the use and flow of information: information architects. Information architecture is one of the lesser understood architectural disciplines, having been brought out of obscurity by the rise of the Web. In the 90’s, information architects were called upon to plan Web pages and Web sites, leveraging their understanding of how companies use and move information to build user interfaces on the Web.
Web Services and SOAs have just raised the stakes for the information architect. All the user interface issues that formed the core of the information architect’s daily work still remain, but now they must also apply their skills to the planning and organization of Web Services. Web Services don’t generally have user interfaces, but they do have contracted interfaces — that is, to plan a Service, it’s important to create the contract that describes what that Service does and how it’s supposed to be used. The information architect is often the best person to decide on the details of these Service contracts. The information architect, therefore, must leverage their core capabilities to make the following decisions:
- What are the core enterprise business Services a company needs, what do they do, and what are they called?
- How granular should each Service be?
- As companies compose business Services into Service-oriented business processes, which Services are the starting point, and which Services should be composed of other Services?
- What are the rules governing the data provided by each Service? The answer may involve industry standard schemas, schemas proprietary to the organization, or conceivably data rules expressed in some other format.
- Which consumers should access which Services? How will the organization understand how to regulate the consumption of the Services? How will the organization specify the Service delivery contracts?
The key take-away from this article is that the best approach to answering these questions is to consider how the organization uses and moves information. Only by using the principles of information architecture can companies have a shot at building an SOA that meets business needs. Otherwise, the IT staff is working in the dark, without a clear understanding of what the behavior of their Web Services should be. And without that understanding, the company risks losing the core reusability and agility benefits of Web Services, resulting in tightly coupled, inflexible architectures that are scant improvement over the architectural approaches that came before. On the other hand, if a company gets the information architecture of their Web Services right, they will have broadly applicable, consumable Services that finally yield the long-promised economic benefits of code reuse.