Archive

Archive for the ‘Maturity models’ Category

Good Order-taking Is Not Good Enough

October 19, 2009 Leave a comment

I’m currently dealing with a client whose IT department is pretty good at being an order-taker. But the business folks are dissatisfied. An LOB exec told me “when we told IT we wanted [a particular solution] they should have probed for what the real issues were and then come up with a better solution than what we asked for. They should have pushed back.” I don’t know about you, but I find this remarkable.

For years IT has struggled to be the best possible order-taker. Back in 2006, Forrester defined three archetypes of IT: The Solid Utility, the Trusted  Supplier, and the Partner Player (see  the first figure). These archetypes are progressive: you can’t be a Trusted Supplier without also being

IT Archetypes

IT Archetypes

a Solid Utility, etc. It took a lot of work to be a solid utility by providing cost-effective dial-tone reliability with transparent, constantly declining costs. And then it took a lot of organizational maturity to attain Trusted Supplier status by nailing projects and consistently delivering on-time, on-budget, and to spec. So when we talk about being a Partner Player, being at the proverbial table and helping to move the business forward, it really sounds like IT management nirvana — we’re going beyond technical execution into the strategic realm.

Of course, EA programs can help at each phase (see the next figure). EA can help by defining

EA Enables IT Archetypes

EA Enables IT Archetypes

and governing to the standards and technology strategy that make IT cost-effective to run and support, and by baking these standards into application patterns that take a significant amount of risk out of development projects. And by pursuing business architecture, EA can begin to have the strategic discussions that will lead to being perceived as a Partner Player.

But back to the IT department I mentioned at the beginning of this post. These folks are crying out for architect-led interactions at the brainstorming stage, but their organizational culture and their processes currently prevent the whole “dream with me” stage described by Eric Hendrickson in his comment to a previous post. Making those interactions happen and formalizing them into regular occurrences is the way to nail the alignment problem and move into strategic discussions. But for this organization it’s not a nice-to-have — it’s as big a black eye as failing to provide a sound infrastructure or always being late with projects.

If this is generalizable to the industry at large, then getting to be a Partner Player is no longer an aspiration that would be nice to achieve but a no-big-deal-if-we-don’t-nail-it-this-year sort of thing. Being a Partner Player is  just meeting expectations. It’s just what the business perceives as necessary to utilize technology in a way that will enable them to survive, compete, and excel. And my take on this client so far is that they are a relatively conservative organization, so if their business folks have this expectation of IT, many others do also.

That means the bar has been raised. IT organizations must evaluate themselves and see if they’re headed in this direction soon. If not, it’s time to change something: change your organizational design, change your processes, change your strategy, change whatever you need to change to make this happen. And since I’m an EA guy, I have to say my view is that the EA effort is where to place your bets.

Comments welcome and encouraged, of course. Take another 30 seconds and take this quick poll — how would you characterize your organization?

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!