Darren Wesemann Blog

Last week I spoke at the Gartner Financial Services Summit in Boston on the topic of Best Practices for Enabling SOA Composite Solutions for Financial Services. I used as my primary theme, 7 lessons learned in SunGard’s collaborative SOA effort. I think the term “Composite Solution” has a comprehensive meaning for this subject. In my opinion, any SOA effort should yield a Composite Solution (independent parts or systems working together to provide greater value). Composite Solutions will be required more and more by the businesses we work for, as they continue to ask for more integration, (reasons include: regulatory compliance, B2B collaboration., mergers/acquisitions, deploy new packaged applications, single view of customer, implement self-service portals, improve data quality, etc.). Additionally, successful collaborative SOA’s involve much more that simply sharing data and services, or procuring a particular vendor’s SOA stack. I’ll attempt to lay out 7 things we found particularly important. 

Lesson #1: Governance process is more important than technology

Clearly the most important aspect of our effort is the very collaborative process that provides key centralized support, involvement of every area of the company (both business and technical). The central team is dedicated to the governance of common requirements, standards and technologies, offers guidance and education, manages the common code base and infrastructure, provides support services, facilitates communication and collaboration and administers automation for builds, tests and deployments. Our process provides for key collaborators within each Business Unit (Common Architects for technical representation and Common Product Managers for business representation). On a regular basis, cross-company collaboration occurs with weekly discussions, workgroups (subsets) define proposals, and the key collaborators vote on adoption. The collaborative process depends on common and centralized documentation, code, issue tracking, and on-line forums.

#2 Lesson Learned: Ensure key stakeholders from each domain are engaged

Probably the most continually challenging aspect of our effort is identifying key business stakeholders and ensuring they are engaged. Business stakeholders need to define which topics are important to collaborate on from a business perspective, assign members of their teams to participate in collaborative discussions and they need to be measured for participation and value added, with incentives provided.

#3 Lesson Learned: Measure and report on key metrics

In line with the old adage that you can’t improve anything you don’t measure, this lesson is key to the continual increase in value in any collaborative process. The kinds of things we found useful to measure include: contributions, consumptions, participation in collaborative workgroups, responding to common communications, cost savings and cost spend on collaborative activities (there is after all overhead to collaboration), revenue, and time savings.

#4 Lesson Learned: Inventory all assets in a directory or catalog

Likely the most important central repository is an asset catalog, or component registry. The registry should identify useful decomposed parts of legacy applications as well as the new stuff. Services, interfaces and components should be identified. Too many limit their registries to Web Services… keep in mind there are many interface types to useful components. In the Financial Services industry we have things like FIX, and a myriad of other protocols/interfaces to invoke a service or component. Your SOA is only as good as your metadata. Also, keep in mind version control for the registered assets is critical. You may run into people (as we did and do) that complain that your asset repository lacks something. Your repository should expand through contribution, and if functionality is needed, teams should build it and contribute it, so the next time a team needs the same thing, it is there, in other words if it is not there, it’s an opportunity to add it. Emphasis should be placed on reducing replication and foster reuse, and proposals for major modifications should be drafted and voted on by the collaborative community. A feedback process should identify if the proposed solution is inadequate, or something better exists and the collaborative stakeholders exist to discuss and decide on the best approach. Participation and feedback is crucial

#5 Lesson Learned: Adoption requires a maturity model

A maturity model is necessary if any technology exists in your enterprise at all, (in other words, a maturity model is always necessary). I’ve described our maturity model several times in my blog, so I won’t re-do that here, instead I’ll merely highlight the benefits of each level of the SunGard maturity model for reference:

Level 1 – Rapid Service Orchestration
Your application services can be leveraged by other business units quickly and easily, opening up new avenues for growth.
Level 2 – UI Conformity
Bundled solutions can avoid the fragmented user experience that has plagued past efforts at selling “integrated” solutions
Level 3 – Improved Processing
A single database provides deeper integration for better processing and analytical capabilities
Level 4 – Architectural Guidance “out-of-the-box”
Focus on your business problems, not technology issues.
Develop more rapid solutions by leveraging what already exists
“Out-of-the-box” composite solutions, already integrated

#6 Lesson Learned: Build integrity into the process and technology architecture

Key to any process is trust in the standards, reference and process. This is a lesson we continually try to improve, and dare I say… struggle with at times (hey, I’m a practical software guy). Areas of focus for us relative to ensuring integrity is built in are: automated testing, unit tests, functional tests, scale or stress tests, peer reviews, profiling, documentation, and standards.

#7 Lesson Learned: Harvest the low hanging fruit first

Uncover the projects underway that require integration, work with key business requirements, and identify real needs, ensure key stake holders are driving the projects, and above all… start small! Get some early successes.