At any given time, SunGard has hundreds of active projects involving the decomposition and evolution of its systems, legacy and contemporary alike. We track and monitor these activities as an organization because many of them are collaborative in nature. Our SOA effort (the SunGard CSA) enables the collaboration by ensuring reusability of work done, common standards, vision and strategy is achieved over time and an overall customer experience is controlled and enhanced.
I’m often asked how legacy decomposition is going at SunGard. One customer even used the word “frightening” in a recent conversation where the size of the SunGard portfolio of applications was apparent in the dialogue, and he was curious if the sheer size of this effort would be adding inertia, such that the weight of each situation adds resistance to the whole, eventually slowing it down to a dead stop. I was happy to report that due to the federated (decoupled and distributed) nature of the SunGard SOA effort (CSA) we’ve found that each project isn’t added weight, its parallel (weight none the less, just not additive), so even though a mammoth undertaking like this looks “frightening” on the surface, it’s actually quite systematic. Our experience has been one of acceleration with each collaborative activity, rather than burdensome added weight.
I also shared several key attributes we’ve learned over the years to assist with educating people who are tasked with the daily architecture and business process work that surrounding a decomposition effort. I’ll include in this blog the key success factors to the process of decomposition that I shared in the conversation for everyone’s benefit.
First, I shared that recognizing resistance patterns in teams and turning them into adoption patterns for success is the first thing to establish. I’m working on a white paper at the moment that articulates this concept, so I’ll leave that topic alone here, and will make a blog entry when the paper is available.
Second, starting a project where refactoring and/or decomposition will be used for the purpose of evolving an application into an agile and flexible system of configurable components or services requires a new way of thinking. I face this issue continually at SunGard, i.e. smart people that have been maintaining and enhancing the same systems for years, and getting people to think differently when their daily lives are so engrained in a particular methodology can be challenging.
In a nutshell, if the education is founded in sound principles, usually the teams catch on quickly. The method we use includes methods for both business processes (containing units of business functionality) as well as data (providing context for the process and functionality of the parts). Both have to be modeled in their current form (the initial take should be extremely high-level), meaning a sheet of paper should contain a flow diagram of the process and another sheet containing the data and its relationships. Keeping the first draft very high-level (almost trivial) will assist in ensuring the team slowly gets converted to the SOA-way of thinking, because the cold-turkey method doesn’t work well with teams that have been working with an application for years.
From the high-level process and data diagrams, iterations will start to decompose the components further and further, until the lowest-level of the business process and data model have been documented. With each iteration, education is required to ensure the teams are contributing and evolving along with the process.
At that point, the more interesting phase begins, where the list of decomposed parts are then architected in component form (this is where the determination of re-writing, combining or refactoring any of the resulting parts is determined versus merely exposing and interface of an existing component). This is also where the SOA begins to take shape, such as loose coupling of the parts, decisions on protocols, interfaces, events handling and other infrastructure as well as process modeling with the case studies. In a parallel effort to the iterations, case studies that hold examples of the desired end-result should be considered and tested intellectually.
There are several keys to this stage as well. Redundancies can usually be identified early on, allowing for normalization exercises to take place where the best, combined or new component survives. It’s also necessary to accept a hybrid approach to the resulting components. For example, a component can merely be “wrapped” with an interface, thus exposing it’s functionality in an agile way however, the implementation remains non-partitioned and largely unaffected underneath. Interfaces can also be partly-partitioned, meaning there is some implementation that has either been refactored or added to allow greater granularity to the exposed functionality. Interfaces can also be “composite”, meaning they are a sum of multiple components.
The data modeling is no different. Lots of iterations resulting in further normalization each time a new decomposed component list is published. Data can be encapsulated, just like components can. If a particular complexity is irrelevant to the whole, those details can be hidden for simplification. The data model can group elements into an actual data-service, meaning common access to information (just data, no functionality), or groupings can be context for the various components resulting from business process decomposition (which is where functionality is exposed).
Throughout the process, various issues typically arise. Education in advance usually helps mitigate those issues before they bubble into tangible problems. Normalizing the redundant parts uncovered, governance for policy management, version control, quality/integrity management, proper expectations are some of the education needed in the beginning to ensure a successful decomposition effort. The right tools are also a necessity to holding the effort together, (i.e. having established standards, a center for testing compliance to those standards, a registry to keep track of all the parts coming out of a decomposition effort, business process management to ensure composite solutions can be orchestrated and deployed from all the parts and agility created, etc…). SunGard offers it’s process, tool sets and overall infrastructure for SOA in an offering called “Infinity”, which contains all our experiences, maturity and lessons-learned from our on-going and “frightening” job of making software in the Financial Services industry flexible, agile and “infinitely” configurable.
