Light Dark

What is Application Portfolio Management?

Application Portfolio Management (APM) is one of the most commonly found initiatives in enterprise architecture. At its core it’s one of the simpler initiatives within the EA toolbox, gathering all of your application data into one place so it is easy to manage and maintain. Many organizations use far more applications than they realize, and so APM gives decision makers an easy way to understand what applications they are using and what applications they are not using (but still paying for!).

 

Application by Category Landscape - Lifecycle

Successful Application Portfolio Management (APM) requires an inventory of your company’s applications together with metrics to understand their fit and value to the business. From here, organizations can engage in activities like application rationalization, mapping applications to specific business capabilities (or identifying capability gaps), and application roadmapping – planning around application lifecycles and vendor support offerings.

In the past, APM didn’t require much more than an Excel spreadsheet or a database, but as the complexity of application portfolios has grown it has increasingly come under the control of enterprise architecture functions. EA tools like iServer365 offer a wide array of features designed to support APM, and having application data in one place often enables other EA initiatives like those mentioned above, or projects like migrating key applications to the cloud.

 

 

Overcoming the challenges of APM modeling with a tool

 

Modeling Application Portfolio Management data using an  EA tool can be challenging, even with a fully-featured platform like iServer365. The meta-model is often designed to store artifacts across a number of domains and, depending on the product, usually in a lower level of detail than portfolio managers require.

 

 

Challenge 1: Selecting the Best Meta-Model

 

Once a tool is selected, the next step is usually to decide how to structure the meta-model – although some of the more prescriptive tools mandate a meta-model, this may not always be the case. This is often the biggest challenge to overcome since it defines the structure of the data and therefore heavily impacts the effort required to manage the data.

Further to this, the meta-model selected will affect the ease at which users can access the APM data, to some degree the complexity of the data capture, and input exercise along with the effort required to construct any custom viewpoints.

There are of course numerous meta-models which offer support for application architecture, most of which are vendor specific. Some standards do exist in this area in the form of the TOGAF content meta-model and ArchiMate’s meta-model also provided by the Open Group. Using these standards comes with its own set of challenges.

TOGAF Content Meta-Model

 

Pros: Easy to Use; Easy to Learn

Cons: Perhaps overly simple compared to ArchiMate; Limited Attribution defined on object types

Summary: TOGAF offers an extremely simple meta- model, providing only three object types in the application architecture area (Logical Application Component, Physical Application Component & Information System Service), with only three relationships between these objects.

This makes the TOGAF meta-model easy to learn and easy to format / load data. With this simplicity comes an inability to model things such as application functionality explicitly

TOGAF Content Meta-Model

 

ArchiMate Meta-Model

 

Pros: More Descriptive; Well designed for Ease of Use

Cons: More Complex compared to TOGAF; Limited Attribution defined on object types

Summary: ArchiMate provides a more complex meta-model, allowing for more object types and subsequent relationships in the application architecture area such as Application Interface, Application Function, Application Service, etc. With this complexity comes both the ability to become more descriptive and the requirement to learn more about how the model can be built.

Although this meta-model is more complex it has been constructed with a great deal of logic, and includes concepts such as relationship strength, which helps simplify the otherwise complex meta-model.

It should be mentioned that although these meta-models are commonly used, it is possible in tools like iServer365 to design and build a custom meta-model. This undoubtedly takes more time and requires significant effort, but it means the meta-model can be constructed in a way that simplifies data management, capture and load.

This also enables organizations to use terminology they are familiar with rather than learning a whole new language

Challenge 2: Viewpoint Selection

 

When content is stored in the selected model using the selected tool, the next challenge is the selection of suitable viewpoints. These viewpoints will expose the information collected through reports, diagrams, documents, and such.

Since these viewpoints will become views and expose the content captured to the organization, it is imperative that they are well received to ensure the messages contained in them are understood.

Further to this, the meta-model selected will affect the ease at which users can access the APM data, to some degree the complexity of the data capture, and input exercise along with the effort required to construct any custom viewpoints.

Whilst there are many factors impacting the success of  Enterprise Architecture (EA) departments, one critical enabler is the accessibility, readability and clarity of deliverables such as application architecture viewpoints.

