Enterprise Initiatives – A Train Built By Monkeys

Business leaders demand alignment, right? 

Many folks frame enterprise architecture (EA) as a function that is necessary because organizations need alignment.  In that mind set, the primary value proposition of EA is to create initiatives that are aligned to strategy, are feasible, well scoped, and should result in a fit-for-purpose organization and information infrastructure.  In this way of thinking, it is up to the enterprise architect to figure out what trains need to leave the station, where they are going to go, and when they need to arrive.  All the passengers have tickets and all the conductors have schedules and everyone is set and ready to go.

Note that I highlighted two words: “create initiatives.”  In this view of enterprise architecture, once those initiatives are created, their work is done.  Projects teams “drive the trains” and move the people and get the work done.

Source: Train Wallpapers

I have a problem with this viewpoint.  Consider this question:  Does enterprise architecture “go away” after the initiative is framed, business case is proposed, and the funding cycle is complete? 

The answer is emphatically “no.”   

Alignment is not your (real) problem

You see, the real problem is NOT alignment.  It’s execution.  Creating a great strategy is tough, but getting your organization to change to meet that strategy is far tougher.  Sure, part of that problem is solved with alignment.  Alignment is necessary because it gives you the right mix of things to do.  It is essentially a planning activity.

But execution is not a planning activity.  There are far more screw ups in the execution than in the planning.  So if the EA is trying to bring about the changes that an executive has demanded, in order to make a strategic change actually occur, he or she cannot stop when “alignment” has been achieved.  The role of the EA has to continue all the way through execution to make sure that the “train” (the initiative) reaches the right destination.  That is why, within Microsoft Services, we refer to Enterprise Architecture efforts using a “framework for value realization.”

The Train Metaphor

The train metaphor is problematic because we think of a train as a tightly engineer marvel of modern efficiency running on a pair of rails that are carefully laid out.  Initiatives are not like that.  Business initiatives are like a train built by monkeys. They are not remotely similar to marvels of modern efficiency.  They are noisy, rattling, energy wasting, Rube Goldberg machines that would fall apart at the drop of a hat if not for the efforts of many people, often unsung heroes, who keep everything moving in the same direction.

What’s more, that train is running on a network of tracks that interlock and weave and visit multiple places from different directions, full of dead ends.  There is rarely a central dispatching office(PMO) watching over the whole operation and even when there is, it rarely has good information on which to base decisions, reducing it to a status-reporting role.  Without oversight and plenty of assistance, the business initiative “train” may end up stalled in some wayward place, abandoned.

Photo: R. Lowsek Source: Uyuni – Bolivia’s Train Graveyard

Execute the Strategy -- Keeping the Monkey Train Running

Enterprise architects have a duty to complete their mission: execute the strategy and realize business value.  Creating the schedule and planning the route is not enough to deliver business value.  An enterprise architect must actually ride the train (or watch to make sure it moves through a particular set of stations).  He or she must listen to the rattles it makes as it switches from one direction to another, evaluate the alternatives of design and implementation, and consider whether the train is carrying too much or too little cargo (scope) for it to handle.  Most importantly, an enterprise architect must be focused on making sure that the train, upon reaching the destination station, actually delivers value when it gets there.

All too often, a train (project) will drop scope or change course along the way.  It may get to the right station, eventually, but along the way, the conductor had to lighten the load, so he dropped a few cars.  The conductor (project manager) declares success when the train hits the station.  To him, it doesn’t really matter if the time delay caused by the "Left Turn at Albuquerque" meant that the cargo missed its connection. 

According to project management professionals, it is up to the business stakeholder to make sure that the value is delivered properly.  The enterprise architect has nothing to do with it, right?  The twist is that the operational business stakeholder rarely cares about the enterprise perspective.  He or she may be interested in “local success” that can be reached,  regardless of the compromises taken along the way.  In this case, both the project manager and the business stakeholder declare success, while the actual value needed to reach the strategy is lost.

So success leads to failure.  The train gets to the right station, perhaps even “on time,” but without actually delivering the value.  The wrong cargo is delivered or it was left behind along the way.    This describes countless “business initiatives” that I’ve seen over the decades.  It’s so common, we have a term for it: watermelon project (green on the outside, red on the inside).  Maybe we should call it a “dead strategy walking.”

The Role of Enterprise Architecture in Oversight

A business initiative is not a smooth, well oiled machine.  If it were a machine, it would be a train built and operated by monkeys.  Parts would fall off, or be added on, for reasons unexplainable, and the direction taken would depend on the whims of political decisions that can seem arcane and undecipherable on a good day.  Getting an initiative going is not the hardest thing you will do in your life.  Far tougher is riding atop the initiative train, making sure that it doesn’t do really dumb things, or fall off the rails, and gets to the actual intended destination with the value proposition intact.

An enterprise architect is an invaluable element for ensuring that business value is actually realized from an initiative.  An EA will collect metrics, prior to the initiative, that illustrate both the problem to be solved and the various other measures of productivity and business value that could be impacted as the program proceeds.  He or she will do more than just collect and report on value realization.  He or she will use the opportunity of collecting this information to guide key decision makers towards decisions that maintain enterprise value and away from decisions that diminish enterprise value.

The enterprise architect, in the best case, is involved in key decisions through this oversight process: how processes are to be changed, where activities (both operational and change focused) should occur, how people will get ready for change, how the change will be orchestrated to ensure that operations don’t lose value, what information will be leveraged, what systems will be impacted and in what way, what lifecycle considerations must be taken into account (both service, information, systems, and technology life cycles), and what dependencies will be created or relinquished. In most of these decisions, the EA is not the final decision maker.  He or she is there to provide the “enterprise perspective” and argue on behalf of senior leaders whose strategy may be impacted.  In a best case decision matrix, an EA would be able to escalate a disagreement to a governing board that includes a broad array of enterprise stakeholders. 

Conclusion

The role of an Enterprise Architect is focused on much more than simply “aligning initiatives to strategy.”  They are also called upon to oversee those initiatives as they proceeds through execution, and to advocate on behalf of the enterprise all along the way.  Let’s recognize that a plan has no impact on an organization… only the initiative that follows the plan (or not) can change things.  When the Enterprise Architect oversees these initiatives, he or she has the opportunity to fulfill their promise to execute strategy and realize business value.

Comments

• Anonymous
  June 03, 2014
  Hello Nick, Thanks for a great blog! My favorite phrasing is that it is an enterprise architect's job to "align":

• strategic value with information (and IT) capabilities
• structure and consistency with change and impact (your point)
• business demand with information (and IT) supply (and reversely, by the way) That's not an either-or, but a three-way split without any train schedules or railway networks fixed upfront. And with different roles in decision making. What a job! Cheers, Paul

• Anonymous
  June 06, 2014
  The comment has been removed