Michael Schrage wrote recently in an Article in CIO magazine about the variance in the usefulness and definition of agility.
I think Schrage makes some valid points, buzzwords, initiatives need to be defined. And agility is much different than hacking around a previously unforseen problem. Also it does make sense to ask the question "agility for whom?". However, I feel like he fails to make a valid actionable point. Especially refering to the fact that architecture for buildings does not have as its purpose changeability. This is true, but no one is saying that IT architecture approaches the problem of design in the same way as building architecture. In other words, using the term from one industry in another (Architecture) doesn't mean it inherits all the problems of the source industry. ie. static buildings.
The true point of agility is to remove the inhibitors to change, and if done correctly this benefits all parties, except perhaps vendors selling monolithic product suites. What helps programmers take less steps to modify software, is the same thing that benefits administration who says tomorrow we are going here instead of there. Benefiting the "enterprise" is a worthy goal, albeit a bit abstract.
Can persons build architectures in a vaccuum that are far from practical? Absolutely. Do architects need to keep this in mind as they approach solutions? You bet. Just enough architecture just in time, should be the model, not the white tower of IT consolidation and governance.
Sometimes IT thought leaders have to say no to something that benefits the organization in the short run, because it pigeon holes them in the future. But in desiring to build an environment that removes the inhibitors to change, they themselves need to make sure their not in the way.
