Make Technologies Whitepaper How to Eat an Elephant: Strategies for Portfolio Modernization There s an elephant in the room that nobody s talking about. This is the legacy portfolio that supports business-critical operations, but threatens the organization s ability to respond to change. The need for organizations to modernize their application portfolios has never been clearer. In many organizations, legacy applications are consuming upwards of 65% of the IT budget. But smart organizations need to become leaner and more agile. This is a potentially difficult goal when an aging application portfolio that is inflexible and expensive to maintain, consumes the resources needed to implement new strategies. Suite 1920 1188 West Georgia Street Vancouver, BC Canada V6E 4A2 T 604.738.4999 F 604.738.4979 TF 1-866-678-6253 E info@ W
It s not surprising that IT leaders are dramatically changing their thinking when it comes to application modernization. Once an afterthought, modernization is now viewed as the best opportunity to cut costs and free resources for new projects. In fact, rationalizing their application portfolio is this year s top CIO concern 66% of IT decision makers consider legacy modernization a critical or high priority for the next year 1. Savvy business leaders are realizing the value of modernization; now, it is simply a matter of determining where to begin. The way to get that elephant out of the room is one bite at a time. A practical, step-by-step modernization solution is needed to align technology with business needs for better, lasting results. The Problem with Aging Application Portfolios Aging application portfolios are putting many organizations at risk. They are eating up valuable resources while important IT initiatives that could actually differentiate the business are being deferred due to lack of time and/or money. These threats are greater than most organizations care to imagine: Lack of Business Agility. No business can compete without quickly responding to competitive pressures or regulatory changes. For instance, the ability to deliver goods and services through emerging channels such as smart phones, tablets and social media is a competitive advantage when trying to attract a younger demographic. But legacy systems were never architected with these newer technologies in mind. This puts your organization at a severe competitive disadvantage today, and going forward. High Operational Costs. IT departments are spending the bulk of their application budgets just keeping the lights on. Aging portfolios are eating up valuable resources while important IT initiatives that could actually differentiate the business are being deferred due to lack of time and/or money. Loss of System Knowledge. Every time an employee leaves the organization or retires, knowledge flies out the window. The loss of legacy system know-how and skill sets, which are difficult to replace in the current labor pool, can have a significant impact on the effectiveness of the IT maintenance organization. Enhancement Backlog. New enhancements to older systems, even those perceived as relatively simple changes in functionality, can require significant design, development and testing effort to implement. As a result, many organizations reject or defer making changes to these systems, creating a backlog of pent-up business demands for enhancements. 2
The Road to Modernization It s true that there is more than one path to the top of the mountain. It s equally true that if you don t know where you are going, any road will get you there, as famously stated by the Cheshire Cat in Lewis Carroll s Alice in Wonderland. The point is that to map out an appropriate modernization strategy you first need to establish a set of goals and principles to guide the journey. The goals should establish your direction. The principles should guide you to make appropriate choices along the path. Goals may be articulated as business or technical drivers for modernization, or described as an end-state vision. Principles are typically non-technical statements of values or priorities. They may address factors such as: The organization s urgency and risk tolerance. Specifically, do we need a pedal-to-the-metal strategy or a more cautious approach incorporating pathfinder projects; The commitment to retain and re-skill existing IT employees to support the new target technologies; Preferences for buy vs. build modernization strategies; as well as, The ability or willingness to change existing business processes to fit Commercial Off the Shelf (COTS) packages. The development and confirmation of these goals and principles at the outset will assist business sponsors to evaluate alternative modernization approaches and establish a program that best fits the organization. Where to Begin How do you eat an elephant? The simple answer is one bite at a time. The more important question is: Where do I begin? To answer this question, the organization needs to start with a Portfolio Assessment, which should include the following actions: 1. Inventory the Applications in the portfolio, including: What do we have and what do they support? What s the source of these applications (in-house developed, licensed from a package provider, etc.)? What are the technologies per application? Who s the system owner (e.g. business unit)? 3
2. Assess each Application or Component within the portfolio. This is generally accomplished via interviews with business and technical stakeholders, using structured questionnaires or surveys. Key dimensions to be assessed include: Uniqueness to the Business: Does this application support processes that differentiate the business or does it support standard or commodity business processes (e.g. standard accounting functionality)? Can the organization change its processes to fit a package or would it have to tailor a package to fit the business? These are key questions to answer, as they re fundamental to the development of a successful modernization strategy. However, some organizations may question their ability to make an objective assessment of their own uniqueness. The best way to validate the self-assessment is to use the inventory of business processes and use cases created during the Portfolio Assessment, as input into a market scan and initial fit gap analysis of Commercial Off the Shelf (COTS) package alternatives. Business Fit: How well does the current application meets the business s current and emerging requirements? Business Importance: How critical is the application to business operations (e.g. is the business able to operate if this application is down)? Alignment to business drivers: Is this application critical to the achievement of strategic business or program objectives? Technical Value: This includes stability and maintainability, as well as technical architecture and platform: e.g. legacy vs. contemporary technologies; strategic architecture or an orphan; etc. In addition, if the application or component is licensed from a software provider, you want to consider the long-term costs and viability of the vendor. 3. Identify Disposition Strategies. After conducting a thorough investigation and analysis of your existing portfolio applications, disposition strategies need to be developed for each application or component (refer to the discussion of Standard Modernization Approaches below). Standard Modernization Approaches There are two high-level approaches to modernization: strategies that extend the life of legacy systems; and strategies that retire legacy systems. This section summarizes the different application disposition strategies within these two approaches, and provides a brief discussion of their pros, cons and trade-offs. 4
Extend the life of Legacy Approaches Defer Action Service Oriented Architecture (SOA) Wrapping Automated Code Conversion Re-hosting Out-Sourcing Discussion This is a valid disposition strategy when there is no compelling business or technical driver for modernization. Absence of business and/or technical drivers for modernization suggests that the current application and platform will adequately support the business operation or process for the duration of the current planning period. Delaying action could also be a cost-deferral strategy when only high-priority applications are modernized, and lower-priority applications are sustained on the legacy platform. This strategy needs to be evaluated in terms of the on-going sustainment costs of the legacy platform vs. potential cost-benefits of migrating to a lower-cost contemporary technology platform. Primarily a portfolio integration strategy. Existing functionality is encapsulated with reusable services that can be utilized by other applications. Still leaves legacy system in place, and does not address functional or technical constraints of the legacy system. Using a 3rd party code converter, the legacy source code is automatically converted to the target technology (not available for all technologies). This is a short-term or interim strategy when the business requirements and codebase is stable, and there is a strong business case to migrate quickly to an alternate platform (e.g., cost-avoidance). The problem with code conversion is that the generated code is not well structured, often larger than the legacy codebase, and difficult to maintain. In fact, some users discover that it s easier to maintain the legacy code and regenerate vs. maintain the converted code. Consequently, automated code conversion is not a foundation for long-term investment in strategic applications and business growth. Re-hosting may serve as a short-term solution when there is a strong requirement to migrate to a different platform. There are minimal changes to the applications and the system retains most of the legacy architecture and code base. Consequently, re-hosting does not address functional or technical constraints of the legacy system. Out-sourcing involves the contracted transfer of operational support and maintenance of systems to a third party. These agreements are typically multi-year agreements, and in some cases may also involve the transfer of staff. This strategy is primarily a cost-reduction approach, based on the assumption that out-sourcing specialists can deliver comparable service levels at lower costs than the organization. Specifically in the public-sector, there may be perceived short-term benefits to the transfer of costs, services-level commitments, or other contractural liabilities to a third party. In most cases, there are minimal changes to the applications and the system retains most of the legacy architecture and code base. Consequently, out-sourcing only extends the life of legacy, as it does not address functional or technical constraints of the legacy system. Nor does it avoid long-term upcharges by service providers to maintain these legacy systems. 5
Retire the legacy There are three primary disposition strategies that both retire and replace legacy systems: Approaches Commercial off-the-shelf software (COTS) Re-Architecture (i.e., TLM ) Custom Application Development (CAD) Decommission Discussion Replaces Legacy with a commercial package(s) Viable option for replacement of legacy applications when standard business or technical functionality is met by COTS packages with minimal customization, and the organization is prepared to change their business processes to fit the package (e.g., standard accounting functionality or enterprise reporting solutions). Not a viable option for processes and functionality that differentiate the organization, and/or the organization is not prepared to change their processes to fit a COTS solution (e.g. applications that provide competitive advantage or enable jurisdiction-specific policy or regulatory compliance). Transformational Legacy Modernization (TLM) is MAKE Technologies Inc. s proven & fullyintegrated platform for application re-architecture. In this whitepaper, TLM and re-architecture are used interchangably. Migrates current business-critical functionality; eliminating obsolete functionality and/or technology-specific code; while incorporating architectural best-practices (e.g., SOA, security model, multi-lingual and improved maintainability). The value of TLM is the ability to harvest Intellectual Property (IP) from the existing legacy system, and re-factor this IP into a well structured modernized system that: provides higher service levels; has lower costs of operation; and can be further enhanced to meet emerging business requirements with lower costs & risks than the existing legacy systems. Re-architecture is best suited for retiring applications or application components that remain business-relevant; differentiate the organization; and when the organization is unwilling or cannot change their business processes to fit a package (e.g., competitive differentiation or regulatory compliance). Code quality is equivalent to CAD. This approach retires the legacy application with new custom developed software. The project follows the traditional software development process from requirements, to implementation either using Agile or traditional software development methodologies. A CAD process is lengthier than other modernization approaches because additional work products must be created to ensure that required and appropriate functionality is built (requirements, additional analysis and design documentation). While there may be some reference made to legacy functionality, there is very little reference, if any, to the legacy code. This strategy is recommended to implement new or emerging business requirements that are not adequately expressed in legacy systems. This strategy is not recommended for the replacement of primarily business-relevant legacy systems, as CAD does not incorporate methods and tools for harvesting IP embedded in these legacy systems. Applications that are no longer needed are simply decommissioned. These can include situations where the current functionality can be delivered as part of the functionality of another application, or the previously supported business requirements are now obsolete. 6
Candidate Disposition Strategies Once the portfolio has been inventoried and assessed, the next step is to assign candidate disposition strategies to the various components. The following figure illustrates a portfolio map created by information gathered during the Assessment: In the above figure, Applications are mapped on two dimensions: 1. Business Fit of Legacy: How well they support the business s current and emerging requirements; and 2. Uniqueness of Business Processes: An assessment of whether the supported business processes are commodity processes (e.g. standard accounting processes) or processes that differentiate the business (e.g. provide competitive advantage or support jurisdictional-specific requirements). The size of the application bubbles in the above portfolio map, represent the relative Business Importance of the applications, as rated by the business. Fitting it All Together The following figure summarizes candidate disposition strategies superimposed on the portfolio map: 7
As previously discussed, under Standard Modernization Approaches: COTS: is a candidate strategy to replace commodity functionality; Re-Architecture: is a candidate strategy to replace systems that are still business-relevant (fit is good) and differentiate the business; Re-Architecture + Enhancements: is a candidate strategy to address systems that differentiate the business but may not fully support new or emerging requirements2; and CAD: should be limited to delivery of net new requirements when there is little or no legacy support. In the assignment of disposition strategies to legacy portfolio components, there are generally areas of clear choices, and some areas of overlap or ambiguity as to what is the best modernization approach for specific portfolio components. The refinement of these dispositions may be influenced by an organization s principles (e.g. a preference for build vs. buy), but they should be confirmed through an objective assessment of options. The approach we recommend is to use the findings from a Portfolio Assessment, specifically the inventory of business processes and use cases, as input into an initial evaluation of COTS options. This will provide the organization with an understanding of what s out there, how well it fits, and what would it cost to replace specific components with COTS. Armed with this additional intelligence, the organization can make more informed decisions and refine their approach. It s important to that realize that one approach is not the best solution for all portfolio components: COTS packages will NOT differentiate the business; COTS costs & risks escalate significantly with customizations; Re-Architecture leverages existing assets & retains differentiation; and Custom development projects have the highest failure rate and lowest ROI. Building the Roadmap Once current portfolio applications have been assigned to a disposition strategy, you next have to think about grouping these applications into manageable work packages (group of applications being modernized as a single project). These work packages need to be organized into a multiyear modernization program, or Roadmap. Here s what organizing your Roadmap involves: 1. Group applications with common Disposition Strategies into projects or a program of projects (e.g. COTS projects, Re-architecture projects, custom application development projects). Within Disposition Strategies: Group applications with high levels of Interdependence (defined by high numbers of programto-program calls between systems, or shared table accesses) into common work packages to 8
minimize the need for developing temporary back-integration strategies between modernized and legacy systems; and Split applications that have low levels of Interdependence into separate work packages (see diagram below showing a visualization of data table accesses within a portfolio of core business systems). Address as a Single Project Candidate Pathfinder Project Table Accesses from Core Systems 2. Sequence applications or work packages according to: Business Importance: High priority to low priority; Application Complexity influences project risk and should be considered in high-level sequencing. Specifically, high complexity applications are not good candidates for Pilot or Pathfinder Projects. Logical predecessor/successor relationships, such as workflow, business process or data entity lifecycle need to be considered in Roadmap sequencing. This is generally an iterative process that incrementally refines an initial approach into a roadmap that properly balances the organization s modernization vision with the disposition strategies and priorities assigned to specific applications and work packages. The following is a brief list of considerations that organizations may also want to consider in the development of their Roadmap: Managing Costs: In general, fewer larger projects are more cost-effective than many smaller projects due to the management & staffing overheads associated with each project. Speed to Market: Understand your priorities and constraints, and group and sequence projects accordingly. Smaller projects are typically shorter in duration. However, if you have a number of applications that need to be replaced within a tight timeline, one or a few larger projects can often be completed faster than multiple small projects if they have to be staged & staggered. 9
Managing Risks: Business Sponsors and Stakeholders need to understand the impacts, costs and benefits associated with introducing new functionality and/or changes into the modernization project. Architectural upgrades, streamlining and most enhancements can be incorporated into the initial modernization release with manageable risk. However, changes that transform the behavior of the modernized system relative to the legacy system may be difficult to test/validate and therefore may be implemented most cost-effectively in a later post-modernized release2. Retaining & Retraining Employees: Organizations that are committed to retaining employees can use modernization projects for skills transfer and retraining employees in new architectures and technologies. In this scenario, it is advised that high-priority but low complexity applications be identified as potential Pathfinder projects. Resource levels and schedule should be adjusted to support coaching and skills transfer on these projects. It is important to note that the Roadmap is not a cookbook; it s a guidance system. It provides a framework for the multi-year modernization program. It must be tolerant to adjustments in course and speed, and evolve to accommodate changing organizational priorities and constraints. Conclusions There are a number of alternative modernization strategies. Some strategies are best used to extend the life of legacy systems, including: SOA-wrapping; automated code conversion; and re-hosting. While other strategies are designed to retire and replace the legacy environment, such as Commercial Off-the-Shelf (COTS) package replacement and re-architecture. These strategies are not mutually exclusive and should be considered in a best-value portfolio modernization strategy. With intense pressure to cut costs and stay competitive, virtually every large organization is looking for ways to assess their current portfolios, identify fit-for-purpose disposition strategies, and, where needed, modernize its legacy systems safely, efficiently and cost-effectively. Modernizing these business-critical legacy systems can be a low-risk and cost-effective solution to conserving critical organizational IP, when planned, managed and delivered by an experienced modernization partner using a proven, fit-for-purpose approach. Make Technologies enables companies to do just that: to understand what they have, to identify appropriate disposition strategies for their portfolio components, and to structure these projects into a multi-year program that balances business priorities with costs and risks. Make Technologies develops a tailored modernization strategy that meets your organizational needs within your specified time frame. Get the best tailored approach for your modernization project now and learn how we can help achieve success. About Make Technologies Make Technologies is a leading global provider of legacy modernization software and services. Founded in 1999, Vancouver, B.C. Make Technologies has helped customers in a broad range of industries including finance, healthcare, insurance, natural resources, distribution, communications, and government. Make Technologies is a trusted brand in enterprise legacy modernization initiatives with partners like Deloitte, Oracle, and IBM. Copyright Make Technologies, Transformational Legacy Modernization (TLM ) are registered trademarks of Make Technologies in the U.S. and/or other countries. All other trademarks or registered trademarks referenced are the property of their respective owners. 1999-2011 MAKE Technologies Inc. 10