IT has too many separate portfolios to manage, and that hinders its ability to help business change. We have project portfolios, application portfolios, technology portfolios, and IT service portfolios – each managed in silos. These portfolios are all IT-centric – they generally mean nothing to business leaders. The business has products, customers, partners, and processes – and the connection between these business portfolios and the IT portfolios isn't readily apparent and usually not even documented. Change in the business – in any of these areas – is connected to IT only in the requirements document of a siloed project. Lots of requirement documents for lots of siloed projects leads to more complexity and less ability to support business change. 

How do we connect these business concepts to IT? What's the "unit" that connects IT projects, apps, and technology with business processes and products? 

It's not "business capabilities" – they are an abstraction most useful for prioritizing, analysis, and planning. We need a term to manage the day-to-day adaptation and implementation of these capabilities – the implementation with all its messiness such as fragmented processes and redundant apps – that we can use to manage any type of change. 

We believe the best term for this unit is "business services," with this definition:

The output of a business capability with links to the implementation of people, processes, information, and technology necessary to provide that output.

EA teams like to know how mature their EA practice is. There are a lot of EA maturity models out there. You will find some of these assessments and maturity models discussed in a 2009 Forrester report. Many EA teams share the idea that there is a single “ultimate EA model” and that EA leaders should strive to move up the ladder to this ultimate model. It’s like a video game – you try to get to the next level. 

For the past three months, the EA team’s Researcher Tim DeGennaro has been looking at these models and Forrester’s research on EA best practices to create a framework for assessing EA programs. This looked deceptively simple: Develop criteria based on the best practices we see in leading EA organizations, create an objective scale to rate an organization’s progress, offer reporting to illuminate next steps, and wrap it in an easy-to-use assessment package. What we’ve found so far is not only that avoiding the effects of subjectivity and lack of context is impossible but also that many assessment styles disagree on the most crucial aspect: What exactly is EA supposed to be aiming for?

Rob Karel and I (thanks to Rob) recently published the second document in a series on metadata, Best Practices: Establish Your Metadata Plan, after a document about metadata strategy. This document:

• Broadens the definition of metadata beyond “data on data” to include business rules, process models, application parameters, application rights, and policies.
• Provides guidance to help evangelize to the business the importance of metadata, not by talking about metadata but by pointing out the value it provides against risks.
• Recommends demonstrating to IT the transversality of metadata to IT internal siloed systems.
• Advocates extending data governance to include metadata. The main impact of data governance should be to build the life cycle for metadata, but data governance evangelists reserve little concern for metadata at this point.

I will co-author the next document on metadata with Gene Leganza; this document will develop the next practice metadata architecture based partially but not only on a metadata exchange infrastructure. For a lot of people, metadata architecture is a Holy Grail. The upcoming document will demonstrate that metadata architecture will become an important step to ease the trend called “industrialization of IT,” sometimes also called “ERP for IT” or “Lean IT.”

In preparation for this upcoming document, please share with us your own experiences in bringing more attention to metadata.