/Tag: Application Portfolio Management

Alignment – the missing Viewpoint

By |2008-10-06T21:56:00+00:00October 6th, 2008|Enterprise Architecture|

The (ISO Standard) RM-ODP model is a powerful and well reasoned mechanism for creating Architectural descriptions (“architectures”).  Leveraging the IEEE-1471 taxonomy, and building out a visual style and standardized approach, there is tremendous value in learning and using this the RM-ODP (Reference Model for Open Distributed Processing), and I’m getting to the point of recommending it.

That said, there is a gap in one of the most fundamental areas of the RM-ODP model.  RM-ODP specifies exactly five viewpoints.  This term is defined by the authors of RM-ODP as:

A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns.

In other words, if you want to communicate with Joe, and Joe cares about 19 things, you’d better cover those 19 things when discussing the system with Joe.  He has 19 concerns, and we can group those concerns together into 3 viewpoints (for example), and provide a “visual language” (my phrase) that can be used to communicate those concerns.

The next sentence, from the RM-ODP Overview (ISO/IEC 10746-1), is the problem:

Five viewpoints have been chosen to be both simple and complete, covering all the domains of architectural design.

Simple?  Not so fast.  The views produced by RM-ODP are far from simple… but…

Complete?  I disagree.  Big disagreement.

For those readers who are unfamiliar with the RM-ODP, this model describes five viewpoints:

  • the enterprise viewpoint, which is concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part;
  • the information viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;
  • the computational viewpoint, which is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution;
  • the engineering viewpoint, which is concerned with the infrastructure required to support system distribution;
  • the technology viewpoint, which is concerned with the choice of technology to support system distribution

(There are many things wrong with this list.  I’m only describing one of them here.  Another will be described in a later post).

One viewpoint that the RM-ODP forgot is the one that matters the most to Enterprise Architecture: AlignmentI propose that the RM-ODP be extended to include the Alignment viewpoint.

The alignment viewpoint is concerned with the strategic and measurable purpose for the existence of a process or business system, and the justification for changing the features, structure, and operational profile of a process or business system, at a particular time, and in a particular organizational and technical environment.

The key concepts here:

Process or Business System — This viewpoint is NOT limited to describing a technology or line-of-business application.  The views may (and typically do) limit themselves to business and informational views that do not illustrate any specific “ODP” system at all.

Purpose — The notion that a system comes into existence for the sake of fulfilling a purpose.  That purpose is described in terms of business capabilities, business processes, business policies, business quality metrics, and business information.  These explicit concepts describe the environment in which a system adds value. 

Justification — The notion that any change to a system has to be justified.  Enterprise Architecture is the business function concerned with insuring that all justifications align to the business changes implied by business strategy.  Insuring that justification is based on strategy is an activity frequently referred to as ‘alignment.’ 

Note that, in a mature organization, alignment must be demanded to justify a change in any system, not just a software system.  Changing a system requires care to prevent negative consequences on routine business operations, whether it is a system of people behaving with common goals, or teams behaving in a process, or applications behaving in a sequenced activity.

Some examples of Architectural Views that fall into the Alignment viewpoint:

Business Capability View — An illustration of the business capabilities of a particular business unit (at any level of a business hierarchy where clear responsibilities and accountabilities exist).  Concerns for a business capability view may include the importance to strategy, staff readiness, process uniformity, cost of IT maintenance, flexibility of IT change, uniformity of information, maturity of process measurement, and scorecard value of process performance.

Business Process View — An illustration of the business processes and process activities necessary to support one or more business capabilities.  May be demonstrated at varying levels of granularity, with the highest level representing abstract business processes (like “Marketing”) down to task level processes (like “Deliver Marketing Brochure to Publishing Team”).  Concerns may include role and responsibility clarity, efficiency, effectiveness, uniformity, delegation of authority, and service level management.

Enterprise Project Portfolio View — An illustration of the business change programs in place throughout the business and how they align to meet the strategic and operational needs of the business.  Concerns for an Enterprise Project Portfolio View may include overlaps by feature area, relative budget estimates by category, interdependencies by time, and feature delivery by time.

