Smart companies approach all IT investment decisions with a three-part question: should they buy, build, or repurpose their IT resources to meet their emerging business needs? Such fundamental investment questions apply to all aspects of IT, ranging from network devices to application software to professional services needs. As a result, the same thought processes apply to burgeoning implementations of Service-Oriented Architecture (SOA).
However, one of the significant shifts in thinking that SOA introduces is the notion that business logic is not engrained in programming code, but rather in the declarative metadata that describes a Service and how it interacts with other Services. In essence, SOA advocates a movement away from code-centric development to configuration-centric composition. This shift to metadata-driven development introduces new challenges to how organizations purchase, repurpose, or develop Services. Rather than dealing with traditional development lifecycles, companies must now understand how to continually iterate the development of their Services and therefore, their Service metadata as well. Just as companies have the choice of developing applications in-house or purchasing their IT assets from third parties, so too they must they resolve the issue of whether to create and maintain their Services and associated metadata themselves, repurpose them from existing assets, or purchase them from third party suppliers.
Building Services from Scratch
When faced with an SOA mandate, the first thing that most IT departments feel compelled to do is to start developing Service interfaces for their existing legacy systems. But what does it mean to “develop a Service”? There are actually two different sorts of assets developers must deal with when building Services in an SOA: the application logic that underlies a Service interface, and the Service metadata themselves.
Application logic development that underlies a Service is much the same as it has always been, with one key difference: developers should not hard-code business process or any other business logic into the application, but rather leave them for the metadata to handle. In an SOA implementation, security, reliability, and transport binding considerations should likewise be relegated to the Service interface and policy contracts that surround a Service, rather than to its underlying code. As such, the real kernel of functionality that remains abstracted beneath the Service interface simply provides the implementation that guarantees the service level agreed to in the Service contract.
Most importantly, companies should realize that putting Service interfaces in front of existing application logic is not all that challenging. Since adding Service interfaces to legacy systems is straightforward, the real development work comes from defining Service contracts and creating the process, security, management, and other metadata that sit on top of the Services themselves. Furthermore, this approach to Service development is only applicable for fine-grained Services where it’s easy to control the functionality and scope of change for those Services. Simply wrapping legacy systems with Service interfaces is not sufficient for coarse-grained business Services.
As such, building business Services “from scratch” really means coming up with the policies and other metadata that govern how the Services work. In this context, it makes more sense to build such Services in-house than to source them from third parties. While it’s possible to purchase the underlying code that makes the Service work, it’s hard to make the same case for Service metadata. Therefore, while companies might be able to buy fine-grained Services from third-party providers, they should look to build their own Service metadata and composite, coarse-grained business Services.
One of the major tenets of SOA is that companies should reuse Services as broadly as possible to support their growing and changing set of business requirements. As such, companies should expect their investment in Services to gradually shift over time from Service exposure and fine-grained development to composition focused on Service reuse. Rather than spending time and money trying to figure out which new Services to build, companies should focus their efforts and resources identifying existing Services in the enterprise, composing them into new processes, and refactoring them as necessary to support new capabilities.
Thus, the significant question that companies will be forced to grapple with is which Services to build from scratch and which to repurpose to meet changing needs. The answer to this question depends upon the particular circumstances of the business and the scope of their existing Services. Furthermore, many of the fine-grained Services that companies will have in the early days of their SOA projects will not be amenable to much refactoring, since they might come from pre-packaged enterprise application suites or simple extensions of legacy APIs.
That said, companies that have properly defined their Services in a top-down fashion by starting with an overall architectural plan, rather than building their SOA from the bottom up by building fine-grained Services as legacy wrappers will be better able to repurpose and refactor their Services for new capabilities. Therefore, companies that develop process-driven, coarse-grained, composite Services will find greater flexibility and ability to extract continuing value from their Service investments. On the other hand, companies that fail to move beyond fine-grained Services may hardly even get the chance to think about repurposing their Services, let alone do so successfully.
Of course, Service metadata that define security, policy, reliability and declarative business logic for interacting with Services should be amenable to repurposing. Companies should try their hardest to create Service metadata once and repurpose them as many times as possible to meet ever-changing business requirements. As such, the real development effort here is not one of creating Services from scratch, but rather developing from the start the most agile, flexible Services that can be repurposed to meet new needs.
If companies can repurpose Services, then they can also purchase them from third parties, as a logical extension of the basic ability to reuse Services. In many cases, companies may find that the Services they are using the most do indeed come from IT suppliers, rather than their own development shops. For example, enterprise application vendors are increasingly providing fine-grained Services for consumption in corporate SOA implementations. However, a business-centric, process-driven SOA composes these fine-grained Services with other Services that may or may not come from that technology supplier. As such, even in situations where the bulk of the Services might come from a third-party vendor, the business logic itself should be in the composite metadata, which the company most likely develops from scratch in-house.
The forward-looking question is whether companies will purchase composite, coarse-grained Services from third-party vendors. This question actually doesn’t have anything to do with technology, but rather is one of business process outsourcing. Buying a business-focused Service from a third-party vendor should be the same thing as outsourcing an entire business process to that vendor. The Service would have to be at such a level of granularity that the actual implementation and process details are abstracted from the consumer, and therefore, would appear to be a process the company outsources in its entirety. As a result, companies looking at purchasing coarse-grained Services must first think about whether or not they want that process outsourced.
While a third party can readily supply the underlying implementation of a Service can be readily supplied by a third-party, it’s not clear what sort of metadata can realistically be purchased from a third-party supplier. Every company’s security, reliability, process, and management criteria will differ significantly, and as such, the most that a company can expect from a vendor are technologies for managing metadata or tools to simplify their creation. Therefore, the purchasing decision for Services is only relevant for either fine-grained Services or for processes that are outsourced in their entirety.
The ZapThink Take
In reality, most companies will find that they have to adopt a hybrid of all of the above approaches for their Service development and maintenance. Existing technology vendors will pre-package a wide variety of Services that a company will use, while other Services will emerge when companies extend their legacy systems using in-house resources. As companies devote more effort to developing Services, it’s clear that the one thing companies will need most of all is a corporate memory for how they create and evolve their Services over time.
In an SOA world, it isn’t sufficient for companies to make point decisions about the Services they build, buy, or repurpose. Rather, they must think of the architecture as a whole and how its implementation will evolve over time. Some Services are more economical to build in-house , not necessarily the first time around, but as they are repurposed for future activities. Likewise, outsourcing certain Services may be economical only in the long run. As such, the decision to buy, build, or repurpose must also be capable of evolving as the business changes.