Mike Walker
October 2007

Summary: This article describes how application portfolio management (APM) compliments an enterprise architect’s multi-faceted role. APM provides key information into the IT enterprise architect (EA) management process. It answers questions such as “Can yesterday's applications meet tomorrow's needs?”

Contents

Introduction
Application Portfolio Management Overview
    The Story of Woodgrove Bank
    APM and Project Portfolio Management
Synergies Between Enterprise Architecture and APM
    APM’s Role in Organizational Policy
    APM’s Role in Strategy Development
    APM’s Role in EA Programs and Projects
Conclusion
References

Introduction

For many enterprise architects, there is increasing pressure from CxOs to cut costs, reduce inefficiencies, and to foster agility in systems. Enterprises invest more than 70 percent of their budgets purely on maintaining their existing asset investments. This shows that there is a clear and present broken link between strategic business objectives and “keeping the lights on” in the IT department. This is verified by a recent report by AMR Research that reports that 75 percent of IT organizations have little oversight over their project portfolios and employ non-repeatable, chaotic planning processes.

By using an application portfolio management (APM) practice, IT decision makers can gain visibility into the application’s impacts that reside in the enterprise.

Without having a clear application management strategy, there is an impedance on the business. Enterprise architects have struggled to get to this target state because there are many challenges.

There are many reasons for this, including the following:

• Lack of process. Process can help put a “method to the madness” when there are decisions being made that are not in the best interest of the enterprise.
• Limited views into the enterprise. Having a holistic view into an enterprise is essential, because it provides context for decision making, allows for proper road mapping, and it will provide a true rationalization of the impacts of the IT organization
• Poor visibility into asset base. Without having a clear understanding of the assets an organization holds, it is difficult to make the right decision when the time comes.

In this article, we will provide insights into APM. We will explore how to apply APM to enterprise architecture (EA) practices. Through this exploration, we will show you why this management technique is so essential for enterprise architects. Not only will we provide guidance for APM; we will also identify helpful tools that will aid you in your APM efforts.

Application Portfolio Management Overview

Before we delve into how APM can help EAs, we will first look at APM itself. APM is a management framework for IT decision makers—primarily, CxOs and enterprise architects—to work within. APM provides a portfolio of application assets that provide us with visibility into the enterprise that we would not have without it.

The trouble is that there can be an overwhelming amount of information to be collected. This can be an extremely daunting task for EAs. As an analogy, enterprise technology portfolios are a lot like trees. If you have ever seen a tree stump, you would have observed some distinctive rings. These growth rings show distinctive phases in growth. They tell us a great deal of information from year-by-year. For a visual example of this analogy, see Figure 1 later in this article.

To compound the issue, there are additional factors to consider. The following are some examples:

• New development technologies. Over the years, new innovations in development languages emerge. These are referred to as first, second, third, and fourth generation languages.
• New ways to use development technologies. The existence of so many different languages means that there are also many different techniques in which to implement. These include the use of procedural techniques and object-oriented techniques.
• New architecture paradigms. New ways of building software architecture emerge approximately every half decade. These paradigms have the potential to have a significant impact on enterprises assets.
• Infrastructure enhancements. The onslaught of new hardware and operating systems opens up new development opportunities. Because of this, existing assets are isolated in there own environments that reflect the period of time in which they were developed. Examples of this include Windows® servers, Exchange servers, and network devices.

You will see quite a lot of talk about the term “assets.” Keep in mind that this is a very generic term. An asset is used to represent any logical piece of intellectual property within the enterprise. This could include application logic, Visio® diagrams, Word documents, commercial-off-the-shelf-applications (COTS) or even media. These assets are crucial for an enterprise to execute and operate for the business.

The Story of Woodgrove Bank

Let’s tell a story about a fictitious bank named Woodgrove Bank. This organization has a long track record with technologies over the years. What has happened over the course of a number of years is a gradual incline of technologies.

In the late 1970s and 1980s, the bank had wanted to embrace the digital age. To accomplish this, they bought a mainframe that they started developing applications on. The business had such an overwhelming need for automation that the IT department couldn’t keep up. So after a few painful years, senior leadership decided that they should consider hiring vendors that could write custom code or provide out of the box applications.

Figure 1 illustrates the tree trunk analogy mentioned earlier.

Figure 1. Tree rings are like enterprise technology portfolios

