Category: erwin Expert Blog

In the third post of our blog mini-series we looked at the Effective Management of your Portfolio, and learned where you need to consider the cost effectiveness of applications and the risk acceptability.

This fourth and final phase of the process is to Optimize your Portfolio, and it’s here that must you begin to examine the dependencies between other applications and projects. You must also add into your portfolio the costs and fiscal requirements of each application. Technical infrastructure requirements are identified and costed and you can start to examine in detail, the benefits and value that is accrued through the exercise. The important final step is to align the portfolio with business priorities and goals.

So for the final time, lets get stuck in!

Step 1 – Identify dependencies

Look at the dependencies on other applications and projects. An Enterprise Architecture may already be available for you to utilize and view the application portfolio in a broader context of its architecture. If not, then you need to associate each application with identified dependant goals, drivers, application dependencies, technologies, work packages etc.

Corso software allows users to view the list of concepts and details of an Application Component, and see all of the dependencies/associations that exist or can be created.

If you possess enough domain knowledge to associate this application to other concepts such as business processes and other applications, then you should go ahead and add the associations. Otherwise, you should collaborate with someone in the organization who is an expert on the application.

You should associate work packages (projects) in the same way. Now to see the full dependencies of an application (or group of applications), work package or any other type of concept, you need create diagrams that visualize the associations.

This example shows an application and all of its associations (using an ArchiMate Layered View).

You can see the application’s dependant business processes, data objects, other applications, technology, projects and roles. The work package (project) called Upgrade Claims Handling also has associated business goals, drivers and deliverables which impact this application.

This type of diagram allows you to view the complexity of the application and the impact it has on the rest of the organization and IT, and is a valuable for decision making in prioritization meetings.

If we dig into the detail here, this close-up diagram example shows a driver named Claim handling. It has a dependant Goal named Improve claims handling, and as assessment named Sloppy claims archiving. The Claim reviewer is the role related to the Claim handling driver.

The above techniques will help you build up a good understanding of the dependencies in your application portfolio.

Step 2 – Determine priorities and timeframes

To help determine where to prioritize your efforts within the application portfolio, use a roadmap view to visualize your application portfolio and its dependent concepts over time.

Now you can start to adjust the lifecycle dates of each application and the Goal dates and other dependent concepts according to your action priorities and anticipated timeframes.

For each application component you look to set a required action, any cost savings you may have identified, the time frame for the action and any improvements that this action will deliver. Typical actions include:

• Invest additional funds in the application
• Sunset or eliminate the application
• Consolidate the application with another application
• Replace and consolidate the application
• Continue maintenance

You should complete this process for each of the application components in your portfolio and don’t forget to apply values to each attribute that work best for you. For application components that require additional work to complete the attributes, you should create a work package and associate your application components to it.

Step 3 – Potential benefits for selected actions

Work packages represent an action that needs to be completed on the application portfolio, and often produce an improvement or benefit when completed. A work package can be small task or a large project, and can require collaboration with other stakeholders in order to be completed.

For work packages in your portfolio you should record the estimated Costs and the anticipated Gains that this work package will produce to calculate its Value or importance. Value is often monetary but it doesn’t have to be. For example, reduced risk is a positive Value!

You can calculate the total Costs of your work packages and also total the Gains which are achieved by consolidating or sunsetting applications etc.

Now you can use pivot table reporting to summarize your portfolio that helps to produce a business case for your APM findings.

Step 4 – Pivot tables reports

By creating what we call an Application Portfolio Action Plan pivot table you can visualize the costs of an application over its lifetime and its action plan (work packages to be completed). In this example heatmap pivot table, the applications in the portfolio with the highest cost savings potential are highlighted. This type of information is vitally important for communicating your plan with stakeholders and decision-making.

By creating a Work Package Risks and Costs pivot table you can understand the budget assigned to different work packages, the rough order of costs and the risks associated with not completing the work package. Again this level of detail is valuable for decision making and communicating with stakeholders.

Step 5 – Workflow, sign-off and produce funding requests

Use pivot tables to drive the Return on Investment of work packages in your application portfolio and track their status, like this example below.

Also utilize a kanban board to track the status of applications, with the columns of the kanban board representing the four stages of the APM process. Application components and other related concepts are positioned on the board in the corresponding status. This is an incredibly effective way to visualize and share the status of your APM efforts with stakeholders and collaborate on different concepts to ensure they continue to move forward.

For example, you can track when an application component has completed the initial Build and Maintain Inventory stage of the APM process and progressed into the Analyze Portfolio stage.

