I'm at InfoWorld's SOA Executive Forum this morning in San Francisco. I'll be conducting a panel on SOA governance later this afternoon. There's a sellout crowd. InfoWorld really knows how to put these things together. I also know from working with Eric Knorr, Steve Fox, and other editors at InfoWorld that they try really hard to make sense of this, create good ways to explain it, and develop sound advice.

The opening keynote is by Jeff Gleason, Director IT Strategies, Transamerica Life Insurance Company. He's speaking, from experience, on achieving reusability using SOA. Transamerica provides life insurance, pensions, and related investment products with the typical product offerings you'd expect. The complex piece, the part that drives SOA is the distribution network of independent agents, broker-dealers, banks, and other financial institutions

Jeff Gleason of Transamerica speaks at SOA Executive Forum (click to enlarge)

The product Transamerica offers is not, of itself, a sustainable competitive advantage because competitors can copy products in a short time. Giving customers and distribution partners good service is the competitive advantage. In addition, the legislative and regulatory burden is heavy and there is considerable economic pressure (low interest rates, consumer confidence, competition, etc.)

The technical challenges include legacy mainframe systems running COBOL apps on VSAM, lots of complex, P2P integrations, redundant tools, and limited documentations and metadata. All this has created a brittle complex architecture that has created rather then being planned.

The environmental challenge includes a project-based culture, architecture, process, and tools. Last year there were 800 projects that resulted in something entering production. Jeff explains what he means by "project based architectures" as an architecture that has been built up over time where each project does what works best for that project. The result is an architecture that doesn't support change even though IT is the key vehicle that business executives use to support change.

In 2003 Transamerica started a project to define a strategic architecture. The strategic architecture has an integration focus for both applications and data. The architecture uses business services for functional encapsulation, BPM for process orchestration, BAM for process visibility, and a portal for user interface integration. The methodology is SOA.

Jeff shows an as-built diagram of their high-level integration diagram as it existed early in this process. The policy administration system is the core piece. The diagram looks like a plate of spaghetti. Splitting this diagram up shows lots of redundant functionality. The future-state diagram shows three layers: data, elemental business services, and composite apps. The data layer is not just a database, but includes infrastructure pieces like CRM, accounting, etc.

The first project enabled policy valuations. This was a batch-oriented process with multiple applications and data stores. There was significant ROI and great opportunities for re-use because this process gathers data that's core to the business. Business partners require valuation data (via SLA) in a timely manner, but as the number of policies grows, the ability to calculate the value goes down.

There were three key lessons learned:

• Re-use doesn't happen in a vacuum. You need steward to implement and guide the process.
• You need tools to understand what you have and what you need.
• Process can be used to level the skill sets needed.

Two perspectives on reusability. What exists and how can it be reused (legacy apps, data stores, etc.) Whoops, missed the second.

The stewards for reusability are the architecture team. They look for patterns and standards and provide architecture level consulting and governance. There are business patterns, applications patterns, and product and technology mappings. An Integration COE shows how to implement the patterns and standards picked by the architecture team and provides implementation level consulting and governance.

Tools for reusability let you see what you have and model what you want. For example, they've created an business event viewer and records information about business events and can be browse or search these records. A second tool (built on Rationale's Requisite Pro tool) tracks business event tractability. This shows events, actors, and the object of the event.

A business architecture map shows how business event, functions, services, transactions, and data stores are related. This related the business architecture to the technical architecture. The map and other tools show where reuse is possible because redundant functionality can be seen.

The are four important parts of their process for reusability.

1. New roles of technical and business architects have been created. They identify business and technical opportunities fore reuse, integration, and consolidations. They're also responsible for requirements management.
2. Minimize Risk by identifying risks, developing prototypes, and using iterative development.
3. Ensure Quality with quality gates and iterative development.
4. Be seamless by tracking changes through requirements, designs, technical artifacts, test cases, and test scripts.

This process has had a real impact on design yielding configurable and dynamic services. For example, in creating a new design for agent validation services, Transamerica found components that have since been reused in three other systems.

SOA is not about technology like UDDI, WSDL, and SOAP and more about the organization that uses those things. Jeff didn't use the word specifically, but what he's really saying is that reusability requires good goverance and enterprise architecture.