News

SOA Excellence: Some Lessons Learned

• By Kurt Mackie
• March 10, 2008

Koenig spoke last Thursday on the topic of "Establishing a SOA Center of Excellence: Ten Valuable Lessons Learned." The talk was part of a continuing series on SOA governance hosted by The SOA Forum, which has more than 1,600 members. The SOA Forum has been sponsored for about five years by WebLayers, a provider of SOA governance solutions.

Thomson Financial was formed from more than 50 individual acquisitions and had a fiscal-year 2006 revenue of more than $2 billion, Koenig said. There are six products in the Thomson ONE line, covering equities, fixed income, wealth management, investment banking, investment management and corporate services.

Keeping all of those acquisitions together while still meeting customer needs was a challenge for IT. The company needed to create workflows that were targeted toward what its customers were doing. Doing that would entail breaking the old products apart and reaggregating them, Koenig explained.

What Is an SOA?
The talk frequently paused for questions and Koenig was also careful to provide definitions for terms commonly thrown out by enterprise architects. For instance, he gave a definition for SOA.

"A service-oriented architecture is essentially a collection of services that communicate with each other to provide a specific function," he said. "The communication can involve either simple data passing or it could involve two or more services coordinating an activity."

Koenig described a service as a broad term that's inclusive of Web services but not equivalent to it. He used a picture of an iceberg as an example. Web services are merely exposed tip of the iceberg. However, beneath the surface is where services and the implementation reside.

Thomson's solutions are built from its shared services, and the company has a general goal in terms of using those shared services.

"One of the metrics that we use is that we aspire to have 80 percent of the functionality of our solutions built from shared services; 20 percent of it being service-specific functionality," Koenig said. "And we measure that -- it's measurable in a service-oriented architecture -- and we govern to that."

Lesson 1: You Need Governance for SOAs
SOA requires governance, Koenig said. It all comes down to the enterprise architect and the governance process to control the potential chaos that can arise in an SOA.

Here Koenig preferred to use the definition of governance described by the Burton Group: "Governance is a process which defines a set of policies and produces a set of metrics so that an organization can manage the eventual convergence of the technology to the architecture."

Lesson 2: Choose Policies That Matter
Having too many policies is just as bad as having none at all, Koenig said. Too many policies leads to death by governance, so choose the ones that matter. Koenig's rule of thumb is based on the pain threshold associated with breaking the policy. If you can define the pain caused by breaking the policy, then it definitely matters and the policy is important.

In his work with Thomson ONE, Koenig said that his team differentiated 5,000 really good ideas and then distilled them down to 170 policies that really mattered.

"The lesson is, don't govern by too many rules -- or don't boil the ocean," he said.

Lesson 3: People Don't Communicate
When two or more smart people disagree on a solution, it's almost always true that they don't agree on the problem they are trying to solve, Koenig said. He described tools to help with that communication.

"We found that the best vehicle for communicating architecture is through diagrams," he said. "And we chose a standard that is subset of the UML 2.0 specification."

His team uses class diagrams for showing how things connect. They use sequence diagrams for showing how the data flows.

An audience member asked about the use of business process modeling.

"About two thirds of the services in our architecture don't require business process diagrams, but for the third that does, we adopt the UML flow diagrams for that," Koenig said. He added that the tools used for business process modeling at Thomson include "the human brain and Visio. And I'm not sure that I would encourage anyone to follow our pattern on that."

Lesson 4: Make Governance Easy and Do It Early.
Making things easy was perhaps the second major theme of Koenig's talk. He cited an adage on the problems of complexity in an organization and how people react to complexity.

"Sixty percent will do the easy thing, regardless of whether it's right; 40 percent will do the right thing, regardless of whether it's the easy thing to do," Koenig said. "So, I think that if we can make the right thing to do the easy thing to do, you pretty much get everybody."

Automation is one the keys to making things easy and Koenig said that Thomson has tried to automate governance wherever possible by integrating governance into the software release process.

"We use the WebLayers Center for SOA Web services governance and policy management," Koenig said. "We use Black Duck protexIP for open source monitoring and the Fortify toolset for information secure IP set and code scanning. And all of those are integrated from the point when the developers check the source code in and run automated builds."

This approach generates governance reports "right at the beginning of the process…," he explained, "long before we get to the actual physical human review."

Lesson 5: Reusability Is Not Cheap
Koenig said that software reuse has been the goal ever since "objected oriented" first appeared in text books in the 1960s. However, reuse is expensive.

"Our rough calculation is it's about 2.5 times more expensive to make something reusable as not." If you are dealing with reusability, by definition you want customers, he said, and those customers are going to want support, which is a cost.

Lesson 6: Importance of Interfaces
It's more important to get your interfaces right than get your implementation right, Koenig said.

A well-defined interface can enable loose coupling. And by definition, loose coupling applies the rules of versioning.

Lesson 7: Integration Is More Common Than Greenfield
There aren't too many greenfield systems out there, but even so, the principles of a service-oriented architecture would apply, Koenig said. "Any big problem is going to be easier to solve as you carve it out into smaller problems that will integrate back together," he added.

Thomson uses its governance model when acquiring companies. "We use their compliance to our policies as a metric to the integration cost of that company," Koenig explained.

Lesson 8: Identify an Owner for Each Service
It's important to identify who defines the value proposition for the service, Koenig said. You need to know "who gets called at 3:00 in the morning if it's not meeting its SLAs."

Lesson 9: Be Pragmatic
Enterprise architects have to understand a lot, but achieving perfection isn't the goal.

"The perfect architecture no matter how perfectly defined will never be achieved because it takes too long and the business will change by the time you do," Koenig said. "It's like trying to reach the end of the rainbow," he added.

"What a good architecture and a good process give you is agility, and that's what the business needs more than a perfect architecture." And because perfection is out of the picture, that is why governance is so important, "because it's about the process of getting there," he explained.

Lesson 10: It's All About Governance
Governance lets you measure how far you are from achieving your goals.
It supports the business with efficiency and agility, and it improves quality in complex technology environments, Koenig said.