You can also use a kanban board to show the approval lifecycles for application component and work packages. In any organization of any size, its unlikely that one person is the sole decision maker on such decisions.

It’s also useful to create a kanban board for the APM approval process too. Set up your Kanban, set the goals and set the roles involved in decision-making and approvals. It’s also a good idea to filter the concepts that are included on the board initially to keep it simple, and then add concepts to the board at a later stage. Its incredibly useful to create a notification system for when an application component or one of its related concepts moves between stages, the relevant stakeholders (financial or IT etc) will be informed.

The final step is to produce the material required for additional funding requests etc to support you APM efforts. It may well be the case that you can fund the rationalization of your portfolio simply through existing work packages (projects) attached to your applications.

Any request for funding or resources must be built around a solid business case. This is where the multiple techniques and outputs covered above prove their true value. You must be able to publish the reports and diagrams created throughout this four-stage process, for presentation to senior stakeholders/decision makers.

That’s it. You now know how to do effective Application Portfolio Management from start to finish. We’ve taken you though building and maintaining your inventory, analyzing your portfolio, the effective management of your portfolio and the optimization of your portfolio.

In our last post we looked at Analyzing Your Application Portfolio, pinpointing the moment at which your business problems and issues need to be identified.

Now it’s time we focus on the actual Management of your Portfolio phase. This is where you’ll need to consider the cost effectiveness of applications and the risk acceptability. You should move towards a decision making process with subjective business decisions, identifying problems and/or opportunities and any alternative approaches for supporting the business with the portfolio. Additionally, you will also need to begin to look at the best actions for managing applications over their expected life spans.

Business importance and criticality are also key criteria, and you can use all of the techniques outlined previously to help you make decisions about each application in the portfolio.

This blog series seeks to address the successful management of your Application Portfolio touching upon Enterprise Architecture and Innovation Management techniques. We show examples taken from Corso’s software platform to help illustrate important points.

Step 1 – Analysis through pivot tables

Pivot tables provide a mechanism for slicing and dicing your application portfolio data, which is critical for surfacing the answers to your questions and decision making requirements. Pivot tables enable you to visualize, in a relatively simple way, a large amount of data that would otherwise be very complex to understand. You can generate a high-level overview of many different attributes, or focus on just one or two data points for more granular detail.

Here’s an example pivot table heatmap of application components and related attributes;

• Business Criticality
• Functional Quality
• Technical Quality
• Risk Profile
• Organization Value
• Failure Risk
• Health Status

This approach produces a high-level analysis of the portfolio which can help understand where to focus your efforts. You can now begin to analyze your portfolio in detail!

Step 2 – Decision making and analysis

Utilizing the pivot table technique, you should begin to drill down into your application portfolio and discover which components might require you to take action.

Start by visualizing those application components that are eligible for technical replacement. To do this you need to review applications that score High on Organizational Value but Low on Technical Quality.

Similarly, you can also visualize your applications based on the Functional Quality attribute to understand which applications do not provide the functionality that is required by the end user.

To take this one step further, examine the Functional Quality, Technical Quality and the Number of Active Users attributes which produces a more complete picture.

By adding in Business Criticality too, you can start to shape the portfolio. Don’t forget, there many different pivot tables that you can create that will allow you to make accurate decisions about your portfolio.

Step 3 – Application lifecycles

Utilizing your pivot table analysis of the portfolio, you must assign the lifecycle status for each application and apply the temporal attributes for the lifecycles. In this example you can see that the application that went Live on 24th January 2014, the next release is due 27th March 2015, and is scheduled for Retirement on 7th December 2022.

Step 4 – Application portfolio roadmaps

Now that you have defined the lifecycle for each application, you can begin to visualize the roadmap view for the portfolio. Roadmaps enable you to view applications over time; essential for understanding how each application’s lifecycle relates to the rest of the portfolio.

Portfolio Roadmaps are divided into a number of lanes and can display one or more concepts. In this example, you can see how the application portfolio and the Application Live Lifecycle attribute date range are displayed as a roadmap.

The red line indicates todays date/time. The start and end dates of each application’s Live status are indicated by the length of the bar.

A useful roadmap view for APM is looking at work packages (projects) and application components. The projects are those that will have been identified as impacting applications in our campaign (as outlined in our earlier post Build & Maintain Your Inventory).

In this example below, work packages and applications are on the same lane on the roadmap which shows the initial live date for applications and the scheduled date for the projects. Here you see how a combination of single date points and date ranges can be displayed – the work package has a start and end date, while the application has a single live date.