Figure 1 illustrates the technology spurts of the fictitious Woodgrove Bank. First, they invested in a consolidated mainframe environment with a blend of languages. As time went by, open systems had become more prevalent and additional languages and application models had emerged. Then a whole new paradigm emerged with Web-based technologies, this provided yet another set of development methodologies and supporting infrastructure.

As time progressed, Woodgrove Bank noticed that applications lived for many years and had entire teams supporting them. Then one day, they forgot about these applications for other more exciting technologies, until one day they looked back and realized they no longer knew what applications existed and where they were installed within their environments. For Woodgrove Bank, management of legacy applications posed a set of issues they hadn’t encountered before.

This is a common scenario for many enterprises. The goal of an application portfolio is to store all these enterprise assets. This also allows us to classify the information. After we are able to classify our assets, management processes can be applied. This is the key enabler for enterprise architects.

APM and Project Portfolio Management

Application portfolio management (APM) and project portfolio management (PPM) are very closely related activities. PPM is very similar to APM; sometimes there is confusion between the two. Although PPM and APM are very similar, they are also very different.

PPM provides project managers the visibility into many projects or program portfolios. They also provide built-in governance processes. The goal of PPM is to catalog, quantify, and manage project efforts.

Figure 2 illustrates how PPM interweaves into the SDLC process to provide transparency for various roles in the enterprise. The following screenshot shows information that applies to the “Create” phase.

Figure 2. Project Portfolio Server showing integration into the project life cycle

Figure 2 shows how an APM solution such as Microsoft Project Portfolio Server 2007 can integrate or build new project processes. Office Project Server 2007 enables organizations to quickly understand how work and resources align to business objectives. In addition to PPM capabilities, Microsoft Project Portfolio Server has APM capabilities.

Seeing a comprehensive view into how time is being spent can help improve the process for proposing and evaluating projects. Furthermore, organizations can get better insight into key strategic projects, in addition to inventory active maintenance and development projects. Key benefits include the following:

• Defining the portfolio. You can build or customize the metrics, reports, and categories for a portfolio.
• Integrated process statuses. You can classify stages in the process with particular status aids in process automation and visibility into the state of the overall or micro level process.
• Portfolio reporting and review. Business intelligence (BI) and reporting features of Office Project Server 2007 can be used to track the health of a portfolio, evaluate project proposals, and assess the alignment of projects and resources to business priorities.
• Maintenance work. Build a simple project to capture maintenance work on a completed application. Timesheets enable actual work to be tracked; reports enable planned versus actual time to be viewed.

The following table lists the comparisons of APM and PPM.

APM	PPM
Focuses on the application architectures: Application-centric Takes non- tangible aspects into account such as: Personnel skills and education Dependencies of applications Links costs between applications Takes into account architecture, infrastructure, platforms, frameworks Supports IT governance holistically	Focuses on project characteristics: Primarily project-driven Links to project resources Focuses on investments in the portfolio Return on investment (ROI) of programs and projects

Synergies Between Enterprise Architecture and APM

We have identified strong synergies between enterprise architecture and APM. To be effective at enterprise architecture, APM is absolutely necessary. Some may not realize they are performing APM functions for one reason or another. However, to support necessary EA functions, APM information is collected in either a formal COTS tool or a custom solution. Although it is difficult to capture, there are many ways to get this information.

APM provides many of the multi-faceted aspects that are required for an enterprise architect to be effective. These include the following:

• Application costs
• Supporting business process and capabilities
• Business objectives or missions
• Supporting technology
• Environments

The preceding aspects show EAs only a partial view just from an application perspective. The viewpoint of an EA is much broader than the preceding list indicates. So to augment this application view, other views are blended. EAs should extend the well-defined APM information with enterprise architecture metadata where the application architecture can be linked to other aspects. After this is in place, multiple viewed analysis of an application provides enormous value not only the EA but other IT decision makers.

After we are able to have the facility to correlate information with metadata, what we will struggle with is the sheer amount of IT application information that must be gathered and classified. A typical enterprise that has existed for more than a few years (such as our Woodgrove Bank scenario) has a complex base of existing applications. These applications reflect what the organization owns from an asset perspective and also past business models and development architectures. The challenge is to balance what was built for yesterday’s business needs with evolving business demands.

Figure 3 illustrates relationships between EA, APM, and the CIO office. APM allows transparency in the architecture process. This is important to the CIO and is also critical to building an EA community. Additionally, it reinforces governance for EA initiatives. It does this by providing transparency in the process. This is coupled by having a central store of record for application classification and management processes in which to base decisions.

