Service-oriented architecture (SOA) projects start with governance and end with governance at Thomson Financial, the arm of The Thomson Corp., which provides online information services to customers.
Governance rules the activities of the SOA Center of Excellence (COE) at Thomson, said Ian Koenig, the firm's senior vice president and chief architect. This past week in a presentation to the SOA Forum Roundtable, coordinated by WebLayers Inc., he covered "Ten Valuable Lessons Learned" in building the Thomson COE.
Integration of disparate systems is a way of life for IT at Thomson Financial, which was originally formed through 50 individual acquisitions and is now in the process of acquiring Reuters, one of its major competitors.
"Thomson Financial is one of those companies where technology solutions built from its service-oriented architecture are the products it sells," Koenig told the roundtable at the beginning of his presentation. "Many companies fall into the category where IT supports the business, at Thomson Financial, IT is the business."
With the information products generating $2 billion in revenue in 2006, it is important that the Thomson SOA COE have governance in place to make sure those services work together without a hitch, the chief architect said.
"The union of all services is your entire infrastructure," Koenig explained. "The service interfaces are what provide access to your services. The services are well defined, meaning they all communicate by well defined interfaces. Then you define another type of thing called a solution or composite application, which is built from the services."
Not surprisingly, Koenig's top 10 list of SOA lessons learned began with governance:
1.SOA requires governance. The only way to control the complexity of an IT infrastructure built out of services is with a governance process based on "a well defined set of interface guidelines and policies," Koenig said.
2. Govern to the policies that matter. It is important to focus on policies which are critical to making the business work and providing the customers what they need, Koenig said. While it might be easy to brainstorm 5,000 policies, he recommends narrowing the focus to 50 that really matter. As his slide put it: "Having too many policies is just as ineffective as having none (maybe worse)."
3. People don't communicate. What Koenig is saying is that when talking about or arguing over something as abstract as SOA, verbal skills usually aren't up to the job. He advocates going visual. His COE uses UML tools for class diagrams and sequence diagrams to clarify problems.
4. Make governance easy and do it early. Since nobody likes being told after they have completed a project that they have done it wrong and need to do it over, Koenig advocates integrating the policy management into the software development lifecycle (SDLC) from the very beginning, so policies are built into projects.
5. Reusability does not come cheap. Despite all the SOA hype around reuse, Koenig says it is important to understand that building reusable services is expensive. "In fact, our rough calculations are that it is approximately two-and-a-half times as expensive to make a module re-usable as not." His rule of thumb is that if you are going to go to the expense of designing and building a service for reuse, you should be sure it will have at least three users.
6. Interfaces are more important than implementation. Koenig says "a proper interface encapsulates an implementation," so it is important to "get the interfaces ( APIs) right first." At Thomson Financial they have precise policies to make sure interfaces support loose coupling and proper versioning, he said.
7. Integration is more common than "greenfield." Koenig, who held a similar architect position at Reuters before joining Thompson, said that while there may be so-called "greenfield" architectures somewhere in the world, he has never seen one and doesn't expect to. Facing the reality that many companies grow through acquisitions and have heterogeneous systems, SOA with good governance is the best choice for IT, he argues.
8. Identify the owner for each service. Every service in an SOA should have an owner, Koenig said. In fact, there are owners at two levels. Business owners are responsible for the business aspects of the service, including the cost of running it and its value proposition, he said. Infrastructure owners are responsible for maintaining the service level agreements (SLAs), and making sure consumers of the service are satisfied with it.
9. Be pragmatic. Just as there a few if any greenfield architectures, Koenig argues that there are no perfect SOAs. There will inevitably be "deviations" from SOA best practices to meet the immediate demands from the business side of the operation. The way to deal with this is the define how deviations will be dealt with and tracked as part of the governance process, he said.
10. It's all about governance. Closing the loop in his top 10 list, Koenig said managing an SOA environment requires an on-going governance process "to measure how far you are from goals and whether you are converging or diverging." Through on-going governance architects learn where the SOA needs to be enhanced and what new development is need to solve problems.