Author: Bunny Tharpe

Many businesses struggle to adapt quickly enough to new technologies to stay competitive. In most cases, these failures can be attributed to a lack of foresight and planning. We addressed this issue in a blog post, stating that a revolutionary and ever changing sector such as technology, demands revolutionary processes to cope.

Benefits such as reduced business risk associated with IT; increased flexibility for business growth and restructuring; bridging the gap between business strategy and implementation; and a generally more efficient IT operation, make Enterprise Architecture great for adapting to unforeseen changes.

However it is also a great system for tackling changes we know will come. One such change is the not-so-gradual shift to a truly connected world, dubbed The Internet of Things. The Internet of Things, or IoT, describes the booming (and sometimes bonkers) world of gadgets that can communicate with the Internet.

From toasters to trainers, and from washing machines to wrenches, eventually, almost all everyday appliances could communicate with each other and the wider world.

Naysayers need not, as this phenomenon has already begun, and judging by reports stating the number of IoT devices could reach 38 billion by 2020, it’s not going to slow down either.

As with most dramatic shifts in technology, unfortunately some businesses will be lost, unable to transform and cope with new consumer demands. That’s why solid enterprise architecture foundations are so important, and potentially the difference between a business floundering in the face of change, or flourishing.

Concerns over Internet of Things

Apprehensions surrounding IoT are both widespread and valid. Users accustomed to the automation of IoT devices expect them to work consistently and with little maintenance. After all, what’s the point in an automated process you have to manually monitor for it to work?

The pressure this puts on a business is far from insignificant. The devices must be regularly updated in the back-end to reflect the constantly evolving sector in which they are a part of. This requires a level of flexibility from a business to respond to these changes quickly and accurately.

Imagine your business is a fast food chain. A customer with a smartwatch and an app for your restaurant walks into your store, triggering the app to automatically order their ‘usual’ and debit the users bank account. However, you’ve recently changed your menu, perhaps as soon as the day before, and the customers order is no longer available.

Without the foresight of good preparation and efficient systems, that customer would order something that no longer exists, be billed for that order and be left waiting for their usual order indefinitely, most likely resulting in an unhappy customer who might even think twice about using your services in the future.

Considering the internet’s scope and the breadth of data accessible in it, unhappy customers are nowhere near a worst case scenario. Due to the automated nature of the devices, most data is transferred both mutually (both ways) and automatically.

Therefore, any adopters of the technology are placing their trust into the business that the data they share is being used and stored responsibly.

But like anything connected to the internet, these devices can be subject to cyber attack, and with IoT devices penetrating a multitude of sectors, including hospitals and traffic systems to name but two, the prospect of such attacks is very worrying indeed.

The two way passage IoT devices create between business and consumer is what makes the tech so valuable. However, making that connection, also opens up avenues for third parties to exploit. This potentially leaves both the business and its customers open to a cyber attack. For large enterprises, the PR fallout alone is enough to wince at, let alone the potential loss of or duplicated and stolen data.

Enterprise Architecture Opportunities

So far, we’ve touched on the booming IoT trend, the associated risks, and how enterprise architecture systems will help overcome those.

However the relationship between IoT and EA runs much deeper than damage limitation. Due to the nature of IoT, the “things” are often goldmines of useful data. This data can be measured to review the businesses current systems, or even identify new avenues for the business in the future.

This information is invaluable when constructing your enterprise architecture roadmap, and will ensure your expectations are based on solid, fact-based-frameworks, rather than guestimates.

For businesses completely new to IoT devices, enterprise architecture will also assist in preparing for the new influx in data (of which there will be a LOT). You’ll work out how that data should be stored (securely of course), as well as which bits of data you will actually need to collect, providing better focus.

Once you start gathering said data, the leg work you put in earlier, will help you make sense of that data more quickly and work on monetizing it.

What Enterprise Architecture Will Do for You and IoT?

Leading technology research firm, Gartner, have spent a lot of time analyzing IoT. Their research director, Mike Walker had this to say: “Enterprise architects have a great opportunity to position themselves at the heart of digital businesses.

“This could take the form of establishing a business competency center that explores how the IoT can create innovative breakthroughs for the organization’s business models, products and services through rapid experimentation.”

In this case, Walker’s comments are structured to highlight what IoT can do for enterprise architects, but the sentiment is just as valid when flipped. The reason IoT puts enterprise architects in such good stead, is because they are essential to actioning the transformation smoothly.

