Service oriented architecture (SOA) is going to save us all. We all know the drill: Faster time-to-market. Lower total cost of ownership. Loose coupling makes integrating or re-wiring existing capabilities faster and adding new features easier.
Except that in most large companies, just doing SOA doesn’t do any of these things. In reality, sub-optimal time-to-market and high operational costs are caused by many factors; older approaches to system integration is just one them. While an SOA approach certainly helps, it isn’t a silver bullet. It’s easy for technologists to get caught up in the promise of SOA as a solution to common IT challenges. Even active SOA practitioners in growing companies believe – with good reason – that their existing SOA approach will scale with growth. Most large companies have one or more of the following constraining factors that will limit the success of narrowly focused SOA initiatives:
- A lack of maturity with governing shared technology services.
- Project management methodologies and software development processes that are based on waterfall approaches to building software and usually highly dependent on integrated testing.
- Legacy systems that are difficult to service enable simultaneously.
- Infrastructure delivery constraints that make adding or changing hardware time-consuming.
- Testing methodologies that do not take advantage of a highly service-oriented environment.
- Technology solutions that require a mixture of technology platforms with varying capabilities for development methodologies (e.g. waterfall vs. agile) supporting many different projects within the organization.
It is very difficult for SOA to deliver on its promises when one or more of these conditions exist with an organization. Furthermore, changing these conditions while also trying to become more service oriented can add time and cost to the effort. If the stakeholders and sponsors of an SOA initiative have unrealistic expectations about the process, these added wrinkles can result in an otherwise beneficial project being canceled.
While most companies have already jumped on some form of the SOA bandwagon, many are not realizing the benefits because these fundamental challenges have not been addressed or even considered. What most companies really want from SOA is a flexible IT environment. To achieve this flexibility, more than SOA is needed.
I’ll explore each of these in more detail over a series of blog posts, beginning today with governance.
Lack of Maturity in Governing Shared Technology Services
Consider the problem that SOA intends to solve: proliferation of varying technologies implementing different standards that make integrating and changing these “solutions” slow and difficult. The intent of SOA is to decouple service consumers from service providers, abstract knowledge of the implementation of the service from the service’s consumers, and provide common methods for interacting between consumers and providers. In doing so, SOA must be (or become) a shared service to the entire organization, not something individual SOA practitioners create in silos.
Unfortunately, implementing SOA without an SOA governance program just recreates the original problem. A practical, pragmatic approach to governance solves problems like:
- Setting a direction for how services are implemented. Should services be built using SOAP or RESTful implementations? If SOAP is used, what WS-* standards are all service providers and consumers expected to support? Can service providers assume all consumers will implement WS-Security? For either SOAP or RESTful implementations, even basic questions like the use of HTTP vs. HTTPS can create road-blocks to adoption.
- Standardizing schemas, data and message formats. The whole point of SOA is to enable a variety of service providers to expose their operations in a common way. While SOAP/XML and REST provide a mechanism to do this, message format differences can be a significant barrier to reuse. Consider the following:
- Service Provider A implements a complex type called “Address” that has one address line, a city, state and five-digit zipcode
- Service Provider B implements the same complex type using two address lines, a city, state/province, ten-byte alphanumeric postal code, and country code
- Service Provider C provides a service that relies on both service providers A and B to operate on data including addresses
- Integrating these “service oriented” applications is no easier than if we were trying to do an EDI integration or a CORBA integration or a COM+ integration or a COBOL integration; in fact, it may even be worse because the business partners may believe that SOA should’ve fixed this problem.
- Ensuring consistent service/operation packaging and granularity. Consider a an example similar to the one above, except now service providers vary widely in the granularity of the services or operations they provide. One provider always operates on a “customer” entity (encompassing all attributes of the customer) while another always operates on individual customer entity attributes. Again, the reuse of SOA services is undone because the services are incompatible in implementation.
- Preventing duplicate or overlapping services from being created. Yet another variation on the above theme: two service providers create very similar services. The differences between the two may be something as simple as performing an update to some customer data, but the service providers have one or two fields that differ between the interfaces. Why maintain two heavily overlapping service? In most cases, one service should exist and simply be enhanced to add the missing fields.
SOA governance can not and should not be draconian. The objective of governance is not to implement rules from an ivory tower or deliberate on academic issues of building systems using SOA techniques. Good SOA governance can be measure by how well it promotes service reuse, how much (or little) service duplication exists, and how time-to-market for projects using shared services trends over time (SOA is a long-term investment). Practical SOA governance comes in the form of:
- Reasonable, attainable standards with respect to how services are implemented:
- SOAP vs. REST
- Practical use of WS-* standards where they add value
- Common and consistent schemas
- A system of incentives for compliance with governance policies
- A system of record (like a UDDI registry/repository) for recording which services exist and who consumes them
- Agreed upon metrics and goals that quantify the quality of the governance system and the compliance of services
- Sponsorship from technology and business leadership that governance is important
I’ll continue to explore the other constraining factors in future blog posts and how to address them. While the challenges are significant, successfully meeting those challenges enables organization to realize the full potential of SOA.
