Mike Walker
October 2007

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

Contents

Introduction
Application Portfolio ManagementOverview
   The Story of Woodgrove Bank
   APM and Project Portfolio Management
Synergies Between EnterpriseArchitecture 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 isincreasing pressure from CxOs to cut costs, reduce inefficiencies, and tofoster agility in systems. Enterprises invest more than 70 percent of theirbudgets purely on maintaining their existing asset investments. This shows thatthere is a clear and present broken link between strategic business objectivesand “keeping the lights on” in the IT department. This is verified by a recentreport by AMR Research that reports that 75 percent of IT organizations havelittle oversight over their project portfolios and employ non-repeatable,chaotic planning processes.

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

Without having a clear applicationmanagement strategy, there is an impedance on the business. Enterprisearchitects have struggled to get to this target state because there are manychallenges.

There are many reasons for this, includingthe 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 insightsinto APM. We will explore how to apply APM to enterprise architecture (EA)practices. Through this exploration, we will show you why this managementtechnique is so essential for enterprise architects. Not only will we provideguidance for APM; we will also identify helpful tools that will aid you in yourAPM efforts.

ApplicationPortfolio 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 decisionmakers—primarily, CxOs and enterprise architects—to work within. APM provides aportfolio of application assets that provide us with visibility into theenterprise that we would not have without it.

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

To compound the issue, there are additionalfactors 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 theterm “assets.” Keep in mind that this is a very generic term. An asset is usedto 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 andoperate for the business.

The Story of Woodgrove Bank

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

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

Figure 1 illustrates the tree trunk analogymentioned earlier.

Figure 1. Tree rings are like enterprise technologyportfolios

Figure 1 illustrates the technology spurtsof the fictitious Woodgrove Bank. First, they invested in a consolidatedmainframe environment with a blend of languages. As time went by, open systemshad become more prevalent and additional languages and application models hademerged. Then a whole new paradigm emerged with Web-based technologies, thisprovided yet another set of development methodologies and supportinginfrastructure.

As time progressed, Woodgrove Bank noticedthat applications lived for many years and had entire teams supporting them.Then one day, they forgot about these applications for other more excitingtechnologies, until one day they looked back and realized they no longer knewwhat applications existed and where they were installed within theirenvironments. For Woodgrove Bank, management of legacy applications posed a setof issues they hadn’t encountered before.

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

APM and Project PortfolioManagement

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

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

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

Figure 2. Project Portfolio Server showing integration intothe project life cycle

Figure 2 shows how an APM solution such asMicrosoft Project Portfolio Server 2007 can integrate or build new projectprocesses. Office Project Server 2007 enables organizations to quicklyunderstand how work and resources align to business objectives. In addition toPPM capabilities, Microsoft Project Portfolio Server has APM capabilities.

Seeing a comprehensive view into how timeis being spent can help improve the process for proposing and evaluatingprojects. Furthermore, organizations can get better insight into key strategicprojects, 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 comparisonsof APM and PPM.

Synergies BetweenEnterprise Architecture and APM

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

APM provides many of the multi-facetedaspects that are required for an enterprise architect to be effective. Theseinclude the following:

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

The preceding aspects show EAs only apartial view just from an application perspective. The viewpoint of an EA ismuch broader than the preceding list indicates. So to augment this applicationview, other views are blended. EAs should extend the well-defined APMinformation with enterprise architecture metadata where the application architecturecan be linked to other aspects. After this is in place, multiple viewed analysisof an application provides enormous value not only the EA but other IT decisionmakers.

After we are able to have the facility tocorrelate information with metadata, what we will struggle with is the sheeramount of IT application information that must be gathered and classified. Atypical enterprise that has existed for more than a few years (such as ourWoodgrove Bank scenario) has a complex base of existing applications. Theseapplications reflect what the organization owns from an asset perspective andalso past business models and development architectures. The challenge is tobalance what was built for yesterday’s business needs with evolving businessdemands.

Figure 3 illustrates relationships betweenEA, APM, and the CIO office. APM allows transparency in the architectureprocess. This is important to the CIO and is also critical to building an EAcommunity. Additionally, it reinforces governance for EA initiatives. It doesthis by providing transparency in the process. This is coupled by having acentral store of record for application classification and management processesin which to base decisions.

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

The model illustrated in Figure 3 shows asmall 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 threecolumns. The first row identifies the current state of the enterprise. The CIOcan obtain the necessary business intelligence on what he or she needs to makedecisions about and report to the business, and the EA office can now have afacility to store and manage assets that provide a tool that enables them tomake informed decisions on current projects.

APM is the backbone for IT decisionsbecause it provides vital information about the enterprise for strategicplanning, governance, and risk management.

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

Figure 4. APM influences EA processes

APM’s Role in OrganizationalPolicy

Integration into the organizationalpolicies of an EA organization is essential. The majority of APM interactionhappens within this aspect of EA. Organizational policy provides the operatingmodel for EA organizations. The reason for this is that APM provides arepository to store the information needed to support the rest of the EAprocesses. APMs provide a backbone to the rest of the EA processes (such asorganizational, strategic, and programs).

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

EA organizational processes into which APMprovides 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 theseTLCs. APM repositories alone cannot provide all the required information;however, it gives EAs a large step forward. The additional information can beextended in the APM system or it can be federated through a metadata facility.

