6 | 2007

"If we accept that SOA is the royal road to better alignment between business and IT, we must face the question: exactly how will this alignment come about?"

-- Tom Welsh, Guest Editor

Automated Management

A successful SOA initiative soon brings forth dozens, or even hundreds, of services. No human being can possibly keep track of how all these are working. SOA governance requires powerful suites of tools to monitor, record, and analyze service traffic in order to identify bottlenecks, clashes, and dependencies before they cause serious problems.

A Meeting of Minds

SOA involves an apparent contradiction. Services can only be implemented bottom-up by developers, but they must be specified and fine-tuned top-down by business professionals. The only solution is to place an intelligent layer in the middle to reconcile technical means with business ends. That intelligent layer is SOA governance.

Opening Statement

Service-oriented architecture (SOA) has been the hottest topic in software for the past two or three years, and it looks as though it will continue to enjoy that status for some time to come. Like Java, XML, and Web services, it has attained buzzword superstardom -- membership in that select clique of terms that seem fated to be continuously analyzed and debated by analysts, bloggers, and the media. Under the circumstances, software vendors have naturally hastened to talk up their products' potential contribution to SOA success.

Unlike most innovative ideas, however, SOA is deemed to be of immediate and pressing interest to business decision makers, from CxOs on down. This is because (in spite of its name) it is not just another software architecture, but a new and powerful way of reorganizing business enterprises. The theory is that, with SOA, all corporate software applications are decomposed into logically related groups of services. Each department or division -- HR, finance, marketing, purchasing, and so on -- takes responsibility for creating and maintaining those services that implement its business activities.

With the advent of SOA, it is harder to consign all technical questions to the IT department and leave it to work away in isolation. Indeed, this should theoretically be impossible, as services cannot be properly designed or administered without substantial input from the relevant business groups.

SOA is intrinsically distributed, whether network-wide within an enterprise or reaching out beyond the firewall to embrace external partners, suppliers, and even customers. Moreover, SOA experts stress the importance of breaking up the monolithic control that central IT has usually exercised over corporate computing in order to put separate divisions, lines of business, and departments in charge of their own services. For these reasons, together with its strategic nature and the size of the investments likely to be required, SOA is believed to encourage convergence between business and IT planning.

Thus, SOA is deeply linked with enterprise architecture (EA) and governance. Indeed, it could be seen as the answer to an enterprise architect's dream, as it comes complete with answers to many knotty questions that would otherwise have to be worked out ad hoc. If you have a robust, viable SOA that is capable of growing in response to corporate business requirements and opportunities, you automatically have most of your enterprise architecture, too.

All this is well and good, but if we accept that SOA is the royal road to better alignment between business and IT, we must face the question: exactly how will this alignment come about? How can we establish SOA governance so that business and IT professionals cooperate smoothly to deliver maximum business value while minimizing risk?

SOA governance is an extremely important, and highly sensitive, topic. After all, it sits at the intersection of two zones of controversy, neither of which has yet been resolved. On the one hand, we have SOA -- a new technology revolution that poses difficult IT problems and even more exacting organizational ones. On the other, we have IT governance, a discipline that, to be polite, we may characterize as still more of an art than a science. Neither can get by without the support of the other. IT governance is being transformed by the radically new demands of service-based IT, and SOA cannot hope to succeed without firm and consistent governance.

Given that SOA compels business and IT to cooperate organically, it follows that SOA governance must also blend requirements, processes, and techniques from both these domains. Questions inevitably arise as to the distribution of responsibility, the degree and manner of cooperation, and the ways in which decisions are made and -- just as important -- enforced. At one extreme, a committee of business managers might interview IT specialists before deciding what services are needed, how they are to be funded and built, and what feedback metrics are to be obtained. At the other -- a far more frequent scenario -- business groups inform the IT department of their requirements and then leave the "techies" to do the rest. Between them, the authors of the six articles that make up this issue of Cutter IT Journal thoroughly address all these questions.

Michael Kunz, Dirk Krafzig, and Dirk Slama proceed from the logical view that SOA governance cannot be dealt with as a static issue. Instead, they describe the ongoing challenges posed by a legacy-to-SOA transformation, noting that "effective governance raises the probability of SOA success because it enables big organizations to conduct change programs over many years." Not only does enterprise SOA force a reevaluation of how IT interacts with business, it also imposes organizational changes.

According to the authors, the transformation to SOA takes place on six levels: business, organization, people, IT processes, functional architecture, and technical architecture. They provide a sustainable roadmap for the transition to SOA at each of these levels and claim that this framework helps enterprises take a holistic approach to SOA adoption. This contention is supported by a brief case study of an international services company whose reuse rate in IT projects rose by 120% in a single year after it decided to take a global approach to SOA.

In our second article, Jorge Ronchese takes a step back to get a broader perspective on the origin and desirability of SOA governance initiatives. As every organization does not necessarily need SOA, he proposes eight criteria for assessing the likely benefits. There follows an analysis of inadequate reasons for embracing SOA governance, such as a desire to impose stronger controls or to compensate for weak management without ruffling too many feathers. Resistance to change is inevitable, but, Ronchese argues, it is not necessarily a bad thing. He explains how listening carefully to people's objections can be the first step toward defining problems and finding solutions to them, and he shows how the Theory of Constraints can help with this analysis. Given that "SOA governance is important if it solves some of the problems or constraints that are preventing your company from reaching its goals," Ronchese concludes by asking bluntly, "Do you have them clearly identified?"