Figure 3. Relationships between EA, APM, and the CIO office

The model illustrated in Figure 3 shows a small set of processes that are enabled by APM. From left to right, we have EA, APM, and CIO processes. These processes align horizontally across the three columns. The first row identifies the current state of the enterprise. The CIO can obtain the necessary business intelligence on what he or she needs to make decisions about and report to the business, and the EA office can now have a facility to store and manage assets that provide a tool that enables them to make informed decisions on current projects.

APM is the backbone for IT decisions because it provides vital information about the enterprise for strategic planning, governance, and risk management.

Let’s take a deeper look at how APM influences EA. Figure 4 illustrates how APM influences the processes EAs undertake.

 

Figure 4. APM influences EA processes

APM’s Role in Organizational Policy

Integration into the organizational policies of an EA organization is essential. The majority of APM interaction happens within this aspect of EA. Organizational policy provides the operating model for EA organizations. The reason for this is that APM provides a repository to store the information needed to support the rest of the EA processes. APMs provide a backbone to the rest of the EA processes (such as organizational, strategic, and programs).

As EAs build out APM repositories, EAs should attach attributes to applications. These attributes allow EAs to align application architectures to items such as principles, policies, and standards. This provides insight into the alignment of applications to the overall vision of the IT organization.

EA organizational processes into which APM provides information are as follows:

• Technology life cycles (TLC).This is the process in which a life cycle is attached to an asset. The asset could be an application and or a technology standard.
• Principles and policies. This is the aligning of applications to principles and policies, which is a fundamental activity for EAs. If the principles and policies are aligned with the business, this provides the full tractability back to the business.
• Standards alignment. This is the linking to standards. By doing this, EA can gauge the overall effectiveness of a standard and analyze why standards are not being adopted; this provides a level of governance and proactively to impact the standards list in a positive way.
• Architecture decisions. This is the bridging of APM information with other information. By doing this, EAs can make informed decisions.
• Architecture review boards (ARBs). This is information that is fed into the architecture review process. APM provides essential PPM and application data that provides visibility across multiple domains.

Technology Life Cycles (TLC)

APM provides the facility to manage these TLCs. APM repositories alone cannot provide all the required information; however, it gives EAs a large step forward. The additional information can be extended in the APM system or it can be federated through a metadata facility.

The way EAs are able to digest this large amount of information is to assign attributes to assets. These attributes will link key information to applications. Dashboards are commonly used to surface this information. This shows EAs vital information on the IT ecosystem. Figure 5 illustrates an example of information that is provided for the TLC process. This dashboard shows a listing of applications in the portfolio with segments assigned. You can see that there are two deprecated applications in the lending LOB. However, one application is up for review, while the other is not. With this information, an EA can focus on the current application instead of spending time on an application that may not need attention for several quarters.

Figure 5. Simple example of information provided for TLC process

One example of information that can be used is the determination of whether an application should be decommissioned or re-engineered. Consider Figure 5. The Commercial Lending application has been classified as a deprecated technology and business pattern. This is following aspects such as the application does not conform to any enterprise patterns and is up for review. Based on this data, an EA can easily identify which applications he or she needs to spend time on and work through the solution architecture.

The following are other aspects APM will identify for TLCs:

·         Application segmentation. The concept of application segmentation is to group applications into segments that can provide an EA insight into what actions to perform this set of technology assets. This applies to both the applications and to standards. Common groupings include the following:

o        Emerging. This is new technology that may have a significant role in the organization, such as the latest trends in software development.

o        Core. This is technology that is core to the business, such as current standardized technologies that are mature and in wide use within the enterprise.

o        Depreciate. This is the segment that identifies technologies that should not be used and existing implementations that should have a TLC to remove from the enterprise.

o        Banned. These are forbidden technologies that should not be used within the enterprise.

·         Relationships with other applications. There may be direct or indirect dependencies of all different combinations. It is important to understand this aspect, especially when taking operational aspects, such as information security or business continuity, into consideration.

·         Application modernization schedules. This refers to creating schedules around if and when applications should be reviewed. A result of this may be an update to the application or a simple review to ensure that it is in line with the goals of the organization.

·         Links to standards. This refers to identification of the right and wrong standards used within these applications can be critical.

Principles, Policies, and Standards