Taking on such a huge transformation as IoT without enterprise architecture assisted foresight, is essentially going into a battle, blind, with both wrists and legs bound. All while the competition that came prepared, are already on the front line, swinging Wi-Fi detecting Hobbit swords.

But don’t fret! The purpose of this text isn’t to create panic around integrating IoT. In any case, it’s far too late for that (see: 38 billion by 2020).

On the contrary, this piece is more about highlighting those risks, so those risks can then be prepared for and managed. If you’re thinking that sounds familiar, it’s because it is. Essentially, this is the first step on your enterprise architecture roadmap.

Think back to the most recent enterprise architecture articles, blog posts or even job descriptions you’ve read, and count any that did not mention “innovation” at least once? I’m guessing that more often than not, “innovation” was tauted as a catalyst, outcome or bi-product of effective enterprise architecture in one way or another.

Now we all know this is not a new theme, but it is increasingly being emphasized as more C-level executives place innovation on the strategic agenda which has a trickle-down influence on the entire organization. And i’m not talking about it in the buzzword sense. No, i’m talking about definable, measurable, incremental and breakthrough innovation that delivers tangible results to business performance.

Agile and Innovative Enterprise Architecture

To borrow a line from this blog post by Steve Nimmons: “Ask yourself how innovative your Enterprise Architecture function really is. An Agile and Innovative Enterprise Architecture function can and should drive tangible business benefits. An Enterprise Architecture function that ‘uses governance to say no’ and paralyses the business with change control will soon die (or become an irrelevance).”

In a recent post on Driving Innovation Through Enterprise Architecture, we explained how teams that embed a defined and repeatable ideation/crowdsourcing process into its operating model can solve the most complicated challenges and develop a pipeline of innovation opportunities.

To achieve this, architects must engage all stakeholders across the organization to capture their ideas and input. The combined creativity of the crowd surpasses the ability of the architecture team alone to uncover new innovations. It’s then up to the EA team to evaluate the impact, value, risk, cost, strategic alignment etc. of each idea and solution in order to select the best for implementation.

In fact, Gartner recently outlined three approaches for EA teams to adopt when exploring “Complicated”, “Complex” and “Chaotic” problems/opportunities, and the different stakeholder groups you must engage to capture the required ideas and input. There’s a good explanation of the approach in this post on the UCISA EA blog (see section “Orchestrating Ideation: Creating Breakthrough Innovation Opportunities”)

When you proactively pursue innovation in such a way, coupled with the adoption of emerging technologies, IoT, 3D printing and the likes, it increases the opportunity for, and the profile of innovations driven by EA.

Innovation The New Normal In Enterprise Architecture

With significant horizontal play across the organization, our role in orchestrating ideation and engaging all stakeholders becomes significant. I wonder if we’ll soon see a growing community of Enterprise Innovation Architects? We’re already beginning to see it frequently added onto VP level titles at larger organizations.

Enterprise Architecture Guiding Principles are high-level definitions of the fundamental values to guide Business Information and Technology (IT) decision-making activities. They provide a foundation for both business and IT architectures, standards and development policies.

Each EA Principle should focus on business goals and key architecture applications. They are intended to be enduring and not subject to frequent changes. However, they may be amended as the organization refocuses its mission and objectives over the long-term.

This blog post shares some real-life examples specifically from the University sector. Use them to review your own set of Principles. But before we get into all that, lets take a look at how they are formed.

Writing Enterprise Architecture Principles

Each Principle should be formally stated. What’s interesting is that the format in which they are stated can vary quite a lot between organizations; some explain in great detail following The Open Group recommendations for example, and others chose a lighter approach. Typically, Principles are made up of the elements Name, Description, Rationale, Implications.

Name
The name should represent the essence of the principle and ideally be easy to remember. It should not reference any specific technology platform.

Description
The description should convey the fundamental rule in a short and to-the-point manner. It should not reference any specific technology platform.

Rationale
The Rationale should highlight all the business benefits achieved by adhering to the principle. It must also describe its relationship to other principles and any situations in which a principle would take priority over another if there is any conflict in the decision-making process.

Implications
This section explains how the business and IT are required to comply with the principle when it comes to resources, costs and activities. As the name suggests, it should list potential related outcomes of making decision inline with the principle.