The important point here is to use the pivot tables and roadmap views to adjust your decision making on whether to invest, sunset, consolidate or set any other appropriate lifecycle action. This leads you into the final phase of the process which is focussed on optimizing your application portfolio.

Last week, we talked about starting the journey with Application Portfolio Management: Building and Maintaining Your Inventory. We outlined a 9 step process for you to start engaging stakeholders more effectively and to introduce new ideas into your wider enterprise blueprint. In this blog post we look at what is required to effectively analyze the application portfolio.

As before, this blog series seeks to address the successful management of your Application Portfolio touching upon Enterprise Architecture and Innovation Management techniques. We sometimes give examples by referencing erwin software tools to show Application Portfolio Management in action. So lets get straight into it!

Analyze Portfolio is where your business problems and issues need to be identified. It’s useful to collaborate with a line of business stakeholder or technical expert to capture their input on the application components throughout the process.

Step 1 – Add associations

The first step is to add risks, issues and associations of each application to the rest of the portfolio. These can be in the form of associated applications, processes, actors, locations, data and technology components.

Associations are critical for impact analysis; understanding how a change to one application component will affect its associated components.

For example, an Application may comprise other Applications, or an Application may realize a Requirement.

erwin’s platform allows for additional associations to be recorded than those mentioned above, to provide a greater level of context and reasoning behind certain application components and concepts for users/stakeholders.

Step 2 – Chart attributes from your inventory

By visualizing attribute data in a simple chart its easier to make assessments on the application portfolio. For example, it can be valuable to visualize those application components with the lowest risk, highest functional quality, greatest business criticality and best technical quality.

Here’s an example of a chart produced using erwin’s software platform.

Application components are stacked, so that you can focus on the application components with the highest total. Users can filter the content on the chart if there are many concepts to analyze or create multiple charts for easy visibility.

It’s important to weight attributes according to their importance. Decreasing the value of one attribute will give more weight to the other attributes. For example, the Business Criticality attribute can receive a higher weight than the Functional Quality attribute.

In this chart, you can see that the application Bank System has a higher overall rating because we place less weight (importance) on the Risk attribute of the application components.

Step 3 – Evaluation attributes

Here, you need to look at the value of the application components to the organization, the health of the application components and the risk of unrecoverable failures.

To evaluate the health of an application, look at the Technical Quality and Functional Quality attributes. Visualize these attributes using the same chart technique described in Step 2. There are many ways to visual the chart data, so choose a way that provides the best representation to meet your needs.

Here’s an example of a simple chart showing the Technical Quality and Functionality Quality of different application components that can be used to understand Health.

Use this data to assign a Health Status attribute to the application components. For example, the Home & Away Policy Administration component would have a low Health Status since it has low Functional Quality and low Technical Quality.

erwin offers an automated scorecard function for calculating the Health Status of an application, utilizing formulas such as (Functional Quality + Technical Quality ) * Risk Profile.

Evaluate an application’s Organization Value by looking at the Business Criticality, Functional Quality and Technical Quality, with a heavy weighting on Business Criticality.

Evaluate an applications Failure Risk by looking at the Risk Profile and Technical Quality. For example, High Risk and Low Quality indicate an increased likelihood of an unrecoverable failure.

These attributes combined unlock another dimension to your Application Portfolio Management efforts. By placing Organization Value, Health Status and Failure Risk into a single chart you can start identifying areas that require your attention.

In this example, the Organization Value is on the Y axis, the Health Status is on the X axis and the color and shape of the Z axis indicate the Failure Risk.

Ideally, you are looking to see applications that exist in the lower left corner that have a cross shape as this indicates low value, low health and high risk. These are the potential remediation applications.

Step 4 – Build just enough documentation

Now is a good time to start documenting the results of your APM efforts. As you make important decisions about the portfolio, you must maintain documentation describing what you have done. These are critical for ensuring effective stakeholder communication and collaboration, and supporting further decision making.

Application Portfolio maintenance and operations can consume between 70% to 90% of an organization’s IT funds, meaning Business and IT Executives are increasingly having to “do more with less” when delivering innovative new business and IT initiatives.

Application Portfolio Management helps save time and costs that can be utilized for other more strategic and valuable programs. In this blog series will touch upon some of the benefits including:

• Understand the cost of your IT estate
• Analyze the impact of change to an application in your portfolio
• Visualize application and technology roadmaps for future decision making
• Easily build an application of entry through simple form based data capture
• Identify overlaps and gaps in IT capabilities
• Manage your vendor relationships