The way EAs are able to digest this largeamount of information is to assign attributes to assets. These attributes willlink key information to applications. Dashboards are commonly used to surfacethis information. This shows EAs vital information on the IT ecosystem. Figure5 illustrates an example of information that is provided for the TLC process.This dashboard shows a listing of applications in the portfolio with segmentsassigned. You can see that there are two deprecated applications in the lendingLOB. However, one application is up for review, while the other is not. Withthis information, an EA can focus on the current application instead ofspending time on an application that may not need attention for severalquarters.

Figure 5. Simple example of information provided for TLCprocess

One example of information that can be usedis the determination of whether an application should be decommissioned orre-engineered. Consider Figure 5. The Commercial Lending application has beenclassified as a deprecated technology and business pattern. This is followingaspects such as the application does not conform to any enterprise patterns andis up for review. Based on this data, an EA can easily identify whichapplications he or she needs to spend time on and work through the solutionarchitecture.

The following are other aspects APM willidentify for TLCs:

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

o       Emerging. This is new technology that may have asignificant role in the organization, such as the latest trends in softwaredevelopment.

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

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

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

·        Relationships with other applications. There may be direct or indirect dependencies of all differentcombinations. It is important to understand this aspect, especially when takingoperational aspects, such as information security or business continuity, intoconsideration.

·        Application modernization schedules. This refers to creating schedules around if and when applicationsshould be reviewed. A result of this may be an update to the application or asimple 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 standardsused within these applications can be critical.

Principles, Policies, and Standards

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

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

Figure 6. Cataloging principles, policies, and standards inAPM repositories

As shown in Figure 6, the aspects of theprinciples, policies, and standards process can be retained or be referred toan 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 aremade using APM; however, in the context of operational policy EA use APM tobuild out what technologies and standards should be part of the IT governanceprocess. Figure 7 illustrates an example of a “what if” analysis. This providesa mechanism to manipulate information about an application and show thedownstream impacts of those changes. Thus, it provides EA with a tool to makemore 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 inenterprises is having enough information to make a decision about architecture.Reviewing architectures is not just about the technology; it’s also about theimpacts of it to the enterprise.

The following are aspects that APM providesto 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 StrategyDevelopment

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

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

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

Figure 8 illustrates the IT strategy lifecycle described earlier.

Figure 8. IT strategy life cycle

What happens is that a transition statearchitecture is developed. These transition state architectures are developedwith the understanding that the future state is always in motion andaccomplishes the needs of today and a bit in the future. This limits the riskfootprint dramatically by allowing smaller chunks of future state architecturesto be implemented in a reasonable timeframe. This eliminates the potentialnegative impact on going to through a lengthy program to build out the futurestate.

Figure 9 illustrates the iterative behaviorof developing future state architectures.

Figure 9. Iterative behavior of developing future statearchitectures

As shown in Figure 9, EAs tend to createiterative steps toward future architectures. APM provides the enablinginformation on the past and current applications in the enterprise. Thisinformation provides EAs with much needed context and perspective about theprogression of the architectures in your organization. This is similar to theWoodgrove Bank scenario discussed earlier in this article.

Figure 10 shows a bubble chart thatincludes the risk footprint of applications in a specified query. This isanother example of how APM provides EAs with information that support theirdecision-making processes.

Figure 10. Bubble charts shows coverage of applications

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

The following are some other aspects toconsider:

• 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 allinformation will be or should be stored in the APM repository. There are otherstores that you can bridge information together to get that holistic picture.

APM’s Role in EA Programsand Projects

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

Often EAs run into statements such as “Wehave 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 biggerpicture is one of the largest reasons why more than 75 percent of IT workconsists of maintaining solutions. APM information can remove many of thebarriers in behavior such as this by providing concrete data about the trueimpacts of these actions.

As an EA, you want to make projectdecisions based on a broad set of information. In addition to take into accountthe current state application portfolio, you will also review theorganizational policies, such as standards and design patterns. One effectiveway to ensure traceability is to create a tool that aligns these componentstogether.

You want to do this for the followingreasons:

• 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 getconsumed in the micro-level details, but we must resist staying at that leveltoo long. That is not where the value of EA is to be had. Take a step back andnot focus on the tree, but look around the forest. APM repositories can helpEAs find the answers to questions such as the following:

·        Is this a unique solution, or is there somethingsimilar 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 itapply to multiple domains?

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

Figure 11: APM and EnterpriseArchitecture touch points in the SDLC process

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

Figure 12 illustrates an application recordin Office Project Portfolio Server 2007.

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

When referring to work management, thereare 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 rolessuch as the enterprise architect. When working on projects, it provides thenecessary processes that bridge multiple project roles together. The followingare 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 applicationportfolio management (APM) compliments an enterprise architect’s multi-facetedrole. APM provides key information into the IT enterprise architect (EA)management process. It has answered questions such as “Can yesterday's applicationsmeet tomorrow's needs?”

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

For EAs looking for tools to accomplish thetask of APM, Microsoft Office Project 2007 answers the call with its family ofproducts which provides a range of APM and PPM capabilities. Microsoft OfficeProject 2007 supports a variety of approaches to work management, levels ofprocess maturity, and business goals. On one end of the spectrum, MicrosoftOffice Project Standard 2007 provides enhanced desktop tools for small teams orindividuals tasked with managing projects but who are not necessarily projectmanagers.

Further EA process optimizations can beachieved by combining Microsoft’s APM products that leverage a common WindowsSharePoint Services portal framework with the Microsoft productivity toolsuite. This provides a better user experience and enterprise mash upcapabilities.

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