Enterprise Application Portfolio View — An illustration of the operational systems and processes in place to run the business, and how well those systems are prepared to adapt to potential risks and strategically driven projects.  Concerns for an Enterprise Application Portfolio view may include applications that are impacted by multiple projects in close temporal proximity, applications that share similar functionality but different data stores, applications that share data stores but remain inconsistent in their implementation of rules, and applications that with high risk metrics (risk of failure * impact of failure).

Enterprise Information Federation View — An illustration of the core informational elements of the enterprise (like “customer,” “product,” “market offer,” “shipment,” and “service request”).  Concerns for this view include addressability (the ability to find a unique data entity, using a readily accessible identifier, anywhere in the enterprise), consistency (the ability to insure that information that is shared by many people has consistent use throughout those who use it), and federation (the ability to apply the control of key data elements to the level that is closest to the team that needs or uses it).

Enterprise Technology Portfolio View — An illustration of the supporting business capabilities required by the business, and the use of shared technology platforms to meet those capability requirements. 

While I have not met anyone who had told me that these views should be in the “enterprise viewpoint” as described by RM-ODP, I’m prepared to defend the notion that the enterprise viewpoint does not, in fact, cover this space.  (A different post, perhaps, if it is necessary).

Measuring Risk in Application Portfolio Management

By |2007-12-26T13:28:00+00:00December 26th, 2007|Enterprise Architecture|

I decided to take a few minutes of my vacation time to catch up on my reading, and I read through Mike Walker’s article on MSDN on APM and EA.  It is an interesting and useful article. (I’d give it a B-).

One thing that I’d like to highlight in the practice of application portfolio management is that of risk management, an area that Mike implicitely touches on, but which I believe is fundamental to the business case of APM.

You see, there is nothing wrong with owning a bunch of stuff.  Think about it: how many chairs does your company own?  How many desks?  How often does the company spend money to replace every chair in every office?  If your business is typical, the answer to that question may very well be “never.”

Yet, we do see projects where a company will replace four billing systems with a single billing system.  That happens.  Clearly, owning an application portfolio is different than owning an inventory of assets.

Key among the differences is risk… especially risk to business continuity.  There are many other factors, of course, and Mike covers some of them quite well in his article, but I want to focus on risk and risk management.

There is a substantial intersection between Application Portfolio Management and Risk Management.   However, I suspect that some folks who read this may not be aware of the area of risk management.  From wikipedia, here is a fairly good definition:

Risk management is the human activity which integrates recognition of risk, risk assessment, developing strategies to manage it, and mitigation of risk using managerial resources.

The strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.

By way of example:

When you look at an inventory of chairs, you have risks.  If a chair gets old, and breaks, and an employee is injured, then the business faces insurance claims.  Morale suffers.  Productivity may decline due to lost work time and morale.  If the incident is public, then the company’s reputation may suffer.

Managing that risk involves understanding the kinds of things that can go wrong (falls, wounds, productivity decline, etc) and determining the factors about a chair that may lead to them (poor condition, missing parts, wobbling, etc).  If you collect this information about your inventory, and then you group your chairs according to these attributes, you might get a few classes of chairs: (excellent, workable, frail, dangerous). 

With each category, you can determine the risk to the business for owning it.  Clearly, the risk to own dangerous chairs is higher than the risk to own workable chairs.  While it doesn’t make sense to replace every chair, these statistics can provide an excellent business case for replacing the dangerous chairs (right away) and the frail chairs (over a finite period of time).

We use essentially the same process for applications.

What are the things that can happen to the business if an application fails?  Let’s list out those things, and then create a set of attributes that an application has that will help to differentiate some applications from others.

Risk scenarios –> Attributes –> Data collection –> categorization

Within each category, you can determine the risks to the business that need to be mitigated.

Note that you can have many heirarchies, many categorizations.  You can group applications by their lifecycle stage (Strategic, Core, Maintain, and Sunset), and that is certainly useful for combining APM with PPM.  In other words, it is useful to know how much of your planned budget is devoted to improving strategic applications. (Mike mentions this in his MSDN article, with different definitions that we don’t actually use internally in Microsoft IT).

Another useful categorization is application impact on operations.  The attribute to measure is  the speed at which a failure would impact operations of the business:

  • Instant (<6 hours)
  • Immediate (<2 days)
  • Rapid (< 10 days)
  • Serious (< 60 days)
  • Corrosive (within 9 months)
  • Hidden (gradual impacts on quality of customer experience or regulatory compliance)
  • Competitive (no impact on operations, but potential impact on ability to compete)
  • None (no one will miss this app if it goes away)