Guiding Principles should span all Enterprise Architecture Domains and are often grouped as such:

• Business Architecture Principles
• Information Architecture Principles
• Application Architecture Principles
• Technology Architecture Principles

3 Different Examples of University Enterprise Architecture Principles

Now let’s get to the interesting bit and dig into some real life examples of EA Principles. By sharing these examples I hope to provide you with insight and inspiration for refining your own Guiding Principles. Many can be re-used across organizations, but every organization should define a set that is aligned to its specific requirements, mission and strategic direction.

I’ve selected 3 different Universities that publish their EA Principles in slightly different ways but all with the same objective of guiding decision-making to ensure IT strategy is aligned the overall goal and mission of the organization. The idea is to show the different styles, but ultimately it comes down to whatever works for each of them.

EA Principles at the University of Washington (United States)

The University of Washington defines 9 short and succinct Principles in which it uses to govern its IT decision-making. A relatively short set of rules but each is well defined in terms of its Rationale and Implications.

• Standards Based
• Simple
• Scalable
• Service Oriented
• Strategic
• Reliable
• Data Driven
• Sustainable
• Secure

Use this link to visit the University’s EA web pages and explore in greater detail: http://www.washington.edu/uwit/EA/ea-guiding-principles/overview.html

EA Principles at Plymouth University (United Kingdom)

Plymouth University separates its principles by EA domain as outlined above, listing 18 Guiding Principles to “inform and support the way in which Plymouth University sets about fulfilling its mission.”

Business Principles: “Provide a basis for decision making throughout the business”

• Primacy of Principles
• Compliance with Statutory Obligations
• Maximize Benefit to the Enterprise
• Information Management is Everybody’s Business
• Business Continuity
• Common use Applications
• IT Responsibility

Data Principles: “Provide guidance of data use within the enterprise”

• Data Security
• Data is an Asset
• Data is Shared
• Data is Accessible
• Data Trustee
• Data will be Analyzable

Application Principles: “Provide guidance on the use and deployment of all IT applications”

• Technology Independence
• Ease of Use
• Purchase rather than Develop

Technology Principles: “Provide guidance on the use and deployment of all IT technologies”

• Requirements-Based Change
• Control Technical Diversity

For the full set of principles visit the following web page:
http://blogs.plymouth.ac.uk/strategyandarchitecture/enterprise-architecture-with-plymouth-university/plymouth-university-architecture-repository-2/enterprise-architecture-principles/

EA Principles at Brigham Young University (United States)

Brigham Young University describes the purpose of Business Architecture Principles is to “guide developers’ approaches to technology products created for a business unit.”

• BA is about the Business – not IT
• BA is about Examining Processes
• Enterprise Business Process Drive Architecture
• BA is Reusable

The University sets out a very extensive set (too many to include here). So it’s well worth taking a quick look. For the full set of principles visit the following web page:
http://ocio.byu.edu/ea-principles.html

All the examples listed above are published online so you can read and review at your leisure.

EA for an Agile Organization

One final note – something important to add here is HOW these rules are applied to the decision making process. It’s essential for the University’s EA team to be able to act with agility and be able to effectively collaborate on EA assets with all stakeholders. Through this, architects can present just the right amount of enterprise architecture assets required by the CIO or EA Board for making decisions in a timely manner.

As organizations embark on transformation journeys and seek closer alignment of IT capabilities and business goals, most will need to become more agile in the face of a fast-changing environment. Enterprise Architecture must step up to deliver innovation through new solutions that bridge the gap from where the organization is today and where it must be tomorrow in order to remain competitive and thrive.

On this journey, Enterprise Architects face both challenges and opportunities that they shouldn’t attempt to solve in isolation. As Brian Burke stated at the Gartner EA Summit 2015 in London:

“…companies can no longer rely on a small group of big brains to do all the thinking.”

Instead, EAs should look to orchestrate ideation as part of their Enterprise Architecture efforts (Click to Tweet!). That means engaging different stakeholder communities inside the organization to capture brand new ideas, and then leveraging that input to develop innovative solutions and solve their most complex challenges.

The ability to engage the right audience and focus on answering the right questions are critical steps on the path to successfully innovating. Those EA teams with a defined and repeatable process for Innovation, that can engage the relevant stakeholder groups and focus efforts on specific goals, will achieve the best outcomes that translate into increased business performance.

