Darren Wesemann Blog

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.

Although often sought after, software component reuse historically has been difficult to realize on a grand scale. Component-Based Development or CBD, for example, applied focus centered narrowly on the reuse of software artifacts in the application development process, in other words it was a purely technical exercise and often was not collaborated across IT teams and worse, business stake holders. As a result, the reuse of components was illusive and often not realized.

In order to achieve reuse, a collaborative process must be leveraged. Organizations adopting SOA’s in particular can take advantage of the agility and flexibility inherent in the service oriented approach and combine a collaboration process to make reuse a reality. The process must properly manage expectations, drive appropriate behavior throughout the entire IT organization, define accountabilities, define communication flow, and position reuse as a means to an end, not an end in itself, in other words reuse is more about a process than a deployment.

As the business stake holders historically have been left out of software decisions below the highest level of an application (what the user sees), it’s critical the business requirements process get inserted into the process iteratively and incrementally. In a clear collaborative model involving teams across functional areas, reuse of software components or services becomes a reality.

Often the ROI question is taken out of context, so in order to arrive at a complete picture (and one that can be measured), several attributes of the SOA need to be taken into account. SOA is not a technology, it’s a design philosophy that must be understood and applied, and accordingly many appear to be missing the total affect of its potential.

First, because SOAs and agility go hand-in-hand, there is a whole process behind the interaction of people (developers, testers, support engineers, business management, etc…) and the SOA itself. Processes such as validation, support, requirements gathering, design, and even implementation are areas that are affected by the introduction of an SOA. Organizations can incur cost in restructuring their teams and establishing a new process, however they can also realize benefit from these enhanced processes by sharing or consolidating common activities. For example, costly software testing can be positively affected by an SOA, because consumers of services only need to be concerned with the service contract, not with the actual service implementation. This, in turn, allows the service implementation to be tested independently and consistently, thereby reducing both the cost and time required for software testing.

The next attribute to consider in ROI measurement for SOAs is the technical architecture itself. Various aspects that require development disciplines and methodologies must be defined and adopted. With the modularity of an SOA infrastructure, companies can measure benefits from the architecture in several ways. Modular systems are easier to modify and update or upgrade, leading to significantly lowered maintenance costs for existing IT systems. Also, SOA maximizes reuse of existing applications, using investments in the IT infrastructure.

Another area to think about in any ROI discussion is the SOA runtime infrastructure itself. Certain software infrastructure products must be acquired, installed, and managed, such as a message bus, a database, application servers and potentially many other components depending upon the need of the business. Despite the decline in cost of SOA-enabling technology, availability of SOA knowledge can require investment. Once in place, however, the runtime infrastructure serves as a single place where common plumbing for all solutions would be service from, allowing for the application parts to be focused on functionality, and not infrastructure, thereby reducing the time in which new solutions are deployed.

The final area to consider is the impact an SOA can have on revenue generation or simply enhancing the business model in general. Because SOAs allow for a focus on improved alignment of technology with business needs, a good area to measure is the enhanced business or product support (whichever the case may be) an SOA can provide. Special attention to well-focused, departmental or business-unit-level application projects driven by specific business requirements such as self-service portals, call center integration, etc. can demonstrate enhanced revenue capabilities in some cases.

The biggest shift I see is the (finally) holistic view many IT organizations are taking regarding their systems and infrastructure. Consolidation of redundant functionality is being architected into common components and standards are being placed on core infrastructure, such as the message bus, the application server, and a few others. The purpose appears to be business needs such as:

- Adopt flexible, enterprise-wide computing strategies that facilitate tighter integration with customer processes and give customers more visibility to their data.

- Move from a organization-centric to a customer-centric approach where disparate business processes are consolidated and automated for greater efficiency and customer satisfaction.

- Integration with customers and other community members in order to deploy new services to customers faster for increased revenues.

From the technology teams themselves, they appear to have additional reasons in the consolidation trends, such as:

- Reduce delays, errors and inefficiencies in integrating internal lines of business and applications on a single architecture to unlock information trapped in the back, middle and front offices.

- Allow multiple, secure and integration points into the organization for ubiquitous access and collaboration from anywhere.

- Address business requirements with solutions that match the technology to actual business needs so the organization can extend visibility and efficiency across real-time interactions with trusted partners.

Both the business and technology sides appear to be in sync with respect to a common architecture in many cases. Adopting the consolidated strategy however is going to be challenging for these organizations, to say the least. Here are some of the trends that appear to be resulting in some measure of success in our customer’s environments:

- Lower expectations related to service-enabling all existing systems. Leverage business knowledge and expertise to identify core functionality required, and start with those systems.

- Consider what is in place that can be leveraged, and make use of if where possible.

- Process, governance and procedures are necessary to ensure success.

- Deliver incrementally, start small from a delivery perspective, but always consider the entire system from a planning and design perspective.

- Act immediately, start now and leverage agility to ensure deliveries are small but regular and incremental. Begin with pilot projects and move on to more complex projects from there.

- Collaboration with business stakeholders is critical, instead of trying to discover, define, rationalize, etc. functional requirements from solely a technical perspective.

- Use a single place to post/register/manager/etc artifacts such as documentation, interfaces, code, and tracking information.

- Spend some time determining the most relevant security policy.

- Pick an asynchronous message bus and stick to it. This will take care of how messages will be sent or received among services and applications, and will save tremendous time because non of the low-level integration that had to be done in the past (like opening sockets and formatting messages) has to be worried over.

- Make use of a dash-board solution for monitoring the health of the services.

At the end of the day, SunGard customers are taking things one-step-at-a-time, but with an overall view of things globally, so that each choice is made in the context of the overall system, yet implemented in phases or steps.