This is far more useful than a subjective measure like “strategic” or “core” when determining the value of investment in an application, and it also shows something else as well: the serious problems that may arise from a lack of investment.  

A terrific example was described in CIO magazine a while back, describing a situation where Comair Airlines kept putting off investments in a new crew management system, only to have the system crash during a heavy Christmas season that literally grounded the airline.

No one in the business would have considered a crew scheduling system to be ‘strategic’ and so an investment portfolio that breaks things down by how ‘strategic’ an application is would not have favored the replacement of that application.  On the other hand, a categorization that captures the application’s impact on operations would clearly have placed that application in the Immediate category. 

Of course, correct categorization is only the first step.  Now you have to determine the risk of failure.

Categorization –> risk of failure –> cost to business –> priority for mitigation

By determining how likely an application is to fail, based on its risk categorization, you can select the applications that most need attention.  Now, that attention does not have to involve a rewrite.  There are lots of ways to mitigate risk.  You can move the risk by making someone outside the business responsible for handling that business capability.  You can reduce the risk of failure by introducing redundancy or failover.  You can reduce the cost to the business by moving non-essential decisions off of one application and onto another, more reliable, application. 

Mitigation review –> Comparison of alternatives –> investment in mitigation

I am not an employee of Comair, and I have no desire to criticize.  Their case is very public, but there are many more failures in IT that impact operations that are not so well described.  I refer to their misfortune as an example for us all to learn from.  In that vein: perhaps if there were a graph that showed the amount of investment against high risk applications, as opposed to the amount of investment against ‘strategic’ applications, then it would have helped to seal the business case for mitigating, and ultimately preventing, the heavy losses that the company faced when IT failed to keep the system running.

The key here is that IT has to work closely with business, something that IT folks are not very good at and that business folks often fail to understand the value of.  But by showing that some applications deserve mitigation, and by working as partners to reduce the risks faced by those applications, the business will willingly invest in IT the mitigations that are needed.  This is the visibility gap that APM can fill.

Success requires a conversation between IT and the business, one that Enterprise Architecture must foster.  And this is one area where EA and APM intersect.  One of many, but an important area that we must not forget. 

EA + APM + Proper Measurement = Risk Management

Does APM reduce cost? That depends.

By |2007-08-18T15:12:00+00:00August 18th, 2007|Enterprise Architecture|

The goal of Application Portfolio Management is to reduce the cost of owning the portfolio.  The fundamental premise is this:

  • We own a lot of code.
  • It costs a lot to maintain our code.  (too much)
  • Management wants to be able to make cuts in the maintenance budget.
  • We don’t know which costs are optional and which costs are necessary
  • APM answers that question, allowing us to cut unnecessary maintenance costs

Something like that anyway.  (OK… it’s a bit over simplified.  sue me).

There are some problems with the notion, problems that show up in the details.  Systems are not simple marbles that you can remove from your bag and sort into neat little buckets.  They are tied to business problems that need to be solved.  They are part of a solution that automates activities in a business process.  The criticality of those business processes, and their rate of change, does more to drive the cost of maintenance than most other factors in play.

Yet, most APM tools are simply catalogs where you write down things about the app, but don’t do much to help you to analyze the importance, or rate of change, of the business processes that they are attached to.

And thus, all the data collection in the world won’t help without that analysis that puts things into perspective.

Some folks do that analysis, and they see costs decline… sometimes by large margins.  Others expect the tools to help, or they measure the wrong things, and costs don’t drop.

My gut tells me that APM will only succeed when it is tied to tangible analytic methods like Six Sigma.  Without that tie… it may not do very much.  A car, without an engine, won’t get you to the church on time.

Putting Application Portfolio Management into the picture

By |2007-08-01T20:32:00+00:00August 1st, 2007|Enterprise Architecture|

Gabriel Morgan knocks one out of the ballpark in this blog post that traces the connection from Business strategy through business process to applications, data, and hardware. 

Highly recommended for anyone who is an Enterprise Architect or aspires to being an Enterprise Architect. 

One aspect that Gabriel didn’t address is Application Portfolio Management.  I’d like to wax a little on that subject.

