If you had to pick a single business benefit that service-oriented architecture (SOA) can provide, it is the ability to respond to change. Change occurs continually in a multitude of places that affect the enterprise: the market, the supply chain, strategic processes, regulations, and so forth. SOA can enable the creation of an agile environment that creates stability in the face of change because it restructures automated functions into reusable pieces that can be quickly reconfigured into new or modified processes.
But an architectural approach alone will not create agility. Agility comes from having the right pieces from which agile processes can be assembled. Developing, refactoring, or acquiring the right services requires a deep understanding of your business.
Over the past few decades, many models have evolved to push automation toward agility. Simple mainframe applications gave way to numerous integrated processes running in central mainframe - enabling libraries of functions. Client/server and later multi-layered systems began to allow for more targeted replacements or upgrades - so-called "separation of concerns" - the hallmark of agility.
Those advances in agile technology, however, were often offset in the operations center by the introduction of multiple disparate systems, each somewhat agile in its own way, but not designed to operate together in an "agile enterprise." Business drivers such as mergers and acquisitions often brought together systems whose designers had no vision of such cross-enterprise interoperability, or, worse, whose vendors had no motivation to create an integrated system responsive to changing requirements. While Enterprise Integration suites very successfully addressed many challenges, the basic approach of integrating individual and disparate interfaces is inherently expensive and brittle.
SOA ushers in nearly a perfect storm for agility, enabled by standardized best practices, pervasive communication and data protocols, and a general movement toward "openness" in the industry. Best practices have emerged from enterprise integration efforts and other advances such as object-oriented approaches. The Internet has made the plumbing necessary for integration ubiquitous and well understood. Openness has come both from the demands of customers as well as the "disruptive" open source and open information movements.
Why nearly a perfect storm? Because like all the previous technologies, SOA is only an enabler. Without a deep understanding of today's processes and a general sense of how they are likely to change, the inability to choose the right components prevents the storm of agility from forming completely.
SOA is about how - but a true business plan using SOA really needs to start with what. Simply put, without a clear understanding of the "what," the "how" becomes nearly irrelevant.
What exists to guide the application of these new architectural approaches and underlying technologies? What prevents SOA practitioners from simply rearranging the pieces without really achieving SOA's promised agility and alignment with business objectives? What ensures that the pieces are not rearranged into "an SOA" without producing significant benefits?
There has been a lot of discussion in the SOA literature about the importance of governance, but this too is more about the "how" than the "what." Design-time governance, for example, supports the reuse of components, which is a critical piece of SOA adoption (why pay to make something reusable if no one is able or compelled to reuse it?). But this says little about the process of determining what is being reused. Again, the prerequisite to success seems to be a model that guides the selection or creation of components that truly enable agility - components that can be called upon to support new or changing higher-level business processes.
There is also a lot of discussion about whether SOA should be adopted from the top down or the bottom up. Both approaches have clear advantages and challenges. While top-down can "feel right" because it's based on planning and thoughtful investigation, it can become overly prescriptive and mired in "analysis paralysis" - sometimes to the point where requirements and even technologies are changing out from under the plan.
The bottom-up approach enables a quick start, is often driven by enthusiasm for new technical possibilities, and has the benefits of an "organic" methodology. However, it can also lead to gold-plated components that are never reused or disorganized collections of services that might adhere to service-enabled principles on a small scale, but which collectively fail to provide the right mix to truly enable agility and realignment with business processes.
A "meet in the middle" strategy can provide the best of both worlds. Understanding top-down business objectives and decomposing them and the processes that support them is clearly the most controlled and planned approach. But "the best-laid plans..." wisdom supports the idea of bottoms-up, where getting started and refactoring along the way allows progress to benefit from the lessons learned as well as supporting finer-grained adjustments to account for changing priorities, requirements, and technologies.
The "meet in the middle" approach often has the time benefit of supporting parallel development efforts, because top and bottom often represent different organizations and disciplines. But therein lies the challenge. Two teams digging a tunnel to "meet in the middle" need to understand quite precisely how one side will connect to the other. Left to chance, there is very little possibility that this will happen.
A comprehensive and layered set of models representing current and desired states, sometimes referred to as a blueprint, supports "meet in the middle" quite effectively. That approach requires clear traceability from the top to the bottom, and the blueprint provides it. Development of such a blueprint will iteratively enable "the big picture" to be evolved to its maximum benefit while enabling progress in parallel on obvious infrastructure and process requirements.
It is common advice from SOA practitioners to establish a proof-of-concept that has significant visibility to keep attention and funding, but with simple enough requirements to ensure an initial success. Adoption of such an approach within the framework of an iteratively developed blueprint allows exploration with traceability from business objectives down to the infrastructure that helps realize them. Do enough top-level modeling and definition to establish a foundation and identify key processes for early development, but get started quickly with the development to gather experience to continue to the next steps, well informed and confident.
Because a blueprint provides traceability, it shows what requirements you were satisfying with the current implementation or proof of concept. It becomes a plan that captures changes in each step toward an enterprise based on SOA and containing the right components to maximize agility. A blueprint creates a common language and defined touch-points between the business architect working at the top and the systems architect working from the bottom. A blueprint supports a plan to ensure that they truly "meet in the middle."
In essence, a blueprint is a "paper copy" of some or all of the enterprise - in fact, because it is activated by software tools, it might more properly be called a digital model. In a blueprinting approach, governance becomes the controls and communication structure necessary to turn the "copy" into reality. Planning lays out the schedules and resources to address the gap analysis between "as is" models and "to be" models within the blueprint.
Because of the traceability between the "layers" of the blueprint, prioritized business objectives help identify the business processes that require change, which in turn point to the underlying automation and components involved, which then identify any needed infrastructure changes. It is easy to see that with a blueprint, projects can be prioritized based on scope, ROI, resource availability, or other factors not directly driven by the architecture and technologies. Execution of the plan can occur in parallel with the expectation that all the interdependent pieces are available on schedule. IT aligns with business goals.
A blueprint and the traceability it includes have a direct impact on ensuring that the right reusable pieces are produced. Continual requirements gathering coupled with prioritization facilitates the right discussions around which components really will provide the maximum ROI. Like change, requirements come from all over the enterprise. An inventory of existing components and processes, sometimes referred to as the "as is" model, helps establish the current state of the enterprise. This enables tools such as maturity models to be applied as part of the gap analysis referred to earlier to couple goals with needed changes.
A blueprint will expose business process patterns that also can be reused, making the subsequent iterations of the blueprint and development easier with faster return and less risk. The blueprint business objectives guide your architecture while identifying business processes, and the patterns within them guide the design and priority of components. Existing assets identified in "as is" models can be examined against modeled processes to determine if they need to be refactored to support the "to be" states.
While SOA is an architectural approach, it typically resides in the technical domain. A major positive impact of the SOA movement has been the acknowledgement that what affects business affects IT and, conversely, what affects IT affects business. Many maturity models now include dimensions such as organization and funding. With an emphasis on reuse, there must be consideration of the organization and funding that support development, purchasing, and support of reusable components. This is a different model than siloed organizations using siloed applications.
While some organizations with centralized IT may be well positioned to follow this model, other organizations with more distributed structures face additional challenges. Often public sector organizations are distributed based on the services they provide, e.g., law enforcement and court administration. A blueprint has the capability to identify these potential adoption challenges and integrate the functions. For example, an integrated justice information system based on a blueprint can help police learn about outstanding warrants in different jurisdictions, and that can make it easier to prevent crimes by identifying offenders more readily.
By bridging various horizontal disciplines, a blueprint helps expose the gaps between vertical interests while creating an opening to reduce risks and capitalize on opportunities.
How Do You Measure Success?
It would be easy to look at the architectural diagrams of an IT infrastructure, count the number of Web services that were developed, look at how many are reused, and declare your SOA journey a success. Perhaps from a technical perspective it has been a success. But the real measure of success is the increasing ease of executing the next iteration from your blueprint. That is true agility.
It becomes easier because you are recognizing patterns in your processes. It is easier because you find that, from the previous iteration, you increasingly have the right component services in your arsenal. It is easier because you are positioned to understand how to purchase and integrate services you need. It is easier because you invested in externalizing the business logic for processes you anticipated changing and now those new requirements can be achieved without recoding. If it's not getting faster and easier, you may have adhered to the technical design principles, but are likely missing the real return promised by the SOA enabler.
A blueprint provides a foundation to get started, objectives on which to structure an iterative plan, and a basis against which to measure success at the business level. It provides a foundation against which all the elements of SOA adoption can be applied: technologies, governance, and iterative improvement.
You probably could evolve your enterprise to SOA without a blueprint, but it would be like attempting to build a house without its architectural equivalent. You may end up with a kind of Winchester Mystery house - many years of construction, lots of nice but unrelated features, staircases that lead nowhere, and lots of features based on superstition due to bad or misunderstood premises and assumptions.
© 2008 SYS-CON Media Inc.