Archive

Archive for August, 2009

Babies, Bath Water, And Enterprise Architecture Maturity Models

August 27, 2009 6 comments

Recently I took a look at an EA-maturity-model-cum-roadmap from Leo de Sousa, Manager of Business Application Services and Enterprise Architecture at the British Columbia Institute of Technology (click to read Leo’s blog on EA CMM). To my surprise, I liked it. Why was I surprised?

I have never liked EA maturity models. Yes, tracking progress is important. And yes, there should be a consensus about what characterizes a mature EA practice. But I don’t like how they would ostensibly be used to compare one enterprise with another, a la benchmarks. Perhaps I was soured on them by seeing them used as a governance technique in US federal agencies.

The Office of Management and Budget (OMB) required agencies to assess themselves against a standardized maturity model, with progressive hurdles in successive years. Federal agencies, accustomed as they are to all sorts of oversight and compliance mandates, know how to pass compliance audits. Did you ever wonder how (then) Popkin System Architect got so popular  in the federal government? An EA tool was required to demonstrate a certain level of EA maturity and System Architect was the lowest-cost offering at the time (I’m sure there are other reasons as well). Behavior was around letter-of-the-law compliance, and it seldom catalyzed getting with the spirit. Even when Dick Burk at OMB introduced a clever workaround in a second version of the model — you could leapfrog to a level 4 if you showed actual business benefits, regardless of what other checklist items you missed — agencies simply marched through the maturity level checklists getting the requisite items done. The scores were good, but in my opinion they overstated the degree to which EA was ingrained in the culture of the agencies.

And then there’s the notion of a single number representing an enterprise. In most reasonably large organizations, there is some degree of federation of the EA effort. Some business units might have very advanced practices, while others have virtually none, and the enterprise-wide practice may have an entirely different agenda. What does one do, rate all units and average the number? That would be a pretty meaningless metric.

Source: Leo de Sousa, Manager, Business Application Services and Enterprise Architecture, British Columbia Institute of Technology

Source: Leo de Sousa, Manager, Business Application Services and Enterprise Architecture, British Columbia Institute of Technology

So, I’m afraid because  of all this I threw the proverbial baby out with the bath water regarding EA maturity models. But I like Leo’s. He took some fairly standard criteria and modified them to fit his organizational goals and processes. They still resemble other CMMI-like level criteria, so his 3 would be similar to someone else’s 3, but that’s not the main point. The point is to create a roadmap for where he wants his EA practice to go, and then rate and report actual against plan. This approach is about creating a tailored roadmap to consciously mature your EA practice; it is not about scoring maturity of implemented architectures.

No big deal, you say? I tweeted about this and a couple of wise EA folks who usually respond to my tweets essentially said “of course, you have to make it your own, what else would you do?” making me wonder if I’ve been missing the boat all along.  But I don’t think this is a prevalent attitude about EA maturity models. I think the general idea is to rate one’s org against where it ought to be, by some industry-standard scale. I don’t find that worth much. I think an organization should understand where they are and where they want to be, figure out how to get there, and track their progress. If someone else’s model of how EA can improve your org helps you describe your goal or your path, great. But generic doesn’t work — for any generic goal statement, you must edit it into terms specific to your enterprise. And don’t set any goals without including the statement “as measured by ___.” You can use the Goal-Question-Metric technique for filling in the blank, but that’s a topic for another day.

To really manage your EA agenda, I’d recommend taking the maturity model as a roadmap a step further and also populate it with goals that don’t fit the standard CMMI scale language.  For example, if you have an incipient information architecture or business architecture practice, place goals and milestones related to expanding and formalizing those efforts on the roadmap. I’ve been interviewing people about their information architecture initiatives and working with Forrester analyst Jeff Scott on approaches to business architecture that can be broken down into a cookbook-like  sequence, so watch this space for more on phased approaches to these aspects of architecture initiatives.

How do you all measure EA progress in your shops? Do you use a maturity model? And/or have you created concrete custom goals with associated metrics and measure against them? Take the quick poll below and we’ll all get to see!

Will Business Architecture Initiatives Put A Permanent End To Business-IT Alignment Problems?

August 21, 2009 3 comments

An early 2009 Forrester interview with the CIO of a retail firm produced a great quote: “Our business execs have two views of IT: a big budget blob or their BlackBerry.” Now, maybe those retail business execs think of IT as a strategic budget blob, but it’s more likely that’s a shop with alignment issues. If that CIO’s business execs don’t see technology as enabling anything more than mobile email, then they really don’t get the power of technology and they’re not going to see the value in the IT department.

