See Also
1.9 Establishing Governance
Problem
You need a reliable organizational mechanism to transfer knowledge, enforce stand-ards, provide infrastructure for growth and change, and in general offer strategic lead-ership regarding your service-oriented architecture.
Solution
Establish a Center of Excellence, sometimes called a “Competency Center” or SOA governance board, comprised of stakeholders from the business and technology sides of the house, whose job it is to provide the enterprise this support.
Discussion
Depending on the maturity level and size of your company you may already have IT governance standards in place. SOA governance is an extension of IT governance, spe-cialized for the particular needs of SOA. Because SOA represents a strategic initiative of which a set of tools and techniques is only a part, you need to have a way to gradually introduce the strategy into your organization.
This book does not address much of the organizational or business as-pects of SOA. While they are very real and important parts of SOA, there are many good books that address SOA from that angle, and this book is intended to address the technical side. But it is important as a devel-oper/architect to be clear that SOA is not merely a collection of web services.
SOA requires new processes. It must be clear to your organization how to design SOA-based solutions, elicit service candidates, and coordinate a new development cycle to support your incubating SOA.
You might include solutions and systems architects, as well as business stakeholders in the Center of Excellence. This helps ensure that IT acts in alignment with the business and has access to its current priorities and future plans.
Keep the governance team somewhat lean. As long as the SOA gover-nance team has enough resources to remain aware of the activities of the enterprise and enforce and grow the reference architecture, that should be enough. Grow it responsibly. You don’t want your SOA to die by committee.
The responsibilities you might assign to such a governing body are as follows:
Establish business case
This may be performed early on during SOA adoption by the enterprise architect and others. The business case for SOA includes the vision, the goals that SOA will accomplish, and probably a plan to fund the initiative.
Outline roles
SOA will introduce new roles within IT, and they should be clearly stated. You need people to be responsible for carrying out the governance work, make
architectural decisions, establish the reference architecture, vet services, process service candidates, and establish and grow new infrastructure such as the ESB. You may also decide who will support and maintain services after they are deployed, and ensure that your knowledge transfer plan accounts for this.
Assist in setting the roadmap
The governance team has a special purview that may make them key elements in helping the enterprise architect or technical executives set the IT roadmap. The roadmap may go so far as to map defined activities to larger goals, and map those goals to a larger set of aspects of your business vision.
Maintain the reference architecture
The CoE can also have the maintenance of the reference architecture under its purview, which will aid in building and linking process models into the larger enterprise.
Facilitate development at design time
Architects in this context act as a guide to developers, enforcing the reference ar-chitecture and supporting their efforts. They might select tools, frameworks, and infrastructure applications, and adopt and adapt methodologies to support the service-oriented enterprise.
Facilitate services at runtime
The subjects of SOA governance include developers and services too. Runtime monitoring tools should be in place to ensure that SLAs are being met. It is under the purview of the governance team to keep track of this and plot for future growth so needs are met just before they arise.
Facilitate services’ life cycles
The governance team can see when services may need to be versioned, and assess the impact of that versioning. Versioning is a more complex issue in SOA than in traditional development because of its distributed nature. The person or team who develops a given service may not have any clear view into the larger set of processes that now compose this service. It is the job of the governance team to understand and prepare for this and oversee its proper implementation.
Enable knowledge transfer
The CoE can support the knowledge transfer effort. The learning curve on SOA and on web services APIs and infrastructure can be considerable. Even if some members of your team are not building services, they should be aware of the lan-guage and familiar with the ideas in order to work in a complementary manner.
Eventually such developers may move on to create and consume services, and they need to be prepared to understand and follow the guidelines laid out in the refer-ence architecture.
Common pitfalls governance helps you avoid
Organizations that attempt SOA without governance in place can fall victim to a variety of ailments, including total failure of the SOA initiative. There are a few common, avoidable pitfalls.
You can’t govern what you don’t know about. So, to ensure that all of your service-related code and documents are visible, implement a central repository that has the documents of record for each version of each service. This will help track these impor-tant documents during design and runtime.
A common pitfall, particularly within large or decentralized organi-zations, is service redundancy or overlap. The same or similar service is repeatedly created throughout different groups in the enterprise. This is expensive, wasteful, and confusing. As a result you can find yourself with sharply increased maintenance costs.
It is the job of the CoE to prevent this by monitoring what’s getting developed, en-couraging collaboration between implementation teams, and establishing and using a centralized repository for service discovery.
On a practical level, ensure that governance is in place to manage the many new kinds of artifacts that SOA can introduce, such as WSDLs, schemas, SCA configurations, policies, and more. Left to their own devices, developers will view such documents as simply part of the code like everything else, and bake them directly into their project files. The artifiats will end up scattered across the enterprise, and version-ing and client dependency management will quickly get out of control.
While Death by Acronym is a syndrome we see in IT and is not particular to SOA, SOA practitioners are among those most vulnerable to it. To die by acronym is to erroneously believe that one understands whatever the acronym repre-sents. Because acronyms act as stand-ins for very complex concepts, they gain the status of sound bites and lead us to affirm to one another only the most bare, surface, and general meanings of the concepts at play. The result is strangled communication that undermines collaborative efforts. At its most insidious, companies looking to claim market share for a rising buzzword will rebrand a collection of only marginally related products with the buzzword. SOA is susceptible to both of these kinds of problems.
Education is the only known cure. In the case of SOA, it means not trusting any single source, and cross-checking with a variety of references.
Resume padding
This is a reality. Beware of developers and architects who seek to advance their careers at the cost of populating your SOA with frivolous functionality or over-engineered solutions. You can recognize these types by their endlessly new answers to problems that have already been solved.
Governance can handle this problem by making all service-related development efforts transparent, and by managing solution implementations.
Service redundancy.
Sundry artifacts.
DBA (Death by Acronym).
Bunny services
One bunny is pleasant to find in your yard. Two bunnies are even better, chasing each other hither and yon. Fifty bunnies is a problem. Just because something is good doesn’t mean that more is necessarily better. The cake you’re baking might need half a teaspoon of salt; add a tablespoon and it’s ruined.
Once you get good at services, it will be tempting to make lots of them. Review your landscape. Not everything should be a service. Allow services to proliferate in your organization in the manner of multiplying bunnies, and expect performance, mainte-nance, and management problems. Remember the old saw, “just because you can, doesn’t mean you should.”
Summary
In this chapter, we established working definitions of central terms such as service-oriented architecture and services themselves. We started from a very general level and addressed chiefly matters of organization, such as how to establish a reference archi-tecture and choose a pilot project. But we also examined fairly specific criteria useful in determining worthy service candidates as well as specific guidelines to establish to support the goals of SOA within your organization.
While there are additional design considerations we will address, most of the rest of this book is very practical, and addresses coding problems with coding solutions. Even coding problems have more than one solution. But in the case of the topics in this chapter, there are many other legitimate points of view, and many people who might disagree with some of my conclusions in it.
There are many good books that cover these topics and others in greater detail. If you are interested in high-level service design and organizational considerations, you might read Thomas Erl’s SOA: Principles of Service Design (Prentice Hall) and Nicolai M.
Josuttis’s SOA in Practice (O’Reilly) (http://www.oreilly.com/catalog/9780596529550).