Every Application costs money to own.  If an application ABC stores its data in a manner that is difficult to integrate, and you need to write another application PDQ that moves data around and transforms it, and even another application XYZ that is used to handle the data quality issues and workflow that results from all that data manipulation, then the cost of ABC includes the cost of owning and maintaining both PDQ and XYZ.  That overhead can get pretty expensive, pretty fast.

Application Portfolio Management is an IT practice that views the list of applications in operation within the bounds of an enterprise as assets with individual costs and business value.  This methodology helps to identify applications that should garner further investment, while identifying applications that should be kept running (maintained) without further investment, or even retired.

One valuable activity within Application Porfolio Management is to scan the portfolio looking for redundancy.  Let’s focus on this one activity.

The degree to which an application is redundant with other applications is a useful indicator of whether the business is likely to benefit by retiring or trimming the features of one application in support of another.  In other words, if application ABC has four features, and application DEF has four features, and they overlap on two, then you are paying for eight features, but you get only six (plus the possibility that you have to add features in another application in order to reconcile the data from both).  A good simplification activity might be to add two features to ABC and turn off application DEF.  (this is a wild oversimplification, but it will do for now).

The problem comes when you have more than a few applications in your portfolio.  If you have 10, or even 100, then you can probably compare each application with every other one, looking for overlaps.  But if you have over 2,500 applications, as we do, then the cartesian product becomes absurd.  We’d be talking about making over 6 million comparisons.  Assuming each comparison takes two days to do (which would be about typical), then a team of 50 people would take about 1,000 years to complete the task.  Hmmm.  That’s not gonna work.

Solution domains provide a mechanism to reduce that comparison overload, making an attempt to scan for redundancy feasable.  Because each domain contains a set of “system features” that a business person can understand, then it is not difficult to map each application to one domain.  (Technically, one application will map to one ‘primary’ domain with relationships to other ‘secondary’ domains as needed).  Once you have done this, then you can take your porfolio, break it into 82 parts, and get much smaller groups of applications.  Divide and Conquer. 

Assuming that our portfolio were to map evenly over the solution domain taxonomy (for the sake of public discussion), then we’d have about 30 applications in each domain.  Assuming that about half of those were clearly not candidates for further investment, then we would only need to compare, in each domain, 15 applications with one another.  Each domain would take a couple of months for a small team to analyze for redundancy.  Entirely do-able. 

In addition, you can choose to only analyze one or two ‘core’ domains to start.  That will allow you to prove the process works, establish value for your simplification efforts, and produce an action plan that people can use to measure return on investment. 

And what change would that require in Gabriel’s diagram?  Currently, he has a single line from Application to the services within a solution domain.  I’d add another line, from Application to a new sub-box within Solution domain called ‘Feature’.  This is a seperate mapping that is not useful for service management… but for APM, it’s priceless.

Pay Attention to the Application Portfolio

By |2006-12-14T09:40:00+00:00December 14th, 2006|Enterprise Architecture|

One nice thing about being in Enterprise Architecture: you get to watch as the infrastructure changes.  When you are working on one big project or another, or even a dozen different projects over the course of the year, you only see the changes that you helped to create, but in EA, we have to take a regular inventory.  It is then when you realize all the things that have actually happened the year before.

And it is then that you sometimes find that the data about your application portfolio doesn’t match reality. 

In our area, we had a small exercise last fall where we were classifying the applications according to whether they were Strategic, Core, Maintain, or Sunset.  It’s a part of Application Portfolio Management called Application Segmentation.

The practice allows the organization to inspect the investments across the portfolio (Project Portfolio Management) to see how many of the investments, or how much of the money, is going towards strategic needs vs. core needs vs. maintenance, etc.  You could even make portfolio decisions, like “of our total budget, we want to spend X% on strategic needs” which could move a few of the projects into, or out of, the Plan of Record (POR).

Anyway, while doing this exercise, one of my friends in a different group noticed that one of the “apps” in the portfolio wasn’t really an app at all.  The PM who had created the entry had been working on a project and thought that “all projects need their own application id” so he created one, even though the project didn’t create a new app… it modified one.

So my friend did the rational thing: he asked that the ‘entry’ be removed.  Our support manager agreed and the application entry was removed.  Unfortunately, I wasn’t aware of this. 