But alignment issues are not limited to shops where business execs don’t see value in technology. The whole IT-to-BT transition is about how the business is enthusiastically embracing technology – they’re just not bothering to go through the IT department to find it, deploy it, or use it. Today’s alignment problem is more about the gap between the business’s valuation of technology’s potential and their valuation of the IT department’s ability to deliver on that potential.

Enterprise architecture (EA) has always had the capability to bridge that gap. Now, I certainly can’t claim that all or even most organizations that implemented an EA practice have solved all their alignment problems. But the simplest explanation of how an EA program is supposed to work would stand in for a perfect formula for aligning any enterprise: Map out the current and future states of your organization’s business, information, application, and infrastructure architectures, create the detailed roadmaps that spell out how to go from where you are to that desired future state and bingo! Business execs would know exactly what IT was up to and why they were doing it. They’d be cheering and carrying their IT and EA pals on their shoulders on the way to the next stockholders’ meeting.

What? Hasn’t happened to you yet? What could possibly be wrong? Perhaps it’s that most EA programs haven’t exactly executed the classic formula. Perhaps EA has focused almost entirely on technology and applications and the business has perceived EA – if it has indeed been perceptible at all to the business – as just another thing IT was doing that didn’t matter much to them. Maybe until very recently, for most organizations the business architecture piece has been missing in action (and let’s talk about information architecture another day). No business architecture, no relevance to the business community.

But all that is changing. Suddenly it seems business architecture is the hottest topic in EA circles. When I spoke to clients at Forrester’s IT Forum in May and our EA Forum back in February, business architecture was practically all anyone in the EA role was talking about, whether their EA practice was 10 years or 10 days old. A variety of forces have conspired to make technology-only architecture initiatives seem only marginally worth pursuing. These forces include a relentless drive for value – which implies an accompanying drive for transparency – and a continuing breakdown of the insularity of the IT organization.

But for whatever the reasons, business architecture programs are taking off, and I think that wherever they get traction they will finally put an end to business-IT alignment problems for good. Why? Because whatever the form of the business architecture program, business and IT will interact regularly and work together on addressing business problems and attaining business goals. Business execs will become invested in the connection between implementing the to-be business architecture and the rest of the enterprise architecture domains, at least in terms of the dependencies. And of course, IT will recognize the opportunity to communicate meaningfully with their business partners to ensure complete transparency and to relate all IT resource expenditures to business goals.

But wait a minute, back up – did he say “whatever the form of the business architecture program”? Isn’t there a cookbook of best practices that everyone can follow? The fact is that best practices are evolving, but at this point there are many approaches to business architecture initiatives. Jeff Scott and I have written a series of case studies on business-focused architecture to showcase the different approaches and provide a context for the value they are producing. We also presented a webinar on August 5 that discussed three of the case studies briefly and presented Forrester’s approach to starting business architecture initiatives. We touched on a number of issues, either through the planned agenda or the lively Q&A, including the role of business architecture in the context of the larger EA program and recommendations for the right business architecture artifacts. Regarding the latter point, I discussed a capability map from one of the case studies (see below) and Jeff talked about this type of representation as the “Rosetta stone” for business-IT alignment, which got some traction in the Twittersphere.

DHL Capability Map

In the concurrent chat session embedded in the webinar, we covered a number of very interesting questions, but, given the circumstances, we really just touched on them lightly. Some of these issues clearly warrant further analysis and discussion, such as:

How would we reconcile the two opposing views presented in the case studies, where IT management was intimately involved with business architecture discussions in one case and locked out of the room in another in order to avoid biasing the discussion with current system constraints?

What are the best tools for creating business architecture artifacts? How important are the more elaborate EA tools?

How might capability maps work in organizations that have advanced ITIL/ITSM practices? Or that have successful APM/PPM efforts? Wouldn’t this form of business architecture artifact work well in analyzing IT as a business?

I invite anyone who attended the session or accesses the archived version to post comments here on the above questions – or any related issues for that matter. There are plenty of best practices to be surfaced as this area is still evolving.

There is actually a lot you can accomplish with business architecture, from finding efficiencies to launching new business capabilities to transforming the business. Important as it is, attaining business/IT alignment, the subject of the webinar and this blog post, can seem like just a beneficial side effect when you consider the high-impact possibilities.