Michael Blechar

Scope of the Application Architecture
In research note “Defining the Discipline of Application Architecture*” Dan Sholler and I addressed the scope of the role of the application architect, including how application architects establish when and how legacy applications are to be wrapped or split apart as software services, and which new software services are to be developed. The application architect publishes design artifacts and assists the enterprise architecture team, application portfolio managers and software service providers in promoting enterprise leverage of software services and design artifacts. All this needs to be coordinated across releases of the application portfolio as part of the evolving "work in process" transition toward the future enterprise solution architecture.

Importance of Coordinating AA and Legacy Retirement and Modernization
An important aspect of evolving the current application architecture forward is coordinating the building of new software services, integration of packages, etc, with the retirement and modernization of legacy applications. My colleagues Dale Vecchio and Kathy Harris did an excellent job of discussing legacy modernization in their research note in January called “Toolkit: Modernization — The Case for Change and Top Five Actions*”. Now, I would like to also point your attention to a new research note by my colleague Jim Duggan called “Plan Legacy Application Retirements Carefully*”. A sample of the issues Jim addresses in the note includes:

Where Do Applications Go When They Get Old?
Applications often outlive their usefulness. Functions are duplicated by "sister" organizations, acquired during mergers or included in new packages. Changes in business processes, architectures or operational needs may render an application obsolete. On average, 10% of the applications in an un-optimized portfolio are candidates for retirement. An additional one-third can require migration or rationalization.

Gartner has observed that organizations frequently lack explicit retirement processes. As a result, they struggle to:
·    Agree on which applications should be retired
·    Commit funding and resources to retirements
·    Define and execute an application shutdown that doesn’t create undue anxiety, risk or inconvenience among the operations staff and the business users

As a result, the business wastes money continuing to pay for, run and maintain the application. Scarce resources are consumed by software that is of only marginal use to the organization.

Selecting Applications to Retire
Application portfolio management (APM) processes commonly guide the selection of which applications to retire, as well as establish the business cases for retirements, migrations and consolidations. A company with an immature APM process may have difficulty targeting retirement candidates, after they’ve identified the early, obvious targets. One remedy is to evaluate potential retirements as part of new or enhanced projects.
Start with a preliminary list from those responsible for APM, or from application functions related to the new development. Then narrow that list, using first-level business data, including:

·    Cost to maintain the application
·    Applications that may have replaced the function
·    Technology or resource considerations

In Summary
While it is possible to do application architecture ”bottom up” in terms of leveraging new development project work, to optimize application architecture efforts organizations should use a collaborative approach across projects and architectures. A sound legacy retirement and modernization plan is a key component in effectively evolving the current application architecture forward towards the future enterprise solution architecture in a cost efficient manner.

*Available to Gartner clients or for a fee

Submit a Comment »

Category: Uncategorized     Tags:

Share