Information Systems Transformation: Architecture-Driven Modernization Case Studiesby William M. Ulrich, Philip Newcomb
Every major enterprise has a significant installed base of existing software systems that reflect the tangled IT architectures that result from decades of patches and failed replacements. Most of these systems were designed to support business architectures that have changed dramatically. At best, these systems hinder agility and competitiveness and, at worst, can
Every major enterprise has a significant installed base of existing software systems that reflect the tangled IT architectures that result from decades of patches and failed replacements. Most of these systems were designed to support business architectures that have changed dramatically. At best, these systems hinder agility and competitiveness and, at worst, can bring critical business functions to a halt.
Architecture-Driven Modernization (ADM) restores the value of entrenched systems by capturing and retooling various aspects of existing application environments, allowing old infrastructures to deliver renewed value and align effectively with enterprise strategies and business architectures.
This book provides a practical guide to organizations seeking ways to understand and leverage existing systems as part of their information management strategies. It includes an introduction to ADM disciplines, tools, and standards as well as a series of scenarios outlining how ADM is applied to various initiatives. Drawing upon lessons learned from real modernization projects, it distills the theory and explains principles, processes, and best practices for every industry.
* Acts as a one-stop shopping reference and complete guide for implementing various modernization models in myriad industries and departments.
* Every concept is illustrated with real-life examples from various modernization projects, allowing you to immediately apply tested solutions and see results.
* Authored by the Co-chair of the Object Management Group (OMG) Architecture-Driven Modernization (ADM) Task Force, which sets definitive systems modernization standards for the entire IT industry.
* A web site supports the book with up to date coverage of evolving ADM Specifications, Tutorials, and Whitepapers, allowing you to remain up to date on modernization topics as they develop.
Read an Excerpt
Information Systems TransformationArchitecture-Driven Modernization Case Studies
By William M. Ulrich Philip H. Newcomb
Morgan Kaufmann PublishersCopyright © 2010 Elsevier Inc.
All right reserved.
Chapter OneIntroduction to Architecture-Driven Modernization
Business and IT Challenges 5
Modernization Benefits 11
An Architectural View of Modernization 17
Modernization Assessments 19
Basic Modernization Principles 32
For decades, Information Technology (IT) organizations and the businesses and government agencies they support have been struggling with an ever-growing installed base of software systems. These systems control virtually all automated aspects of a given business or government entity. While maintained out of necessity, these same systems have grown into black-box behemoths of business logic and data representations that continue to stifle organizational agility and the ability of enterprises to move into increasingly competitive markets.
For the vast majority of organizations, these systems have been anchors that dragged them down as they attempted to meet growing competitive and economic demands. IT organizations, driven by the need to control their own internal costs, have responded by outsourcing systems to third parties, building add-on software that replicates aspects of the old systems, plugging in commercial-off-the-shelf (COTS) software packages or enterprise resource planning (ERP) systems, and wrapping systems with middleware. The results have delivered far less than anticipated in many cases.
Every IT and business situation is unique, yet there are numerous parallels in the challenges facing most enterprises today. These issues include:
* Application and data architecture silos that reflect historic partitions in business structures that no longer apply in today's environment * Extensive replication and inconsistency of data definitions and functional logic across application silos * Layers of middleware that have wrapped aging architectures only to mask the need to unravel and modernize these architectures * Systems and user interfaces that are totally out of sync with business processes that require extensive manual effort and countless user-developed, desktop shadow systems (e.g. spreadsheets, Access databases, etc.)
* Diminishing level of expertise capable of managing, changing, or even understanding application and data architectures * Little or no documentation as to how these environments are constructed or function * A lack of understanding by executive teams regarding the impact of these issues and the actions that can be taken to address them for the betterment of the business environment
This last point is probably the most disconcerting aspect of the challenge facing organizations with a significant installed base of existing software systems. Considering the complexity and interwoven nature of many existing systems, this is not a big surprise. Yet, when one considers the criticality of these systems to the continuity and survivability of the enterprise, it is of great concern that software and data assets are largely a mystery to management and planning teams.
The general feeling is that these systems cannot be salvaged or otherwise rehabilitated, so why make an effort to understand them? This belief is so ingrained in organizational thinking that organizations march almost in lockstep toward traditional solutions that have become increasingly ineffective. These traditional solutions involve Greenfield replacement, COTS deployment, and wrapping old architectures with middleware. The historical inadequacy of these traditional approaches to the software challenges facing organizations today will be discussed in more depth in the section entitled "Business and IT Challenges."
Organizations do have an option when it comes to creating more agile and business friendly IT solutions to respond to ongoing shifts in the "business architecture." Business architecture is defined as "a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands." It is called architecture-driven modernization or simply "modernization." Architecture-driven modernization is defined as "a collective set of tool-enabled disciplines that facilitate the analysis, refactoring and transformation of existing software assets to support a wide variety of business and IT-driven scenarios."
The Object Management Group (OMG) defines architecture-driven modernization as the "process of understanding and evolving existing software assets for the purpose of software improvement; modification; interoperability; refactoring; restructuring; reuse; porting; migration; translation; integration; service-oriented architecture; and model-driven architecture[TM] transformation.
The OMG laundry list of modernization topics boils down to three general categories: assessment, refactoring, and transformation. These three high-level categories or stages of modernization disciplines may be mixed and matched to address a wide variety of business and technical objectives.
The concept of modernization has been around for many years. However, the automation capabilities and supporting motivations to deploy modernization projects to support a wide variety of business scenarios have evolved to the point where every organization attempting to understand, evolve, or replace existing application and data architectures now has an alternative to traditional IT strategies. At a minimum, management can augment traditional IT strategies with various modernization options and techniques. The increasing interest and demand for the capabilities delivered through modernization projects are driven by the fact that organizations are now seeking alternatives to historic IT approaches. Historic approaches — Greenfield development, COTS package deployments, and middleware proliferation — have not delivered the business value many organizations originally anticipated.
While succeeding modestly in some cases, many IT initiatives have failed to meet business objectives, encountered major cost or schedule overruns, or delivered significantly reduced value over what was originally anticipated. In most cases, the IT solutions have been interwoven into complex and often convoluted software architectures and only served to add more redundancy and complexity to those architectures.
This chapter discusses the business and IT challenges facing most organizations: the difficulties enterprises have encountered in trying to address these challenges, the benefits of modernization as an augmentation strategy or as an alternative to traditional approaches, and the basic tasks associated with modernization. This includes tracing historic failures of the past as well as looking at how modernization can be used to address a variety of critical business and technical initiatives required by the 21st century enterprise.
BUSINESS AND IT CHALLENGES
Senior executives often think that complex business and IT challenges can be addressed by rebuilding applications from scratch, licensing COTS packages, or tying systems together using middleware-based solutions. While these options continue to play a role in ongoing IT strategies, projects applying these approaches have been plagued with problems.
Corporations and government agencies increasingly find it more and more difficult to address complex information-related challenges. Organizations have spent considerable time, effort, and capital on IT projects with little to show for it. While IT projects in general have been challenged, there are numerous failure stories in the industry. A few of these are cited in this list.
* Cigna's $1 billion IT overhaul suffers a false start, causing the health insurer to acknowledge customer defections. * The Hershey Foods ERP system implementation failure led to massive distribution problems and a loss of 27% market share. * The FoxMeyer Drug ERP system implementation failure led to the collapse of the entire company. * A new IRS system allowed $200 million in bogus refunds to slip through and had to be deactivated. * The Oregon DMV conversion to new software took 8 years to complete and public outcry eventually killed the entire project. * State of Florida welfare system was plagued with numerous computational errors and $260 million in overpayments. * AMR Corp, Budget Rent A Car, Hiltons Corporation, Marriott "confirm" project crumbled having spent over $125 million over 4 years. * A u456 million IT system (from EDS) implemented at the Child Support Agency in UK worked less effectively than the system it replaced. * An IRS project, expected to cost $8 billion when completed, was already 40% over budget with less than $1 billion of work done to date. * "Science Applications International Corp. (SAIC), in San Diego, delivered 700,000 lines of code so bug-ridden and functionally off target that this past April the bureau had to scrap the US $170 million project, including $105 million worth of unusable code." * U.S. Federal Agency cancels $70 million SAP implementation. * An international telephone company canceled a major systems replacement project at a loss of more than $80 million.
These last two examples are not sourced to protect the anonymity of the organizations.
Industry research shows just how challenging it is to undertake major IT projects. For example, IT project overruns are commonplace. The latest Standish Group research shows that IT projects are late 72% of the time — a marked improvement over figures from prior years. Additionally, certain risk factors are reflected in the Standish Group research related to project waste on IT projects. Out of the $364 billion spent on IT projects for 2006, only $204 billion of this amount was considered to have delivered organizational value while $160 billion in IT spending was considered waste.
A related Standish Group finding showed that of all the IT projects analyzed for 2006, only 35% of those projects were considered to have succeeded. This study found that 19% were outright failures (again a marked improvement over prior years) while 46% were considered "challenged." Note that "challenged" means "the project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified."
These studies demonstrate that anytime IT undertakes a major project, management should be suspect of the ability to deliver the project on time and on budget in a way that satisfies business requirements as set forth at the onset of that project. To further illustrate the challenges facing organizations with a significant dependence on a large installed base of software systems, we consider the issues associated with Greenfield replacement, COTS deployment, and middleware utilization.
Greenfield Replacement Issues
Greenfield replacement involves designing, developing, and deploying one or more new application systems from scratch to either replace one or more existing mainframe application systems and/or to automate existing manual processes. It should be made clear that Greenfield replacement, by definition, does not draw on business logic or data descriptions contained within existing application and data architectures. When a project does rely on existing systems as input to the specification and development process, then the project has morphed into a modernization initiative.
Greenfield replacement requires: determining and analyzing business and systems requirements, designing a solution to meet those requirements, designing and developing the actual software to be implemented, testing that new software in the appropriate business environment, and moving the new system into a production-ready state so that business people can use it. The Greenfield approach also requires business people to re-specify and programming teams to re-create years of complex, highly evolved and fairly intricate business knowledge — knowledge that these people are unlikely to command.
Greenfield replacement projects, in our experience and based on industry analysis, commonly result in a combination of project delays, unhappy business users and customers, missing or misinterpreted business functionality and data, and costs that far exceed initial projections.
A Greenfield approach to rewriting application systems takes a significant amount of time, investment, and human capital. Further, the risks associated with omitting critical business functionality that was buried in the old application system and never included in the new system are substantial. The series of industry studies and citations discussed next show how cost, time, and risk-related factors constrain organizations from successful deployment of software systems using Greenfield development.
The costs incurred, per line of code, on Greenfield replacement projects demonstrate the expensive nature of application system rewrite projects. The studies cited provide a range of replacement costs for deployed application systems. The general approach for calculating these costs, based on our experience, involves dividing the lines of software deployed by the total cost of the entire project. These studies provide a useful way to determine the historic cost of Greenfield replacement but are not intended to serve as a project-estimating tool on a project-to-project basis.
Studies have cited line of code replacement costs at $18-45 per line of fully delivered, debugged production software. For example, one cost per line figure that is based on extrapolation of the COCOMO II model is $18 per line of code. A second source cited the cost per line range for developing fully functioning software as $30-40 per line of code. A third study put the cost of developing fully functioning software within the range of u20-25 per line of new code. The pound estimate reflects a Greenfield development cost of $34-43 per line of code. This last citation, which is based on research work using a combination of estimating models, brings the line of code development cost figure to the upper range of the scale — close to $45 per line of code.
Using these numbers, a small company with 2 million lines of software would estimate its portfolio replacement costs using Greenfield replacement in the range of $36 million ($18 per line) to $90 million ($45 per line). In our experience, these costs in practice can even exceed the high end of this cost range.
While costs are a major consideration, the time frames associated with Greenfield replacement can also be unacceptable to organizational management. Rebuilding a system from business requirements using the Greenfield approach takes significant amounts of time. One common statistic is that the productivity generally seen over the life of a project is approximately 10 to 15 lines of new software per person, per day.
Assuming that an organization is planning to rewrite a 1-million line application system using the Greenfield approach, and further assuming this same organization plans to assign 30 people to that project and that each person delivers 3,000 lines of code per (200 work-day) year, it would take those 30 people more than 11 years to complete this project. Note that even if a replacement project team employs computer languages, tools, and techniques that cut this time in half, (which is unlikely) this still represents a 5.5-year project.
These numbers are typically dismissed by programmers who claim to be able to write hundreds of lines of code per day. But these individuals overlook the fact that these industry statistics represent delivered production software from inception to production status. To deliver software to a production ready state, project teams must expend many hours of analysis, design, development testing, and deployment activities. Overall, the numbers revert to the 10-15 lines per day figure even with the advent of new tooling. Much of the real work involves analysis and testing, not just coding.
Excerpted from Information Systems Transformation by William M. Ulrich Philip H. Newcomb Copyright © 2010 by Elsevier Inc.. Excerpted by permission of Morgan Kaufmann Publishers. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Meet the Author
Philip Newcob is CEO of The Software Revolution, Incorporated (TSRI), and an internationally recognized expert in the application of artificial intelligence and formal methods to software engineering. Over the course of 32 years, he has done groundbreaking research in the application of artificial intelligence, software engineering, automatic programming, and formal methods technology to industrial software problems, including 13 years at the Boeing Artificial Intelligence Center as a Principal Computer Scientist before founding TSRI in 1995. Mr. Newcomb formulated the conceptual product framework and led a team of computer scientists to develop the software transformation technology and products offered by TSRI.
Most Helpful Customer Reviews
See all customer reviews