Has the concept of “alignment” entered the infamous “trough of disillusionment?”

By |2011-05-31T03:33:42+00:00May 31st, 2011|Enterprise Architecture|

In the May 15th issue of CIO magazine, there is a rather interesting article, especially for Enterprise Architecture practitioners.  The article, written by Stephanie Overby (a freelance writer), is titled “RIP I.T. Value” and opens with the following paragraph:

The end of IT-business alignment is nigh.  And no one is happier about it than the business focused CIO. 

“If you stand in front of an audience of CIOs and start talking about IT-business alignment, at best you get eye-rolls and at worst, you get people walking out of the room” says Shawn Banerji, a New York based CIO recruiter with Russell Reynolds Associates.  “Alignment has been a big trend for quite some time and—as with most trends—it has gotten a lot of lip service.  But the ability to move beyond that into the practical manifestation of IT and the business being one is a progressive reality for a lot of organizations today.”

Reading down through the article, I’d like to include some interesting excerpts:

Excerpt 1:

According to Gartner, by 2015, the primary factor determining incentive compensation for the CIO will be the amount of new revenue generated from IT initiatives.

Excerpt 2:

CIOs used to measure their personal value by budget or headcount and their team’s value by delivering on time and on budget.  “That’s an arcane approach to measure your relevance,” Banerji says.  “Historically, they’ve talked about alignment because that’s all they could possibly hope for.” Today, CIOs are more likely to be rewarded for overall business performance than for some technology project or initiative, Banerji says. 

Excerpt 3:

CIOs further along in their efforts to measure business impact are putting IT-centric measures like uptime and systems availability on the back burner to focus on business goals like customer retention and operating efficiency. 

To be fair to the author, the article cites some fairly well-versed individuals.  In addition to the recruiter (Banerji), it also references current CIOs (Louie Ehrlich, CIO of Chevron, and Brian Hardee, CIO of Oxford Industries), a Gartner VP (Dave Aron), and a well-placed attorney (Edward Hansen, partner, Baker and McKenzie).  I do not fault the author.  However, I wonder if we are throwing the baby out with the bathwater.

In most businesses, IT is not a front-office endeavor.   Clearly, deep information integration is blurring that line, but only partly.  If IT moves to be revenue focused, I am concerned that IT can lose sight of 80% of its’ value: keeping the lights on for the parts of the business that traditionally make money. 

Now, also to be fair, the quotes from the cited CIOs reflect a focus on changing the measurement structure, not ignoring existing business.  To whit, one very interesting example at Chevron where the old “99.9% uptime” metric has been augmented with a “business incident index” that tracks the number of IT service issues that affected business and the impact of each in terms of revenue and reputation.  This is healthy, and I applaud this kind of metric.  I’m simply concerned that we keep focus on many of the existing metrics as well, and not change CIO compensation to focus on new revenue to their exclusion.

Interesting, also, is the fact that the author never mentions Enterprise Architecture.  Clearly, we need to be reaching out much further than we are.

What do you have to say, fellow architects?  Is the trend towards “IT as business value provider” healthy?  Are there risks here?  What should we do to mitigate them?  What is the opinion of the EA community in this development?

Metamodel 101

By |2011-05-26T17:42:17+00:00May 26th, 2011|Enterprise Architecture|

I was just privy to a conversation about the value of creating a specific kind of metamodel, and it made me wonder… if I had to explain the concept of a metamodel to someone, how would I do it? 

First, let’s start by defining the term “metamodel.”  The IEEE Online Software Engineering Vocabulary (SEVOCAB) provides 12 different definitions for the term ‘metamodel’.  In my opinion, the definition most applicable to enterprise architecture is this one:

CDIF semantic metamodel. (1) the description of the set of concepts and notations used to define a model (ISO/IEC 15474-1:2002 Information technology — CDIF framework — Part 1: Overview, 4.2) Note: The CDIF semantic metamodel defines an Entity-Relationship-Attribute model that is used to construct and define models used in systems development.

Peel away the jargon, and you get this: a metamodel defines the stuff that you put into your models. 

For example, I created this model of a fictitious company, Contoso.  They have created some strategies, and the Enterprise Architect has tied those strategies to business initiatives and those business initiatives to the business units that are impacted by those initiatives.  (A simple traceability model).

Contoso Traceability

If the diagram above is a model, what is in the metamodel?   That’s the diagram below:


In this metamodel, we provide definitions for three terms: strategy, initiative, and business unit.  They are meaningful in the context of the model and should have a single definition.  In addition, the metamodel defines every relationship that is allowed between these elements.  We can say that an initiative may involve a business unit, but our model cannot show the relationship of a business unit to a strategy UNLESS there is an initiative that is aligned to that strategy and which involves the business unit.

A metamodel restricts what you can draw.  It prevents you from drawing things that don’t make sense.  And it clearly defines the terms so that when someone reads your model, they know WHY you described some things as strategies and other things as initiatives (for example). 

A metamodel is the grammar and definitions of words.  It provides the dictionary.  The model itself is the story you tell with those words. 

Tutorial over for the day!