Enterprise Architecture Program continued… Once you have chosen a business area where you can start with, you could potentially conduct application portfolio analysis on that particular business domain. Within this portfolio analysis, you should be able to identify and collect application characteristics such as

  • Owners
  • What operating business functions and processes does it support?
  • Physical characteristics such as O/S, version, software
  • Operating matrix such as cost, license, help tickets
  • Shared service characteristics such as integrations, dependencies

At the end of this exercise you would have built a good meta-data about your application portfolio. This will help you to categorize your applications into “3C’s” (CORE, CRITICAL and CONSTANT)

CORE: These applications support the core business functions, such as Origination, Finance, Human Resource, and Customer Service etc. [example: Data Warehouse, ERP, CRM etc.]

CRITICAL: These applications support the critical daily functioning of the core business, without it, the business cannot operate and is at risk [example: Application Intake System, Order Entry System, Customer Support System – A data warehouse can be core but may be not critical for some business, as mostly it is historical data for analysis and data are loaded in batch]

CONSTANT: These are applications that do not make any differences for the business, or in other ways they are constant, whether they exist or does not exist it will not affect the daily operation of your business [examples: John Doe’s Access Database keeping track of Sale Department expenses, Mary Jane personalized and customized daily reporting for her boss, a custom data hub that is used by marketing department for keeping reference of old products]

application portfolio analysis

The next step in the process is to categorize these applications into “4R”, RETAIN, REDUCE, REPLACE and RETIRE.

RETAIN: These are application that had previously classified as critical and (or) core supporting one or more business. These applications are built on a modern technology platform, and have seamless integration capabilities and are considered strategic long-term investments.

REDUCE: These are applications that are currently considered “stable” supporting one or more core business functions. They possess some limited integration capabilities and are not “at-risk”, and are not built on standards based technology. However, the continued use of these applications in long-term will need hardware and software upgrades and thus need its modernization. The application will not accept any new functionality and will reduce its offering of functionality in long-term until it is replaced and retired.

REPLACE: These are applications that are considered at risk of supporting one or more core or critical business functions in near-term. This application supports business processes that are considered critical, however are built on an older or legacy technology platform. These applications are need to be replaced and migrated into a newer and modern technology.

RETIRE: These applications may be a constant or core, and are not critical. The continued uses of these applications are considered not the best interest to the business. Some of the business processes may be considered to migrate into future plan.

The next step is to conduct business process re-engineering and design. During these stages, you may speed the design activities by starting your infrastructure design and infrastructure architecture. The To-Be Architecture guidance can be utilized to build your new technology and infrastructure capabilities. Thus, while you conduct business process re-engineering and probably some functional design, your infrastructure could be ready in parallel. Detailed functional and technical design follows the business re-engineering phase. At this time of the phase, you would have finished collecting some of the domain specific business (or all) requirements to further develop into technical services.

Most of today’s modern technology transformation program, SOA is an inevitable component. It would not be surprised if you will be transitioning your legacy applications into service based and standards based technologies. These may also include establishing some common shared services platform such as ERP, developing business intelligence and reporting capabilities, CRM and integration platform utilizing a standard based ESB and other security and monitoring tools and frameworks.

You could now introduce PMI methodology, Agile or SCRUM to develop your services. SOA development, data management and other areas of development are intentionally left out from this topic for later discussion. Now, you could go back and revisit some of your architecture governance and control processes for reviewing your design and build documentation. At this stage of the program, you may have well found the entry point to start your modernization program, as well as executing your enterprise architecture plan. Effectively, you just started your enterprise architecture program. Monitor, control, listen, learn, tweak and improve your processes as it progress.