Let me go further: One CIO's "agility" is another CIO's "workaround". You and I both know companies where IT and the business units have successfully collaborated to circumvent - I choose that word deliberately - software or system constraints to provide new features or functionality to customers. Their "agile" circumvention enabled new value creation. Is this how we want to define agility? You are called upon to be agile precisely because uncertainty, unreliability and exceptional circumstances materialize. In this instance, business agility means swiftly implementing the exception rather than the reliable rule.

As I listen to IT users who interact with both customers and members of the supply chain, I am struck by how often the subject of agility pops up more as a response to overcome technical limitations than as a vehicle to exploit existing system capacity. You have to admire the ingenuity of IT folks and their business counterparts to get added value from a system in spite of itself. Success comes from a creatively agile subversion.

So here's a CIO challenge: Look at the last 20 initiatives within your enterprise that you would define as agile. Make a list. Then, circulate the list among trusted subordinates and business colleagues whom you respect and ask them: "Which of these initiatives reflect a successful workaround of existing constraints? The logical exploitation and expansion of our existing capacity? Or a new, clean-sheet innovation?"

We all know what the most common answer will be. Hint: It doesn't involve real innovation.

My concern about agility is that the business and IT communities talk about it as if it's more about architecture than about attitude. If only we have the right technical and business architectures, then we can be more responsive and anticipatory. As with most architectural aspirations, it looks good from the outside. In reality, how many architects design their buildings to be constantly modified, upgraded, altered, enhanced, improved, and changed for less time and less money? Read Stewart Brand's superb book, How Buildings Learn: What Happens After They're Built, for a brilliant exposition on why most architects and their buildings fail to deliver value.

Similarly, the reason why so many companies commit to ERP and enterprise computing is that they define agility as a function of what C-level management has control over, not what line managers can control and influence. When we talk about agility, we must ask: "Agility for whom?"

To answer, "agility for the enterprise" is an act of Dilbert-esque weaseldom. Whose enterprise? The CEO's? The business line managers? That of the customer-touch folks? Or the people who work with the mission-critical suppliers? Or the customers? If we're championing agility for all of those constituencies, there's no architecture in the world robust enough.

Pragmatism matters. Agility exists in context. Agility for the CEO is not the same thing as agility for the supply chain executive or the call centre manager. Refusing to define whose agility we wish to enhance is an act of cowardice.

Today's lust for agility is symptomatic of the deeper issue: Who is really responsible for responsiveness? The people who "lead" or the people who do the real work of the enterprise? Is agility a euphemism for recentralization or is it an honest bid to give more people more power to adapt their software and systems to reality? Either way, the call for agility is a call for a new economic science of implementation. In fact, it means talking about a marketplace of point solutions and ephemeral workarounds that change as soon as circumstance does. That's profound. You can't implement agility without agile implementations. That said, when agility means cutting corners and tweaking process rules, you can be sure there'll be a backlash brewing sometime soon. Today's agility is tomorrow's loss of control. What goes around, comes around.

Michael Schrage is co-director of the MIT Media Lab's eMarkets Initiative. He can be reached at schrage@media.mit.edu