With some suggesting that the failure rate for EA departments sits at around 40% and that successful teams are struggling to have impact and gain recognition, viewpoints could be an important area for EA teams to focus their attention.

When it comes to viewpoints, there are a number of them suggested by both TOGAF and ArchiMate, but most of these viewpoints aren’t focused purely on Application Portfolio Modeling (APM). With a few exceptions, TOGAF and ArchiMate viewpoints show cross domain linkages or the environment of the application.

As we have already established, both TOGAF and ArchiMate have only a handful of attributes which support APM, and a few viewpoints which would be of use. With this in mind it could be deemed necessary to extend these standards with custom viewpoints, which can be tailored to meet the organization’s specific needs.

What are the Benefits of Application Portfolio Management?

 

The name sums it up rather well – gather all of your applications into a portfolio and manage that portfolio to ensure the best return from your apps, typically through cost saving opportunities. Most consultancies even have their own marketing material for APM initiatives. The story that these materials tell is generally the same – find the applications that are duplicates and consolidate them, find the applications that you don’t need and get rid of them, saving ongoing cost in both cases.

Which is true as far as it goes, except that what happens if there aren’t as many opportunities for rationalization as hoped? Or what if the costs of rationalization are significantly higher than expected?

If you have, say, a bank or a pharma company that has grown by acquisition then yes, you’ll likely have plenty of duplication between different units to address. And yes, plenty of organizations may have different departments that have separately implemented similar or the same applications. But going in, you won’t know (which, let’s face it, is usually the point – if they had their portfolio identified and under management then they wouldn’t need the APM initiative). So, what happens if the potential savings are disappointing either due to lack of opportunity or high lock-in costs?

Fortunately, there are more benefits to establishing an application portfolio than just rationalization opportunities, and knowing about them means that we can set the expectations up front about a range of the possible benefits that we expect – and ensure that we work to accomplish these benefits during the exercise.

First of all is consistent reporting. Establishing the identified set of applications, with consistent naming, opens the doors to integrated statistics. For example, if the finance department knows a given application by one name and the trouble ticketing knows it by another, how can you produce integrated statistics? Even worse is when different groups within the organization know the application by different names – and record tickets or implement projects under these names. So having an established portfolio of applications is an essential step to ongoing analysis of the applications the organization has.

A second benefit of an application portfolio exercise is that it can often expose unnoticed areas of risk – for example, through use of inappropriate technologies or working practices that may even have been safe at one time but have become unsafe due to other changes in the IT estate. As an example, in one recent project we found that while all applications using sensitive data had been migrated away from access databases several years before, the access databases in question had been left dotted around their respective file shares, still containing sensitive data with only 40-bit encryption to protect them.

