Related Topics: MultiTouch Developer Journal, SOA & WOA Magazine

Multi-Touch: Article

SOA World Feature: SOA as a Business Strategy

Agility is the name of the game

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.

More Stories By Anthony Gold

Anthony Gold is vice president and general manager, Open Source Business, Unisys Corporation. He is also a board member on the Open Solutions Alliance (OSA). He serves as a business consultant for several startups in the Philadelphia region and is writing a book on how businesses can transform themselves leveraging open standards and services-oriented architectures. Anthony graduated from Drexel University with a bachelor of science in electrical engineering.

More Stories By James Irwin

James Irwin is an open source software architect at Unisys Corporation. He has degrees and work experience in both the computer science and psychology fields.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.