The second area in which APM aids EAs is in the creation of principles, policies, and standards. They provide tractability from the business strategy developed by the CEO and the business through IT strategy that is developed by senior IT decision makers. By having this level of tractability, EAs can show alignment of decisions being made to the core objectives of the business.

Figure 6 illustrates how principles, policies, and standards derive from the business and IT strategy. As you move down the layers, the details become more granular. These linkages can be inventoried into the APM repository.

Figure 6. Cataloging principles, policies, and standards in APM repositories

As shown in Figure 6, the aspects of the principles, policies, and standards process can be retained or be referred to an APM Repository. These attributes include the following:

• Linage to business capabilities. These are the creation of attributes for applications, so they can align to existing and strategic business capabilities.
• Links to organizational aspirations. These link to future projects or organizational aspirations to show how applications lead to future state architectures.
• Alignment to governance. These are supporting processes in APM that empower governance and check points in the process.

Architecture Decision Support

There are many areas in which decisions are made using APM; however, in the context of operational policy EA use APM to build out what technologies and standards should be part of the IT governance process. Figure 7 illustrates an example of a “what if” analysis. This provides a mechanism to manipulate information about an application and show the downstream impacts of those changes. Thus, it provides EA with a tool to make more informed architecture decisions.

Figure 7. Example of a What-if analysis

APM enables EAs to achieve the following:

• Analyze current trends. With the data provided, trending of applications can occur. EAs can get an understanding of the costs, impacts, and benefits an application has had on the enterprise.
• Visualize the IT environment. Application models can be visualized though APMs that provide a way to both rationalize decisions and communicate them.
• What-if scenarios. These scenarios are great for vetting ideas on possible application outcomes based on a number of factors.

Architecture Review Board Support

One of many challenges ARBs have in enterprises is having enough information to make a decision about architecture. Reviewing architectures is not just about the technology; it’s also about the impacts of it to the enterprise.

The following are aspects that APM provides to an ARB:

• Project costs. By linking into a PPM system (PPM and AMP systems are usually one in the same) past, present, and future costs associated with an architecture.
• Quality attributes. APM systems can provide or link to information that identifies non-functional aspects of a solution. These include attributes such as security, risk, continuity, and performance.
• Application impacts on environment. EAs can rationalize the impacts an application can have on an operating environment.
• Resource requirements. These can identify gaps in technical ability in the organization. This can provide a gap analysis of what is supported versus what is not supported.

APM’s Role in Strategy Development

Another portion APM that applies to the practice of EA is architecture strategy. This is the process of creating road maps of technologies and future architecture envisioning.

Examples of these types of future state application strategies are service-oriented architecture (SOA), which may encompass Software + Services (S+S, SaaS), or composite applications. Enterprises want to capitalize on the benefits from service-oriented architectures that foster abilities to be agile, dynamic, and reusable. Enterprise architecture processes provide the foundations to link business processes to these emerging technology trends. APM provides enterprises the facility to catalog current applications and creation of future road map applications. From a strategy standpoint, APM is able to feed into the strategy development process with current state application information that can show inefficiencies, gaps of coverage, or rising support costs.

So, when building these future state architectures, the current state must be considered. Instead a “big bang” approach where all applications must be re-architected to meet the future state requirements, EAs look at more consumable ways of accomplishing this task. APM provides a facility to get this current state architecture information.

Figure 8 illustrates the IT strategy life cycle described earlier.

Figure 8. IT strategy life cycle

What happens is that a transition state architecture is developed. These transition state architectures are developed with the understanding that the future state is always in motion and accomplishes the needs of today and a bit in the future. This limits the risk footprint dramatically by allowing smaller chunks of future state architectures to be implemented in a reasonable timeframe. This eliminates the potential negative impact on going to through a lengthy program to build out the future state.

Figure 9 illustrates the iterative behavior of developing future state architectures.

Figure 9. Iterative behavior of developing future state architectures

As shown in Figure 9, EAs tend to create iterative steps toward future architectures. APM provides the enabling information on the past and current applications in the enterprise. This information provides EAs with much needed context and perspective about the progression of the architectures in your organization. This is similar to the Woodgrove Bank scenario discussed earlier in this article.

Figure 10 shows a bubble chart that includes the risk footprint of applications in a specified query. This is another example of how APM provides EAs with information that support their decision-making processes.

Figure 10. Bubble charts shows coverage of applications

By tracing back to the organizations business objectives, EAs can assess the architectures for which they want to build strategies. APM can provide those linkages back to business objectives.

