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.
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.
Have you read the "Art of the long view"? It is a book about strategic planning at Shell. In that book they talk about coming up with four potential futures and then building a plan that will allow you to adjust to changing business circumstances.
It could probably be applied to architecture, but I doubt that many organizations have the resources to do this kind of activity in any real level of detail.
I have personally found that writing a short paper about tradeoffs between a few different architectural approaches and implementation pathways is more helpful. In comparing and contrasting them you find the key business reasons why you might go down one path or the other. This in turn enables you to genuine chat with the business owners about what they want and when they want it.
The usual splits I have done in looking at future views are usually along the lines of bespoke vs off the shelf, centrally managed vs. federated, high road vs. low road, etc. It is usually the business owners risk appetite, budget and degree of balkanization in the business that will drive one approach or the other.
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?
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.
@ 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.