Keith Swenson, VP of R&D at Fujitsu's Enterprise Software and Solutions Group, states a vital prerequisite for effective SOA creation: understanding the essence of the business. After all, without a clear insight into the enterprise's purpose and core activities, how can an SOA even be designed? Gaining that insight in turn demands a shift in the way business and IT work together. To this end, Swenson tells us, "Companies need to build an architectural roadmap with SOA governance woven into the fabric of daily operations." In short, someone must understand what the business is doing well enough to see changes coming, and then understand IT well enough to adapt the SOA accordingly. The trick is to make top-down business goals mesh with bottom-up IT development, which Swenson contends is the role of SOA governance. He also urges the instrumentation of SOAs with appropriate tools in order to know which services are available, who is using them, which services depend on others, and what quality of service is being provided.

So far, we have seen a variety of different approaches. Cutter Senior Consultant Tushar Hazra seeks to knit these together. He begins by comparing SOA governance with corporate governance, EA governance, and IT governance, seeing to what extent these existing disciplines can be co-opted to support the new dispensation. One clearcut distinction is that SOA governance has to cope with the impact of distributed services across one or more business organization(s), based on service-level agreements. Hazra agrees with Swenson that SOA governance should form a connecting layer between the complementary and equally important bottom-up and top-down approaches. After surveying some useful policies, principles, and best practices based on his own practical experience, Hazra offers some advice about the tools and techniques available for implementing governance processes.

At first glance, Hao He and Brett McDowall seem not to be addressing SOA governance itself, as their chosen topic -- the Universal Business Identifier (UBI) -- has more to do with technical architecture. On closer inspection, it turns out that the UBI has a significant contribution to make. He and McDowall start from the thesis that the goal of SOA governance is to align the business with IT by providing a suitable decision framework. The sharing of models between business and IT, especially a common taxonomy, materially contributes to that alignment. What He and McDowall propose is that the Universal Resource Identifier (URI), which we routinely use to specify Web addresses, should be co-opted in the guise of the UBI. They argue that "absolutely anything important in an enterprise should be identified by a URI." At a stroke, this would fulfill a number of SOA requirements, such as identification, addressing, ownership, resource lookup, and transparency. Above all, the UBI would help to keep things as simple as possible.

In our last article, Piotr Szabelak, Jan Topinski, and Cutter Senior Consultant Borys Stokalski identify a fundamental polarity between the formal, orderly processes of EA management and the innovative, potentially chaotic forces of SOA, which they dub the "yin" and "yang," respectively, of corporate computing. Indeed, the mere introduction of SOA can lead to growing demand for changes in governance, as established processes no longer cut the mustard. For example, many organizations currently seeking to roll out SOA have found themselves forced to rely on traditional techniques such as large-scale release management. These, however, militate directly against the fine granularity, ad hoc nature, and responsiveness that are supposed to be among SOA's greatest strengths.

This can be avoided, say the authors, by restructuring IT governance and EA processes along SOA lines. Everything -- from business planning to software release processes -- must fit in with the services metaphor. Trickiest of all, practices should be devised that allow project teams to coordinate their work on services without introducing any cumbersome and restrictive corporate chokepoints, and the services portfolio must become a truly shareable IT asset.

Some key ideas recur in article after article. Almost everyone emphasizes the fact that SOA's reason for existence is to further corporate business goals -- so SOA governance must be based upon a thorough understanding of those goals. There is also a strong consensus that building an effective enterprise SOA cannot be done piecemeal; instead, it should flow from a coherent central plan. On the other hand, the whole thrust of SOA is to accommodate different platforms, languages, and protocols. So we arrive at the classic dichotomy between top-down design and bottom-up implementation, with SOA governance as a "glue" layer in the middle holding it all together.

While tools are necessary for effective SOA governance, they are definitely not sufficient. As governance relies heavily on the behavior and decisions of human beings, it cannot be wholly automated. Moreover, the part of it that can be automated is, as we might expect, the lower-level, relatively mechanical aspects.

Whatever your interests and concerns or the special requirements of your particular organization, there is sure to be something in this issue that will interest and inform you. You may also discern some overlap and, perhaps, a measure of constructive disagreement. But that is inevitable, as the art of SOA governance is still in its infancy. One thing is for sure: if you are responsible for setting up or administering a corporate SOA, you will find stimulating and useful ideas aplenty in what follows.

About the Author

SOA has been the hottest topic in software for the past two or three years, and it looks as if it will be enjoying that status for the indefinite future. This is because SOA is seen not just as a new software architecture, but as a powerful way of reorganizing business enterprises. SOA experts stress the importance of breaking up the monolithic control that central IT has usually exercised over corporate computing in order to put separate divisions, lines of business, and departments in charge of their own services. This is all very well, but if SOA is the royal road to better alignment between business and IT, then exactly how will this alignment come about?

In this issue of Cutter IT Journal, we explore the implications of SOA adoption for corporate and IT governance. Find a roadmap for transforming an unstructured legacy application landscape into an enterprise SOA. Discover how managing business assets using Universal Business Identifiers (UBIs) will cause new development and initiatives to concentrate around business assets that deliver real value. SOA has been called "the answer to an enterprise architect's dream" -- join us to learn how to keep it from becoming a nightmare in your organization.