CSA integration and preserving legacy
Making independently designed applications work together is one of the two primary challenges that faced the CSA effort in its beginning stages nearly four years ago, (the other challenge had to do with getting independently managed teams to work together). The key to how the CSA standardizes integration lies in the understanding that many application systems found in our customer’s IT organization are linked to one or more application systems, even if the connection is only a batch file transfer. Nearly all of these interactions follow a relationship pattern involving functions, business users and data consistencies.
Functions (often multi-step functions) involve a sequence of related activities, each conducted by an application system or person. Each instance of a business process has a life cycle that consists of steps that collectively take seconds, minutes, hours or days. Business users consume a composite of components through a user interface. They view a software assembly that implements business functions in a user context, whose parts are heterogeneous in their information architecture. Data consistencies allow multiple application systems to agree on the facts. This is useful where there is shared information between software components.
These patterns are captured by the first three CSA standard levels, and allow for steps to be taken in making the most appropriate part of each SunGard legacy application common in terms of how it interacts. The levels utilized in each case depend upon the three patterns exhibited above. SunGard of course defines a level where new development occurs (standards for contemporary software development where new functionality is natively in a consistent framework, called ‘Level 4′), however the vast legacy of installed application is treated by the three patterns discussed above: functions (or Common Virtualized Services, called ‘Level 1′), business users, (or Common UI, Security and Administration, called ‘Level 2′) and data consistencies, (or Common Data Model, called ‘Level 3′). See my blog entitled “Why are there CSA Levels” at Why Are There CSA Levels
s for more on the levels.
With an understanding of the patterns found in typical integration scenarios, it’s easier to see how the vast plethora of legacy applications at SunGard can become standardized in terms of how they interact with each other as well as our customer’s systems, providing greater agility, utility and reuse.