Establishing Innovation Capabilities in Enterprise Architecture

Here’s our list of capabilities you need when establishing an innovation process…

Start with a Goal

By defining the desired end-result for the problem or opportunity, you ensure that all efforts aim to meet the the goal.

Build Communities of Stakeholders

By building different communities of stakeholders across the organization you can engage the right target audience for the given problem. Communities can comprise a select group of individuals, or the entire organization.

Use Idea Campaigns

Create Idea Campaign for each problem or opportunity and advertise it to the community. You can then capture news ideas for each separate question or component problem of the bigger opportunity.

Make Idea Capture Easy

It’s important to have a simple and accessible method for capturing ideas. Ideally, you should have an idea capture form that is specific to each Campaign and that only the selected Community has access to it.

Encourage Collaboration and Feedback

Allow group collaboration, feedback and scoring of ideas. The Community is often best placed to identify the most promising ideas to develop into new innovations. Feedback is also important for maximizing employee engagement in your innovation process.

Use Gamification to Maximize Engagement

Simple gamification techniques such as leaderboards and rewards make a major difference to the level of engagement in your innovation campaigns. Its a proven technique that helps motivate individuals and the crowd to contribute ideas.

Impact Analysis

You must be able to analyze the likely impact of implementing new innovations on organization. Through this you, can understand the true value, cost, risk and alignment of each new idea with the business and IT strategy.

Adopting an Innovation Culture in Enterprise Architecture

For some architects, this requires a sort of culture transformation. Many architects are focused on describing the current-state and future-state architecture and then setting out on a journey. Whilst there is good value in this, its safe to say they are missing major opportunities by not engaging the crowd to uncover new ideas and innovative solutions.

Recognizing that the digital business is in a permanent transition, EA teams are well positioned right now to drive the innovation process and capture the combined creativity of all stakeholders.

When people think about IT Innovation, many would think of a finished product; a new piece of technology or a new system. But as we know, this completely misses the mark. Innovation for an IT executive is ultimately about the processes, transformation, and achieving new business outcomes.

Innovation is increasingly on the CIOs agenda as research shows 50% want to spend more time on innovation. We’ve outlined below four common barriers that IT organizations must solve in order to capture new ideas and successfully innovate.

Challenges in Ideation

IT teams that have problems capturing ideas and feedback from its stakeholders will likely recognize the following scenarios:

• Unclear process: The path to submitting ideas is not 100% clear or accessible to all stakeholders.
• Vague goals: Employees are not focussed on solving or achieving a specific goal, so ideas are not aligned with the current IT strategy.
• Lack of feedback: Contributors are unsure if their ideas are being valued or seen by the IT innovation team.

IT teams need a defined and repeatable process for capturing ideas and input from its stakeholders. Working on a campaign basis helps keep ideas aligned with current goals, while robust feedback mechanisms ensure new ideas are acknowledged.

Risk-Averse Contributors

Nobody wants to feel or be seen to fail, especially when people believe their professional reputation could be at risk. This is why many stakeholders in the IT ecosystem can be reluctant to share their ideas with the community; the fear of pursuing a bad idea that does not deliver value, or the thought of wasting time and resources.

Promoting a “no idea is a bad idea” message to stakeholders can help overcome this. And visualizing the impact of innovative ideas using Enterprise Architecture, IT teams can confidently eliminate less worthwhile concepts before investing time and resources in development and implementation.

Lack of Leadership Support

Without sufficient support from a senior business leader, employees often do not feel driven or that even that they have permission to contribute to Innovation campaigns. Clear and focussed support from the CIO, for example, helps all employees understand that they have a part to play in driving forward innovation.

Hierarchy of employee engagement

Like Maslow’s Hierarchy of Needs, every organization should be aware of a hierarchy of employee engagement which can help innovators understand the reasons behind varying levels of engagement amongst different stakeholder communities. There are a couple of key points to be aware of;

• Employees who feel only their basic “survival” and “security’ needs are met, are highly unlikely to engage in any innovation efforts.
• The middle “belonging” stage and above, is made up of employees who feel they are a part of the company’s community and culture and will typically engage in innovation efforts.

Understanding the above barriers can give IT teams a head start in their IT innovation efforts. Please share your thoughts and feedback on the above using the comments section.

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.