Now, the end of the year rolls around, and I’m taking my annual inventory and updating models, and I notice that the app is marked as ‘retired.’  I know that the functionality is still there.  Few people remember why the app was ‘turned off’ and my friend’s name is not on the entry’s log anywhere.  It took about an hour to figure out what was going on.  Once I realized what he had asked for, I agreed with the logic and removed the entries from my models. 

Point being: Enterprise Architecture is intimately tied to Application Portfolio Management as well as Project Portfolio Management.  Make sure that your processes for review and governance include process points when an application is decommissioned, not just when it is rolled out.  Otherwise, you, too, will spend a few hours, at some later date, trying to track down “what the heck happened to the SNAFU app?”

Third attempt – definition of an application in a SOA environment

By |2006-08-11T20:07:00+00:00August 11th, 2006|Enterprise Architecture|

In a previous post, I rattled on about the problems faced by Application Portfolio managers who wish to reduce the total cost of ownership and measure portfolio return through the oversimplified lens of “how many apps do you have?”

I complained, rather heartily, that the older definitions of an app are no longer valid.  However, I didn’t propose a new definition.  Bad Nick.  OK… third try.

First, what is the purpose of the definition?  To whom does it apply?

This definition is useful only for counting the NUMBER of applications in your portfolio and for determining the boundaries of that application.  Why would you want to know the boundaries of an application?  Because, in the world of composite applications, the boundaries allow you to measure the complexity of the app once and only once.  This allows the basic formula to be: Complexity of portfolio = sum of (complexity of application)

Therefore, I would define an application in the following manner:

Application – An executable software component or tightly coupled set of executable software components (one or more) that deliver some or all of a series of steps needed to create, update, manage, calculate or display information for a specific business purpose.  In order to be counted, each component must not be a member of another application. 

Of course, my definition of ‘application’ included a reference to the term ‘software component’ so I need to define that too.

Software Component – An executable set of computer instructions contained in a single deployment container in such a way that it cannot be broken apart further.  Examples include a Dynamic Link Library, an ASP web page, and a command line EXE app.  A zip file may contain zero or more software components because it is easy to break them down further (by unpacking the ZIP archive).

By this definition, the following ‘things’ are applications:

  • A web service endpoint that presents three web services: InvoiceCreate, InvoiceSearch, and InvoiceDetailGet
  • A service oriented business application (SOBA) that presents a user interface for creating invoices, and that turns around and calls the InvoiceCreate service.  (note that the service itself is a different application).
  • A legacy system composed of a rich client, a server-based middle tier, and a database, all of which are tightly coupled. (e.g. changes in one are very likely to trigger changes in another).
  • A web site publishing system that pulls data from a database and publishes it to an HTML format as a sub-site on a public URL.
  • A database that presents data to an Excel workbook that queries the information for layout and calculations.  This is interesting in that the database itself is an application unless the database is already included in another application (like a legacy system). 
  • An Excel spreadsheet that contains a coherent set of reusable macros that deliver business value.  The spreadsheet itself constitutes a deployment container for the application (like a TAR or CAB file). 
  • A set of ASP or PHP web pages that work in conjunction with one another to deliver the experience and logic of a web application.  It is entirely possible that a subsite would qualify as a seperate application under this definition if the coupling is loose.
  • A web service that no one uses, but which can be rationally understood to represent one or more useful steps in a business process.

The following thngs are not an application at all

  • An HTML web site.
  • A database that contains data but is not part of any series of steps to deliver business value using that data. 
  • A web service that is structurally incapable of being part of a set of steps that provides value.  For example, if you create a web service, but you require that the data that arrives can only be useful by the app if it breaks the web service schema, then you have not deployed an app.  You have deployed trash. 

The following things are many applications

  • A composite SOA application where you develop a set of reusable services and a user interface that leverages those services.  Note that you do not count each service as an app.  Depending on how many tightly coupled components you built, you may have a single servicies endpoint that presents many services, or you may have a couple of service endpoints that are independent from one another.  It is the amount of coupling that defines the application, and therefore it’s boundary.
  • A legacy client-server app that writes to a database to store data, and an excel spreadsheet that uses macros to read data from the database to present a report.  There are TWO apps in this example.  The database clearly belongs to the legacy app in that was developed with it, delivered with it, and is tightly coupled to it.  This is true even if the legacy system uses the same stored procedures as the Excel spreadsheet.