Quantity is No Measure of Maturity
As companies pursue the benefits of Service-Oriented Architecture (SOA), it makes sense that organizations want to measure their progress against an objective benchmark. After all, since SOA represents changes in the way that IT meets the continuously changing requirements of the business as well as changes in the way that IT organizations are managed and governed, it makes sense that companies want to grasp something tangible and concrete to gauge their progress. This is where vendors, analysts, consulting firms, and marketers have all piled on with their measures of SOA maturity.
As ZapThink wrote earlier in What To Look For in a Maturity Model, many of the existing SOA Maturity Models are self-serving, vendor-driven efforts that aim to mature a company’s purchase of products moreso than the evolution of their architectures. However, we also stated that some combination of the various efforts can yield some benefit in trying to understand the dimensions that an organization should consider when maturing their SOA implementation. Yet, in the eighteen months since we wrote that ZapFlash, we have seen, with much dismay, that companies are solely using the number of Services created or managed as a measure of maturity. That is, having thousands of Services means you are more mature than if you had just one. Of course, this is a patently false observation.
The One Service You Care About vs. the Thousands You Don’t
One easy explanation as to why the number of Services created, managed, or consumed has no bearing on maturity, is that creating Services is a trivial exercise. Indeed, there are now a number of tools on the market that can expose thousands of Service interfaces on top of existing application logic, databases, middleware infrastructure, and even hardware network devices. To further reinforce this point, one can take an extreme view that exposing a Service is actually worthless. It’s when something consumes that Service that value is created. In other words, a thousand services that have few or no consumers is worth much less than one Service with a thousand or more consumers. The value proposition for SOA is focused not on the exposure, but rather the consumption of Services.
Now, this doesn’t mean that a Service has to be reused in different process contexts to have value. In the ZapFlash Should All Services be Reusable? we discussed that there are many reasons to consume a Service, of which reuse is just one. However, there must be at least one consumer to give the Service any value at all.
So, in this environment in which Service creation is a trivial and relatively low-value exercise, the primary concern is how to make Services more easily, reliably, and flexibly consumable. Therefore, even if a company has just one Service they care about, if it’s reliable, consumable, and agile in the face of continuous change, then this one Service and the architecture that is oriented towards that Service has a high degree of maturity. However, if the one Service is treated with lack of quality, governance, and control just because it is a singleton, a company has missed the point entirely of the benefit of SOA. Companies should mature the Services that are the most important to them regardless of how many they have. To assume that quantity governs the progression of maturity sets up an organization for potential disaster.
Measuring Architectural Maturity
One indication that companies are inappropriately thinking about maturity is that they are considering issues of quality, governance, lifecycle, and reliability too late in the architectural process. Exposing a Service is one step in the lifecycle of SOA development, but it is not even the first step. Indeed, the step companies take to expose and execute Services should be one of the last they take as part of a mature architectural process. Quality, in particular, should be considered before any Services are created. If a company has not considered how Services will be tested, how consumers will reliably succeed or fail in their Service consumption, and how they will iterate through Service versions, then any consumers that bind to those initial Services will be doing so at their own peril.
Likewise, governance must be a consideration early in the SOA design process. How can companies make sure that Services will be exposed and consumed according to the requirements of the business and government and not go off into the weeds. As we’ve discussed numerous times, SOA projects without governance can result in chaotic systems where no one knows exactly how Services are being consumed or exposed within the organization. Businesses hate chaos, and they will quickly put an end to chaotic SOA efforts. In this vein, ZapThink always recommends to its advisee clients to implement a registry/repository and metadata management system as one of its first SOA activities. By having a place to collect and manage the metadata of the organization, organizations can avoid simple systems becoming complex and unwieldy over time.
Another element of maturity to consider is that of security and reliability. Just because a company might expose one Service to its customers or partners does not mean that it should be any less secure or reliable than a much larger quantity. Indeed, if that one service is the sole way in which a company interacts with its customers, then any compromise of that Service’s ability to provide reliable and secure interaction can compromise the value of the entire effort. While this seems to make sense, we can’t tell you how many times we’ve seen customers exposing Services into an environment where they’ve decided to “expose first, secure later”. Just as with quality and governance, mature SOA organizations consider reliability and security before they’ve exposed their first Service.
So, one way to measure the maturity of SOA efforts is to measure the maturity of the quality, governance, security, and lifecycle efforts that apply to any number of Services in the environment — even if there is just one Service that provides value. As such, quantity has no relevance to the maturity of the organizational efforts. Yet, these technological aspects of SOA are but a small part of an organization’s overall SOA maturity. Doing governance, quality, reliability, and change management in a Service-oriented way changes the very way in which the IT organization operates. How companies manage their organizational adoption of SOA measures just as much of their maturity as their adoption of architectural best practices.
Measuring Organizational Maturity
As an organization shifts their focus from merely producing Services to consuming them, they start to notice that their existing organizational and management structures are no longer effective. In particular, the IT organization might have been aligned in silos oriented towards the particular systems or processes that existed in a tightly coupled, non-composable, and certainly non Service-oriented world. Yet, reuse in an environment of continuous change and heterogeneity as well as a different approach to quality, Service lifecycle, and governance demand a very different organizational structure.
As companies mature their Services and architecture, they will necessarily have to mature their organizations, This means that they might create SOA Centers of Excellence, EA Teams, and Competency Centers centralized or federated throughout the organization that can help guide and institutionalize SOA best practices, manage the growing consumption of Services (even if the quantity of Services exposed remains the same), and maintain effective corporate and IT governance with and of SOA.
As such, even if a company has just one Service that they care about, the consumption and iteration of increased quality and reliability of that Service will necessarily require organizational change that will mandate top-down as well as bottom-up styles of Service-orientation, iterative styles of development and Service lifecycle management, and the ability to continually build and prove the business case of the Services they consume. Just as quantity of Services doesn’t matter here, neither does the need to have a “big bang” SOA project. Even if an organization focuses on a small set of Services deployed for a particular set of processes or individual departments, they can mature their organizational and architectural approaches to squeeze the maximum value out of their efforts, even if they don’t spread to the rest of the company. There’s no need for “Enterprise-wide SOA” just for the sake of achieving so-called highest levels of maturity. Focusing on a problem and maturing the organization to get the most value out of a Service-oriented solution is as much maturity as is necessary.
The ZapThink Take
Maturity is measured against one’s self, not others. That is to say, there’s no external measure that a company must jump in order to consider one’s own SOA initiatives to be “most mature”. Rather, companies need to understand that the quantity of Services or enterprise-wide nature of their SOA efforts has little bearing on the importance and value that the Services they consume bring to the organization. Focusing on a multi-faceted approach to maturity that considers the architectural and organizational as well as the technological will help companies mature their SOA so that it brings the most benefit to their businesses — and this is the only maturity that matters.
While we are hopeful that companies will consider the deeper issues of architectural and organizational maturity in their SOA projects, we know that the lure of simple, if inadequate, maturity models will always be compelling to organizations that seek the quick fix that they hope SOA will be. Unfortunately, SOA is rarely a quick fix for organizations that struggle with chronic architectural challenges. Just as ZapThink recommends an iterative, ongoing approach to Service-orientation that considers the business problems that are most appropriately solved by SOA, so too does ZapThink recommend a step-wise approach to SOA maturity that considers not the quantity, but rather the quality of the Services an organization chooses to consume and expose.