You need a reliable organizational mechanism to transfer knowledge, enforce standards, provide infrastructure for growth and change, and in general offer strategic leadership regarding your service-oriented architecture.
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.
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, specialized 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 aspects 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 developer/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 governance 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.
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.
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.
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.
Architects in this context act as a guide to developers, enforcing the reference architecture and supporting their efforts. They might select tools, frameworks, and infrastructure applications, and adopt and adapt methodologies to support the service-oriented enterprise.
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.
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.
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 language 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 reference architecture.
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 important documents during design and runtime.
A common pitfall, particularly within large or decentralized organizations, 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, encouraging 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 versioning 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 represents. 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.
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.
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, maintenance, and management problems. Remember the old saw, “just because you can, doesn’t mean you should.”