Whether you?re interested in following my Agile Architecture approach to achieving greater business agility in your organization, or any one of several related initiatives, including DevOps, Lean, and others, there is one step you must take before you?ll see any increase in agility: clean up your mess.

I ran into this situation in a conversation with a client. They wanted a streamlined, Cloud-friendly application environment serving their diverse user base. Agile Architecture would certainly help them achieve this noble goal. The problem, however, was their existing legacy environment. It was a mess. And I don?t mean your everyday, run-of-the-mill enterprise mess, mind you. This one was a Gordian knot that would shame enterprises ten times their size.

Over the years they had built several custom apps (each out of a different department) and bought a number of commercial packages (again, with different stakeholders), each with their own way of handling and representing data. Next they had hardwired everything up with a series of point-to-point integrations following whichever integration style was popular at the time. Then, in an effort presumably to make some sense out of this rats? nest, they got two different ESBs to hook everything together. Only they didn?t get rid of the existing integrations. And the two ESBs don?t talk to each other.

Now they want to move to the Cloud. They see the rainbow in the distance and they want that pot of gold, and they want it bad. So they?re now looking for a system integrator with a magic wand they can wave to make the whole shebang agile, streamlined, and fully Cloudified.

True, they?re sorely lacking in anything resembling business agility. And they?re in desperate need of architecture. But the focus on their initial architecture effort should be on establishing the appropriate separations of concerns, so that they have some idea what they have and how each piece of the puzzle should fit with the other pieces. Then they must sketch out a roadmap, where they tackle issues one at a time in an iterative fashion, gradually resolving the existing complexities. Only when they?ve cleaned up the mess they have now will they be able to make real headway with the Cloud, or any other agility-driven initiative they may have.

In situations like this one, the risks are enormous ? and the primary risk isn?t that they won?t be agile on some particular timeframe. The real risk is that they will move too quickly on a modernization effort, and stuff will break. What they have today is dangerously fragile, like some towering Jenga game ready to collapse. Pull out the wrong block and you?ll have a disaster on your hands. The architect must take a page out of the Hippocratic Oath: do no harm ? regardless of how appealing that pot of gold under the Cloud rainbow may be.