Special Reports
Integration Is Key to Simplifying Application Architecture
If you want to simplify your applications portfolio to achieve your enterprise architect vision, think ahead to the next stepping-stone toward your goal.
Our previous column on stepping-stones for aligning business management and enterprise architecture (Enterprise Architect, Summer 2003) identified the first priority as clearly articulating your architecture vision in the context of the value it brings to the execution of the business strategy. Here, we discuss how a critical architecture objective—simplifying your applications portfolio—can be accelerated by applying this important principle.
You've probably tried to make a business case for simplifying your applications portfolio. But the more applications you envision in the "retired" column, the costlier the effort seems to become. You know the right decision is to retire a large number of obsolete applications. The complex architectures surrounding old applications often cause big business losses from increased product development times, lost sales, and high support costs. (How much was the last support invoice for one of your legacy mainframe applications?) Then there are the increased IT costs for application development, maintenance, and assorted Band-Aids. However, these losses are hard to segregate and quantify, while it's even harder to demonstrate the link between business benefits and IT architecture investments.
The Costs of Simplification
If you're like most managers, you're probably building your case for a simplified architecture solely on changes to your current IT portfolio. You estimate the cost of cutting the obsolete applications, or of walling them off (that is, no new development for additional features, extensions, or modifications), and then of integrating the changes into your architecture. These business cases often look bleak, with negative net present value or long payback periods, because of the large up-front investment for rebuilding interconnections and replacing the functionality housed in the obsolete applications.
A better approach is to combine the applications assessment with the value of a comprehensive integration strategy—one that keeps the costs of rebuilding interconnections at a minimum. After all, integration ends up being 30 to 60 percent of the cost of simplification. As you find strategic ways to integrate all of your proposed application changes, your costs are spread over all these interconnections and they diminish considerably. Even better, you can combine these lower costs with reduced business risk, stronger alignment with business goals, and less need for costly resources. The business case suddenly looks brighter. You finally have a compelling case for action.
The stumbling block is that the option value of this simpler application architecture in enabling business growth is often difficult to quantify and validate, and hence is not used widely among IT practitioners.
The trick is to try a broader approach to your simplified application architecture. Rather than start with dissection of your IT application portfolio and an assessment of which applications you can feasibly retire, start with the integration strategy. Determine how much effort is going into interconnecting the applications, and reduce these costs by a clean integration approach (for example, with integration servers for application-to-application interconnection). Then revisit simplifying your application portfolio using the new integration strategy. Plan a phased approach over three years. Finally, factor in the business value: lower business risk, alignment with business strategy, reductions in IT support, and increased visibility into IT investments.
Since application interconnections can contribute up to 60 percent of the cost of a simplified architecture, it's a natural place to look for cost savings. The key to lowering interconnection costs is to map to an integration strategy up front, and then determine which applications are least costly to retire or wall off within those lines.
Map Your Integration Strategy
You'll need to create your strategy by matching the interaction type with the integration tool. For example, do your applications participate mainly in system-to-system transactions? Typically these applications are connected by point-to-point interfaces, without adhering to software engineering principles. Their architecture contains business logic that is often not encapsulated or presented through a well-defined integration interface; the database is not isolated from the interface; and the data mappings are not made once and reused many times. The resulting interface is often in a proprietary language without GUIs, debugging, and testing tools. Making any changes requires a major IT project. These types of applications require an EAI tool to drive the application-focused integration using an integration server.
On the other hand, you need other tools for applications that are not driven by system-to-system transactions. Applications for end users need to have intuitive interfaces, and therefore tend to integrate better using workflow-based integration tools. Those applications that typically don't participate in transactions or processes beyond data extraction from multiple systems are ideal for interconnection to an operational or archival data store. Finally, for environments with robust Web-based infrastructures, consider Web-services-based integration.
Once you have an integration map showing the major integration types and tools, you can evaluate the decommissioning costs of each nonstrategic application according to the integration mechanism defined in the map.
Identify strategic versus nonstrategic applications. The first step in simplifying the application portfolio is to separate applications that will be used as go-forward systems versus applications that are unnecessary. The evaluation will be based on a mixture of business and IT criteria, including how well they enable the business strategy of the company, vendor product planning, and critical limitations (if any) in providing required business functionality.
Then you should refine the categorization based on additional factors such as time period for retiring, ease of providing required capabilities in the interim, availability of replacement applications that overcome limitations in functionality, duplicate or redundant applications in the current application portfolio, and availability of an IT skills set.
Determine which applications to decommission or wall off. Once the decision is made to retire an application, there are two choices: decommission the application or wall it off. When you wall off an application, it becomes ineligible for additional features, development, extensions, or modifications. Only consider this option if decommissioning costs are prohibitively high, since this method will manage expenses but not reduce complexity.
The Business Case for Simplification
Now you are ready to develop the business case. First calculate the cost for decommissioning by considering three main cost buckets: implementation costs for the chosen tool (that is, software license, hardware, training, and adaptor development); costs of building out missing functionality; and costs of migrating data.
Then, as you calculate the benefits, don't forget to include the benefits from the reduction in integration effort for the projects in the development pipeline and the reduction in support costs for service and maintenance requests. In general, you can expect more immediate savings in support costs involving complex system-to-system transaction systems because the EAI adaptors are available and reusable. The potential reduction in integration effort for new projects will vary depending on the complexity of your current application portfolio and business circumstances. For example, a company completing a merger and seeking synergies of a unified architecture may find that benefits of an integration strategy are substantial.
Putting together the costs and benefits, you can build the business case for retiring more nonstrategic applications than you could before you developed an integration strategy. The business case for retiring smaller peripheral applications whose functionality has been subsumed in the newer application can be easily made because they do not require major data migration or additional functionality to be built. On the other hand, for large core processing systems that have been deeply entrenched, heavily customized, and have a large amount of critical data, the typical result of the business case is negative ROI. In these cases, walling off may be the only viable option. You still have an opportunity to manage the support costs of the walled-off application by options such as off shoring or outsourcing.
As you make your way to the first stepping-stone by making the business case for integration, don't forget to involve your business users. While it is your job to set a vision and the implementation plan for the enterprise architecture, it is the business users who will live with the functionality of the resulting application portfolio. There may be hidden business costs that dramatically change the overall business case for the company.
For example, while walling off a legacy order-processing application might be the best decision in light of IT support and maintenance costs, the business users may find that they cannot put in place new pricing strategies required to maintain their competitive advantage. In this case the curtailment of further enhancements to the walled-off application so restricts business-critical processes that business revenue is reduced.
Therefore you need to think ahead to the second stepping-stone—working with the business managers—as you create your architecture vision. Your new vision will chip away at the complexity in your current enterprise architecture that becomes an obstacle to creating real value from IT. While developing the business case can be time consuming, there is real value in rigorously quantifying costs, benefits, and associated risks and in the resulting increased transparency to the embedded constraints of the existing architecture.
About the Authors
Chris Barlow and Janaki Akella are in the business technology office of McKinsey & Company, where they focus on counseling senior business leaders on the effective use of technology. Contact Chris at [email protected], and contact Janaki at [email protected].