A final benefit is that, where the application portfolio exercise is allowed to go and talk to the application owners (we've encountered places where this has not been the case), they can validate the problems and needs that the normal IT demand management channels are reporting. In our experience, it's highly unlikely that the application portfolio team would they'll hear anything different to what's already being reported... yet it's basic human psychology that having another voice confirm something lends a surprising amount of weight to the original voice that reports it. So the APM exercise becomes an opportunity to build trust in this respect.

Download report

How to Architect Enterprise Resilience

Everyone is talking about business resiliency, but too often, we see organizations lack the ability to address business and technology resiliency in a strategic, comprehensive and integrated manner across lines of business.

Application Rationalization

 

Of course, while there are other benefits to be had, we should still talk about the biggest use for APM, which is Application Rationalization.

The accumulation of applications is a major challenge for most organizations today, in fact 85% of CIO’s believe their application portfolio needs to be rationalized. This statistic may seem surprising, but decommissioning an application is often a time consuming and expensive process. This may include steps such as extracting data, finding an acceptable way to store / manage the data, often in a new system and managing support and maintenance contracts for both the systems receiving the data and the one being decommissioned. Considering this challenge, and others such as resistance to change from the user community, doing nothing may seem like the easiest decision.

So why do so many CIO’s see a need to rationalize their application portfolio if it is such a challenge? Primarily the reason is cost. Cost in terms of operational such as hosting, support and maintenance, along with the internal cost of application management. Where an organization has multiple systems performing the same function, or worse - systems which aren’t even used, spending money on these systems is waste and a great opportunity to reduce cost without reducing productivity.
Another key factor is opportunity cost. With new innovative technologies such as mobile, social, cloud and big data there is a lot of pressure to channel the IT budget into these technologies which means moving away from legacy applications, and there is a sizeable investment in these legacy applications; maintaining and supporting legacy applications consumes the lion’s share of the budget.

 

Avoiding the need for Rationalization

 

The bloating of an application portfolio is extremely common, and the causes are numerous. Some of the common reasons include mergers & acquisitions, poor governance or simply a lack of application investment control. Some valuable management techniques can help limit the number of applications requiring rationalization by ensuring suitable applications are introduced:

Architect for Change: Consider building a simplified, flexible application platform applying standard solutions, SOA or Cloud-based delivery. A simplified system architecture can help improve productivity, cut costs, and channel resources toward innovation

Capture Business Requirements: Ensure alignment between business and IT by capturing, organizing, and managing requirements. Establish a risk-based application delivery approach to help you assess and prioritize the highest risk, highest-priority requirements so you can optimize your development and testing efforts based on business risk

Ensure Applications function as intended: The sooner you detect defects, the less it costs to fix them. Starting your quality process as early as possible, and incorporating all aspects of quality into your lifecycle will help ensure that your applications work as expected, and remain reliable and secure

Establish a Governance Process: Portfolio Management can help businesses focus on core activities while staying informed about all aspects of project and application health. It lets you govern your entire portfolio of IT projects, opportunities, and operational work in real-time with effective collaborative processes

Retire Applications while maintaining access to Data: Building retirement and archiving practices into the application lifecycle and implementing enterprise content and data management systems would help keep application and data growth in check. Importantly, it will prevent reoccurrence of similar problems in the future

Even when following best practices for application management, rationalization will be required for the foreseeable future. Organizations regularly introduce new standards and strategies; applications evolve rapidly with underlying technologies changing equally as quickly and business requirements change for a variety of reasons. Whatever the reason, the need for application rationalization is clear and the opportunities, if difficult to realize, are plentiful.

 

Approaches to Application Rationalization

 

To better understand application rationalization, we should understand how to approach to rationalization.

It may seem strange, but the best path towards succeeding with application rationalization is to use the right application. An enterprise architecture tool with a central repository, such as iServer365, will drastically improve the ability to execute on rationalization. The following steps have been designed with this in mind.


Challenge 3: Custom Reporting

 

When selecting a tool, the ability to generate custom reports, perhaps using popular BI tools such as Power BI, should be a key factor in the decision. When populating the tool with APM data, often one of the driving forces behind the exercise is reports such as lifecycles, auto-generated charts such as business vs technical fit matrices and such.

Generally tools have some out of the box reporting capabilities, however the need to extend this capability and bolt on custom APM reports is likely to arise as requirements vary from the generic.

The need for custom reports may arise for any number of reasons, perhaps as a result of a merger, some demanding stakeholders or out of the box reports which don’t meet the requirements but whatever the reason the end result is the need for both a tool flexible enough to enable custom report creation and the capability to create such reports. It's usually best to create custom reports to pull data directly from the tool’s database or synchronized version of the DB.

With such a capability, any BI tool is able to access and process the data to generate any custom reports which may be required – these same reports of course can be edited over time as requirements and data changes.

The key takeaway when overcoming this challenge is that although out of the box functionality and potentially expensive consultancy are alternatives, the preference for application portfolio managers who truly wish to meet the needs of their organization should be for direct access to their data from a specialized BI tool.

Most EA tools support some form of integration with BI tools, and iServer365 has native integration with Power BI, but for APM data this support will most likely be needed at some stage. This is re-enforced by the trend towards data accessibility, with business users increasingly expecting their custom reporting requirements to be met regardless of the source of the data. Fortunately, iServer365 has a range of additional integrations and a powerful REST API to extend this functionality where needed.