Work-back Enterprise Architecture

We are all familiar with the notion of a work-back schedule: a date driven schedule where we start with the end in mind, and work back to the present time, figuring out what tasks we can accomplish in that time frame.  Anything that doesn’t fit, we don’t do.  Creating a work-back schedule is an iterative process.  You describe the results at the beginning, but if you cannot deliver those results in the time you have, you figure out what you CAN deliver.

I was having a chat with another architect today who asked why we don’t do this for enterprise architecture… and I didn’t have a good response for him.  My viewpoint has often been to solve a small problem and “scale out,” (kind of EA + Agile), but his question was interesting…

Why don’t we jump ahead, four years, and describe the “Ideal” state, and then WORK BACK to today, describing what each of the steps would be to get there.  And then iterate.  If we cannot get to the “Ideal” state in four years, answer the question “What can we do in four years?” 

All too often, I’ve seen enterprise architecture described from the “Ideal” state with no respect for time.  It is as though the Ideal state is some goal hovering out in the ether, with no connection to reality.  Thus, it is easy to criticize EA as being detached from reality, because the models ARE detached from reality.

What may simply be a better approach is to describe an Ideal state based on principles and best practices, and then temper that with a work-back process, just as we would for a time-bounded project plan. 

With a work-back approach, the EA team could create multiple possible “future” states and get IT leadership to pick one, rather than having everyone buy off on an ideal state that is pretty, but unrealistic. 

Once you have an attainable “future state” model, then hide the “ideal state” in a desk drawer.  Don’t refer to it.  Use the realistic version that is actually reflective of the budget, appetite, skills, flexibility, and political realities of the IT organization.

The realistic model becomes the “future state model” that is discussed, and described, and shared, and evaluated.  It is the one you discuss because it is possible, not because it is “right” or “ideal.”  Possible trumps Right. 

Simple.  Makes sense.  Yet, in all the discussion of EA that I’ve read and walked through, including the various EA frameworks that I’ve studied, I’ve not yet seen a description of using a work-back process to describe the future state for EA models. 

What are your thoughts?   I’m interested to know.

Comments

• Anonymous
  July 28, 2009
  I am a big fan of doing future state first.  The reason is simple, if you start with the current state, you are likely to permit constraints to pollute your view of the future state.  I always approach future state as if nothing existed and we are starting with a blank sheet of paper.  That allows us to be more creative and create a future state free of waste and legacy.  Once the future state is complete, then we do an assessment of current state.  The current state may prevent some things in the future state from happening, but at least you are able to get all of the innovative ideas out on the table before any are dismissed. My philosophy on this is that doing future state first ("blank sheet of paper" approach), prevents you from allowing the decisions of years gone by constraining today's though process.

• Anonymous
  July 28, 2009
  The comment has been removed

• Anonymous
  July 29, 2009
  Hi Mike, I have no problem creating an Ideal, for your use.  But do you socialize it? On the other hand, you could take your ideal view, and work back to figure out, in a couple of iterations, what you are able to accomplish in a specific time frame (say 4 years).  That would produce a "pragmatic" future state architecture. I'm suggesting that perhaps this pragmatic view is the right one to socialize, not the ideal view. Would you agree or disagree?

• Anonymous
  August 02, 2009
  Looks a lot like the business planning technique created by Clive Finkelstein. He allways retain a full pathway to the end target state so that the client can prioritize in what order capabilities should be reached. He is able to backtrack from all capabilities in the future states to the current state and show the effects of a choice made in the future.

• Anonymous
  August 04, 2009
  @ Mike Likewise I'm a fan of doing the future state first, but when you're in an extremely cost driven and risk averse organisation like mine that's been through several mergers and acquisition we've had to start at the current state to understand the consequences of making changes. My personal preference is take the strategic plan of the organisation and see how the processes, applications, data and technology align with it or not and then make decisions on what to tackle first to get all of those things in alignment with the plan.