The following are some other aspects to consider:

• Asset management. This is a micro-level process that gives EAs visibility into information, such as application costs (licensing, maintenance, leasing).
• PPM. This is linkages to portfolio information that can be linked to building IT strategy.
• Technology life cycles. TLCs are essential to building out IT strategies. There is insightful information that can be harvested and correlated, such as application segments and alignment.

It is important to note that not all information will be or should be stored in the APM repository. There are other stores that you can bridge information together to get that holistic picture.

APM’s Role in EA Programs and Projects

Frequently, EAs will be called in on strategic projects to aid in the architecture process. This happens more when there is a program that consists of multiple projects where there needs to be a renationalization of how multiple architectures fit together.

Often EAs run into statements such as “We have to have this package” or “We want to build it our way because it works.” Having such a limited view on the decision without considering the bigger picture is one of the largest reasons why more than 75 percent of IT work consists of maintaining solutions. APM information can remove many of the barriers in behavior such as this by providing concrete data about the true impacts of these actions.

As an EA, you want to make project decisions based on a broad set of information. In addition to take into account the current state application portfolio, you will also review the organizational policies, such as standards and design patterns. One effective way to ensure traceability is to create a tool that aligns these components together.

You want to do this for the following reasons:

• It ensures that IT decisions are made consistently based on information in APM.
• It creates a repeatable process, which in turn ensures that decisions are made equally without conflict of interest.
• It facilitates traceability to the overall strategy of the organization.
• It enables auditability and accountability of decision making.
• It eases governance by providing tools that empower architects to make the right decisions.

On projects, it is common for EAs to get consumed in the micro-level details, but we must resist staying at that level too long. That is not where the value of EA is to be had. Take a step back and not focus on the tree, but look around the forest. APM repositories can help EAs find the answers to questions such as the following:

·         Is this a unique solution, or is there something similar already in my organization that can be re-purposed?

·         How does this problem align to “buy vs. build” policies?

·         Does this apply to only this domain or does it apply to multiple domains?

Figure 11 illustrates APM and Enterprise Architecture touch points in the Software Development Life Cycle (SDLC) process. The alignment of the SDLC process and APM is useful as it provides a way to iteratively gather information necessary for the application.

Figure 11: APM and Enterprise Architecture touch points in the SDLC process

As shown in Figure 11, APM and EA interweave into the SDLC. APM will provide EAs with a project level work management environment. This allows EAs to concentrate on architecture rationalization.

Figure 12 illustrates an application record in Office Project Portfolio Server 2007.

Figure 12. Example of an application record in Office Project Portfolio Server 2007

When referring to work management, there are many tools that can support this. One example is Office Project Server 2007, as shown in Figure 11. It provides a work-management solution built for roles such as the enterprise architect. When working on projects, it provides the necessary processes that bridge multiple project roles together. The following are the high-level capabilities:

• Connect people and teams to project information. Office Project Server 2007 connects people and tools by providing IT decision makers the visibility into commitments made to executives and dependencies across teams.
• Cross-role work management. This enables organizations to manage all their work and people in a single system.

Conclusion

This article has described how application portfolio management (APM) compliments an enterprise architect’s multi-faceted role. APM provides key information into the IT enterprise architect (EA) management process. It has answered questions such as “Can yesterday's applications meet tomorrow's needs?”

APM can remove many of the variables on the decision making process by providing the right information. Without these linkages between application portfolio management, enterprises must depend on an educated guess. This is neither ideal nor practical for modern enterprises.

For EAs looking for tools to accomplish the task of APM, Microsoft Office Project 2007 answers the call with its family of products which provides a range of APM and PPM capabilities. Microsoft Office Project 2007 supports a variety of approaches to work management, levels of process maturity, and business goals. On one end of the spectrum, Microsoft Office Project Standard 2007 provides enhanced desktop tools for small teams or individuals tasked with managing projects but who are not necessarily project managers.

Further EA process optimizations can be achieved by combining Microsoft’s APM products that leverage a common Windows SharePoint Services portal framework with the Microsoft productivity tool suite. This provides a better user experience and enterprise mash up capabilities.

References

• MSDN Enterprise Architecture Center:
  http://msdn.microsoft.com/architecture/EA 
• Microsoft Office Project Server:
  http://technet2.microsoft.com/Office/en-us/library/c3c3bee4-c1e5-4887-adac-5eb8795b87a71033.mspx?mfr=true