Interestingly, Application Portfolio Management (APM) is considered to be a strategic IT capability that utilizes Enterprise Architecture and Innovation techniques. The overall aim is to run a focused campaign to gather ideas for application improvement and the application detail itself. Additionally, the interdependencies between applications and the rest of the enterprise can be recorded.

This blog series seeks to address the effective management of your Application Portfolio by using Enterprise Architecture and Innovation Management techniques.

Innovation Management (IM) concerns itself with capturing information and ideas, from a wide range of stakeholders across the organization. By incorporating gamification techniques, it helps keep stakeholders involved in the information capture process.

Enterprise Architecture (EA) allows organizations to produce business and IT blueprints that provide visibility of your strategy, capabilities, business processes, IT infrastructure and Information Systems and their dependencies.

By utilizing both techniques in your APM efforts, you can engage stakeholders incredibly effectively and introduce new ideas into your wider enterprise blueprint.

Application Portfolio Management can typically be broken up into four stages:

• Build and maintain your inventory
• Analyze your portfolio
• Manage your portfolio
• Optimize the portfolio

This first blog in the series will focus on; Build and maintain your inventory. We sometimes link our approach into erwin EA software so that you can see a real-world use-case of Application Portfolio Management.

Step 1 – Collect, validate and maintain data

The first task is to collect and harvest your application inventory. The applications in your organization must be documented and stored in one system for completeness. Applications are often owned by IT or different lines of business and so associating them with an appropriate Community helps keep things organized.

Step 2 – Define your communities

By creating different Communities inside your tool, groups of individuals or separate teams can focus on specific concepts that are relevant to them and discuss and share information effectively. You must define a community strategy for your organization and identify the stakeholders needed​ to support your APM requirements.

Step 3 – Set your goal

By defining your Goal and relating all your subsequent activities to it, you can ensure that you stay focussed on achieving your desired end-state.

Step 4 – Create and launch a campaign

Build and run a Campaign (or survey) to engage your stakeholder Communities in the information gathering process and make it simple for them to feedback about applications through a collaboration tool or portal. Promoting and sharing your campaign via email, social collaboration tools or notice boards helps you reach your stakeholders wherever they are. You should consider if your Campaign could be publicly visible to all stakeholders or private to select Community.

Step 5 – Perform initial collection and validation of data

Once the application concepts have been collected from various invited stakeholders as part of a Campaign, you’ll need to refine them. This is important because you might require additional information and/or additional stakeholders to assist. It’s also a good idea at this point to collect and validate data for any implementation projects that are dealing with application assets. Again, you may create a Campaign to gather work packages (projects) that are in progress.

Step 6 – Assign tasks to stakeholders

Sometimes you will need individual stakeholders or team members to manage a specific task, especially when working with a large number of different stakeholders. By assigning tasks to individuals you implement a much more collaborative approach to your APM work stream and ensure you get the input you require to be successful.

Step 7 – Set your major attributes

Here’s where it gets really interesting! You must set the major attributes to measure your applications inventory. Major attributes include:

• Application Lifetime Cost
• Number of Users
• Active Users
• License Cost
• Maintenance Cost
• Business Criticality
• Functional Quality
• Technical Quality
• Risk
• Business Processes Supported

For example, erwin EA customers can utilize predefined attributes for Application Portfolio Management that look like this.

Here, you can calculate the Application Lifetime Cost by summarizing an application’s attributes for Lifespan, Monthly User Cost, Number of Users, License Cost, Maintenance Cost.

You must be able to measure Number of Users. This represents the number of users that were assigned when the application was purchased or subscribed to. Active Users represents the number of users that have used or are currently using the application. Business Criticality measures how important the application is in maintaining business performance.

• High – The business couldn’t operate without it.
• Medium – It’s important but we the business could continue with a back up plan.
• Low – The business could operate without this.

Note that some of our attributes have array type values. For example, Business Criticality can be “High” and has a value of 100. This is very useful when producing charts and reports later on.

Functional Quality; how functional is the application in support of the business?

• High – It is functionally rich and does everything we need of it.
• Medium – It satisfies some of the functions of our business
• Low – It has low alignment with what the business requires.

Technical Quality helps measure technical performance of an application?

• High – It aligns 100% with our technical strategy and is defect free to our knowledge.
• Medium – It has some known defects but performs adequately.
• Low – It has defects and requires support.

What is the Risk Profile for this application?

• High – It presents a high risk to our business.
• Medium – It is a manageable known risk to our business.
• Low – It has no risk to the business.

