Java Reference
In-Depth Information
Chapter 11. SOA Governance
Introduction
While this topic is predominantly technical, it is also essential to address some non-technical
items in order to highlight SOA as a unifying concept. Without considering the non-technical
work within the framework of SOA, we are doomed to wind up over-engineering a bunch of
software components that could have been written less expensively, more efficiently, and in
a more easily maintainable manner. To focus solely on building web services is to miss the
point of SOA entirely.
We have been creating web services in the industry for several years, and while the term
“SOA” may already be 10 years old, many organizations are still only at the evaluation stage.
Gartner research shows that only a small percentage of organizations that self-identify as those
doing SOA are actually in a mature stage, meaning that they utilize a wide catalog of re-
used services in a repository; activity monitoring and automated alerts; brokered ESBs ex-
ecuting under governance domains; rules-based services; solid change management; federated
partnering and security; advanced process automation that includes dynamic discovery, bind-
ing, and composition; and a complete governance board. Governance can act as perhaps the
primary caretaker that helps nurture a fledgling SOA into a mature SOA.
Some of the discussions in this chapter, such as those on return on investment, may seem out
of place in a technical cookbook. But SOA brings to the forefront the alignment of software
with business strategy.
SOA attempts to undermine the traditional dichotomy between business and IT, an exag-
gerated view of which casts admins and engineers as feared and loathsome Quasimodo-like
creatures, madly toiling nerdy beasts who work on their exotic art projects for vending-ma-
chine treats. They secretly ridicule their executive and marketing overlords for having all the
flash, polish, and witless bravado of a hopped-up surfer dude with nothing on his mind but
the next chance to hang ten on some sick Aussie waves. SOA recognizes that this dichotomy
is part of the problem in modern software development, and seeks to define strategic ways of
overcoming it. The architectural, design, and management principles that SOA makes avail-
able help support the alignment of business and IT, recognizing that a little more harmony is
key to realizing the greatest benefit.
Many of the topics in this chapter will address practical matters that developers and architects
must face, such as service versioning and retirement processes. But to really make this an
SOA book, and not a “Let's Tape a Bunch of Web Services Together and Call It a SOA” book,
