Review: Evaluating Enterprise Architecture Processes


From a recent post from Robert Mcllree he talks about the evaluation of EA. He breaks down the evaluation into a set of factors. When I saw this post it was quite lengthy and looked as it may provide some interesting insights. It did, however I struggled with what the post was meant to address. A few things came to mind, was this to:

  • Gauge the Health of the EA Organization
  • Gauge the Maturity of the EA Organization
  • Create Justification of the EA Organization
  • Find Reasons to Disband

Even though the post was a bit ambiguous it doesn’t mean that the post is not relevant or didn’t have great content. I think it did.

Robert provides a great set of questions that you should ask yourself (as an EA) or your EA team:

  • Is EA a distinct function in the organization?
  • Does the EA group have both functional and technical responsibilities and generate actionable outputs to both?
  • How is EA specifically funded?
  • How are EA outputs received and utilized by the organization?
  • How skewed are EA efforts toward specific vendors and/or integrators?
  • Does the EA organization set IT standards, and if so, how are they specifically enforced (and exceptions made)?
  • What is the relationship between EA and the business?
  • What is the relationship between EA and IT management?
  • What is the relationship between EA and project management?
  • Are EA toolsets used? What kinds, how often, and for what specifically?

Like I said earlier, I think that these are great questions to ask but they are simply questions. I think that this needs a little more work. Not on the question side but when the answers come back, what do they mean?



My Blog in Chinese


The architecture community in China is a growing one. With nearly 50,000 architects in China and so far. Microsoft created in China has created the Architect Circle where there are over 2,000 architects in that Architect Community.

If your looking for my blog in Chinese, check out the Architect Circle. A big thanks to Qing Wang from Microsoft in China.

Be Cautious about APM Discovery Agents


I was reading a recent article from InformationWeek about APM and it had concerned me a little bit. The article was titled "Performance Anxiety" and meant to address APM product vendors. For whatever reason, Microsoft’s product line was not included.

I am still trying to determine the intentions of the article. It was not clear. However what was clear was the suggestion that in order to be successful at APM server agents are necessary.

Be very careful with assumptions like this. Application Discovery Agents are NOT the key here.

This is not to say the article was bad, but that it implies and talk a lot about agents when there are many other facets to APM. I do like the diagram below on the APM risk analysis.

APM impact assessment

Source: Information Week APM Performance Anxiety

Let me tell a story from my In my previous life. I was a key resource in the vendor selection and architecture processes for selecting our vendor for APM. We choose one of the big stack IT Management Suites that addressed APM and PPM.

The promise of monitors for the application space became very problematic. We did find that for Service Management (MOF or ITIL processes) that there are some very useful monitors for networks and physical servers. The problem with the application space was that it turned into a HUGE development effort or minimal return. Application monitoring was quickly disbanded.

Until the Application Monitoring further matures I would suggest not to go down this road yet. There is still a great deal of maturing that needs to happen. InformationWeek’s analysis shows this as well.

Instead of focusing on those aspects I would have you consider how APM effects your Enterprise Architecture processes around Technology Life Cycles. Below is a common, but simple grid that is used for basic analysis on what application architectures you should retire, spend less time on, embrace or empower.



Tags: Enterprise Architecture APM

EA and Application Portfolio Management


For many enterprise architects there is increasing pressure from CxO’s to cut costs, reduce inefficiencies and to foster agility in systems. Enterprises invest over 70% 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.

With an Application Portfolio Management (APM) practice it allows EA’s to gain visibility into the applications impacts that reside in the enterprise.

Forester says that Application portfolio management (APM) dashboards provide visibility and the ability to cut applications maintenance support costs by as much as 30%. See the July 22, 2005, Market Overview “APM Tools Will Reach $500 Million To $700 Million By 2008.”


What is APM?

There are many definitions across the industry. There are debates on the definition of APM that frequently cause confusion or derail APM initiatives. There is no a single definition of APM, but is that a problem?

In the near tem I don’t think so. Until our tooling vendors mature a bit more we have time to define it as little or as much as we want. So my recommendation is to be pragmatic about it. just like with everything EA, start small and iterate through some maturity cycle. APM views can then be progressively refined, ultimately arriving at catalogs of the various representations that can be mapped and or analyzed for the multiple areas of concern.

Below are a few opinions on definitions, at the end of the day. You be the judge for what fit’s your organizational needs.

Microsoft: Application Portfolio Management aids organizations gain visibility, insight, and control across all work; thus enhancing decision-making, improving alignment with business strategy, maximizing resource utilization, as well as measuring and increasing operational efficiency.

IBM: This refers to the practice of managing an entire group or major subset of software applications within a portfolio. Organizations regard these applications as investments because they require development (or acquisition) costs and incur continuing maintenance costs. Also, organizations must constantly make financial decisions about new and existing software applications, including whether to invest in modifying them, whether to buy additional applications, and when to "sell" — that is, retire — an obsolete software application.

Gartner: Application portfolio management processes fill gaps in the knowledge used to determine the most-effective deployment of IT resources. Filling those gaps improves consistency and flags opportunities to reduce total life cycle cost.

Wikipedia: Application Portfolio Management attempts to use the lessons of financial portfolio management to justify and measure the financial benefits of each application in comparison to the costs of the application’s maintenance and operations.


So What are the 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. While 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:

· Application Costs

· Supporting Business Process and Capabilities

· Business Objectives or Missions

· Supporting Technology

· Environments



These aspects above only show EA’s a partial view just from an application perspective. The view point of an EA is much broader. So to augment this application view other views are blended. EA’s should extend the well defined APM information with Enterprise Architecture Metadata where the Application Architecture can be linked to other aspects. Once this is in place multiple viewed analysis of an application provides enormous value not only the EA but other IT decision makers.

As shown above APM feeds into the three core aspects of an EA’s role. APM’s providing a backbone to the rest of the EA processes (i.e., Organizational, Strategic, Programs).

Below are some examples of processes APM contributes to:

· Technology Life Cycles (TLC) – 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 – Aligning applications to principles and policies is fundamental activity for EA’s. If the principles and policies are aligned with the business this provides the full tractability back to the business.

· Standards Alignment – By linking applications to standards EA can not only gauge the overall effectiveness of a standard but also analyze why standards are not being adopted. Thus providing a level of governance and proactively to impact the standards list in a positive way.

· Architecture Decisions – Because all of the applications are in this APM repository EA’s are able to bridge APM information with other information that will allow them to make informed decisions.

· Architecture Review Boards (ARB) – It is common to have EA’s on an ARB. APM provides essential PPM and application data that provides visibility across multiple domains.