Business Process Supported or enabled by the application?

It can be valuable to group the associated processes that application supports into a single view.

Step 8 – Add further attributes

Now that you have begun to gather input from your stakeholders you may identify some additional pieces of information required. At this point you can add and define new attributes as required alongside the major attributes described above.

Step 9 – Prioritize on Kanban boards

Kanban boards provide you with a visual storyboard for work. Your different concepts are represented as ‘cards’ on the board and move from one stage to another as they develop and change in status.

Using Kanban boards for APM involves working with community to define the different stages of the kanban and positioning your cards into the appropriate stage (for example; To Do, Doing, Done, Parked). You can update the cards as they are investigated, refined and implemented; progressing them through to completion.

erwin EA provides you with pre-defined Kanban boards for Application Portfolio Management allowing you to move concepts along the board. It’s important for APM that we keep work moving along the board so that we can track the progress of each concept. Different stakeholders can be assigned as collaborators on each concept on the board and receive automatic notifications when they progress.

Stay tuned for the next update in this series, which will focus on stage 2; Analyzing your portfolio.

In a corporate sense, innovation management is about quickly and effectively implementing your organization goals through the adoption of innovative ideas, products, processes and business models. Most organizations are beginning to realize that to drive business growth and maintain a competitive advantage, innovation needs to be discovered and implemented quickly and with care to ensure maximum value.

The process of innovation needs to be managed and governed in the organization and is an important facet of a company’s overall function.

Enterprise architecture (EA) is a perennial tool for innovation. This is because once you develop a good idea; you need to ensure that EA is leveraged to understand how to implement it successfully. Investment in a particular idea requires a degree of confidence that a product, service, IT component or business process is going to make it to market or change the business positively. Conversely, IT requires traceability back to the innovation that has driven it. Not having this traceability means that it’s difficult to see the value of IT and how it drives the business. Additionally, there is a need to leverage the limited interaction between those who innovate and those who manage EA.

Without EA, decision making around the right ideas and requirements is much more of a lottery. And, while there are more and more projects on the go and a rise in agile development approaches, companies simply do not invest enough time in combining innovation and EA. DevOps and continuous delivery are prime candidates for connection into innovation management. In the context of speed and time to market, where the frequency, capability and release cycles are key to competitive advantage; EA’s support of decision making allows innovative ideas to be de-risked without costly mistakes.

The importance of an agile approach to Enterprise Architecture

Enterprise architecture has often failed when it’s targeted at modeling the entire enterprise so performing the appropriate amount of enterprise architecture is required to achieve results. Agile approaches such as Scrum can sometimes be used to build small pieces of enterprise architecture that deliver exactly what is needed. Scrum techniques harness team working, delivery in time slots and identifying ‘experts’ to help with specific issues.

Other techniques such as ‘Kanban’ can be used to help visualize the status of architectural concepts and their journey in the agile process. In innovation management we can show users the journey of different concepts in the innovation lifecycle, which improves the visibility for the whole team. When coupled with EA frameworks such as ArchiMate and TOGAF, Scrum provides the focus to EA.

An Agile approach to EA allows for continuous improvement and ties nicely to incremental ideas that the business receives.

Agile Enterprise Architecture and Innovation Management in summary

We’ve noticed that EA thinking is not influencing innovation management in the way it should be because innovation projects are not necessarily aligned with the transformational needs of the business. EA is typically addressing transformational challenges such as mergers/acquisitions, business and IT alignment, adoption of big data, IT outsourcing etc. There are too many ideas and many more projects than there needs to be.

EA needs to find a place to influence innovation management. Where innovation is growing, EA provides just enough architecture to help influence innovation decision making and current innovation management platforms have not addressed EA.

It’s an oversight but its understandable because the heritage of these older platforms does not provide the rigour needed for an EA approach. Organizations are telling us their resources are scarce so it’s absolutely crucial that we make use of the resources in a way that benefits everyone. With Innovation Management and EA, we can help companies do this by providing them with guidance in selecting the right course of action from the resources available. Consequently, a platform that can marry innovation management and agile EA can provide true decision making for innovation initiatives and EA activities.

Innovation needs to be real, and linking it to the underlying enterprise architecture demonstrates how ideas have evolved. Enterprise Architecture needs to be able to address real innovation. If the architecture changes what effect does this have on innovation and its related strategies? Innovation Management and Agile Enterprise Architecture go hand in hand. Although each can be successful in their own right, it’s when they are used in conjunction with each other that the full benefits can be realized.