Building a service-oriented architecture (SOA) requires significant IT and business collaboration to ensure that IT builds the right services and that different business silos don't create duplicative services in a vacuum. SOA governance is the way to build in the processes and checks and balances to ensure your company does SOA right, and doesn't end up with a mess like a bank that built hundreds of services only to find out that one-third of them were redundant.
Whether you are gearing up for an SOA implementation or taking a step back to reassess the direction of an initiative, here are six key steps to take to establish and maintain SOA governance.
Understand the overall picture of what you are trying to accomplish, not from a technology perspective but from a business perspective, said Todd Biske, a senior enterprise architect at $11 billion agricultural company Monsanto Co. and the author of the book SOA Governance.
An SOA initiative must justify why IT should turn one particular business capability into a reusable service and not another. Without such governance, an organization runs the risk of overinvesting and creating too many services that there isn't much interest in or creating too few services without improving business processes or meeting business goals.
"You've changed the technology and realized some incremental gains, such as making integration easier, but these are not transformational gains," Biske said. "Unless you look at the big picture, such as what needs to change about the way we develop software and deliver business solutions, then you have to ask if you're really doing anything to make that change happen, or if it is just a repeat of earlier efforts with a different technology."
To clearly define desired outcomes of an SOA initiative, you need a chief architect who understands the business implications as well as the technology needed to reach set goals, said Timothy Vibbert, an SOA architect at Lockheed Martin Corp. in Bethesda, Md. "You need an architect that isn't going to go in and say, 'We're doing this because we want more agility' -- that's a technical thing. Rather, he has to explain how it will increase customer satisfaction or reduce maintenance costs."
Establishing a center of excellence or review board to set and enforce SOA policies is not enough when effective communication is lacking. Because individual members' opinions and definitions may conflict, start with policy definitions and agree on those policies. Then communicate that the review board will check team members' work against these policies, Biske said.
The same policies employed for any IT governance project also apply to an SOA initiative: Identify up front the teams that will be involved, the systems that may be affected, the groups or business functions a service could impact, the existing services that may be impacted, whether another business unit may have a need for a similar service down the road, and which groups will be funding which initiatives and if resources can be shared.
Make sure the center of excellence or review board educates and communicates with stakeholders on an ongoing basis in a format they will respect. Biske said he has seen organizations in which center of excellence members keep policies close to their chest. The result can be chaos. "Anyone that is not allocating some amount of time to educating staff is at risk of running into much bigger problems down the road," he said.
Never think one brown bag presentation will suffice, particularly with something as complex as SOA that can result in far-reaching organizational change. The message has to be repeated and geared toward large audiences, business units and even individuals.
You need an architect that isn't going to say, 'We're doing this because we want more agility.' Rather, he has to explain how it will increase customer satisfaction or reduce maintenance costs.
Timothy Vibbert, SOA architect, Lockheed Martin
Recognize that some forms of communication, such as blogs, are not recognized by all employees in a large enterprise. In addition to internal blogs, Monsanto uses email blasts and lunch-and-learn events. "Use every communication tool at your disposal and take every member of the community into consideration because what you communicate about SOA to a department manager will be a lot different than what you communicate about it to a developer," Biske said.
Communication is particularly important when it comes to SOA governance, since one of the main benefits of SOA is reusable services. There is a danger of groups developing services that work only for their own group, versus a service that can be used across several business functions. "Reuse is a big promise [of SOA]. I've seen times when people find out about a service being developed that was already developed by another group," Vibbert said.
Every time you go to develop a new service, ask other groups to figure out if they have additional requirements that you should be factoring in, Biske said.
Enforce polices through education, not punishment. Biske is a big fan of self-assessment in which project team members fill out a scorecard that asks questions like, "Did you meet these conditions or not?"
"We collect those over time, look for trends where we are not compliant, and figure out what to do," Biske said. Other approaches include assigning a mentor to a project or even an individual who acts as both mentor and policy enforcer and is held accountable for policy compliance.
Don't underestimate the need for a repository. Runtime, which gathers production performance metrics of a service, and registry governance, which stores production information on services intended for reuse, are an important aspect of an SOA initiative. But they are often overlooked in a repository for the business side, where additional information and documentation is stored.
Vibbert, for example, was on a team that developed an integrated repository of performance runtime metrics for three tools integrated from three different projects. The resulting services from those projects were published in a single repository, including service-level agreements, runtime policies and performance metrics. That way, the next person who goes to choose an approved reusable service can look at those combined metrics to make the best service choice.
"I can't do that with a plain registry. I have to have additional capability, and that's where a repository comes in," Vibbert said. "A registry alone also won't hold PowerPoint documents or usage plan information, legal documents, etc. All of this helps people make better and easier decisions."
Measure the effectiveness of your SOA initiative as you go along in order to stay on track with goals and assess whether you are hitting your marks. Always look back at the original set of goals to see where you need to go next. "If you're not achieving original goals, you need to ask if you're doing an ineffective job in educating. Or your enforcement approach may be ineffective, or it could be that policies were created that just don't work and need to be changed," Biske said.
Vibbert said that in his experience, a roadmap approach for measuring success is easier to understand than a maturity model. Maturity models are loaded with text with several stages laid out and bulleted lists help you determine when you are at a certain maturity level. A less rigid and more realistic approach for an organization could be a roadmap that is more pictorial, with milestones that have and have not been met clearly displayed.
Let us know what you think about the story; email: Christina Torode, Senior News Writer
This was first published in April 2009