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.