Silver bullet, it just reminded me of this other “new” thing: ESB and SOA. Again, right about now, I'm reading about a national government agency that wants an enterprise-wide Service Bus “to glue it all together” (my own words) and create an agile, flexible service oriented architecture (yawn)

Now, how well have they thought about the different departments, each dealing with different business pieces, consumer sub-markets, various government (other parts of the government of course) regulations, different timings (8/5, 12/6, 24/7) etc?

The ESB must support SOAP over JMS outside, and SOAP over HTTP inside. Described in WSDL. Now I know exactly what they mean, but they don't have a clue themselves

Where's the business agreements going through? How do we get from nothing to perfect by just agreeing on the fact that we'll speak English. I mean, which English? British? Welsh? Scottish? Irish? Which dialect? Australian, American, Kiwi-an? Is Dunglish and Frenglish allowed as well?
Not a word about how to collect enterprise-wide services (= interfaces). How to describe them. How to maintain them. How to version them. How to have them fit-for-purpose for applications, consumers and businesses

It's going to be a long, heavy, dirty and political fight, and my company will seriously miss out on throwing consultants at this by the dozen, but I'm going to go all the way in order to stop this madness before they even try to detail design it

I am blaming the rise of architecture as a profession and institution for this. 10 Years ago people would just get fired or figuratively shot for silly ideas like these, and rightfully so
Now, these ideas are pinballed by and through CIO offices and Chief Enterprise Architects and Boards for months and years, and whatever factor of 100 pages rolls out because the money ran dry, it's become a fact of life, no matter how unpragmatic, inefficient, unflexible and guaranteed-to-not-ROI it is, and their will must be done

Yes, I do get excited every now and then. I'm an Enterprise Integration Architect, and I loathe the current way decisions are rolled down from the top through impermeable layers of management
We don't do IAD, RAD, RUP or Agile. We still LAD through our architectural and CIO departments. And that's just dead wrong

Sorry for this long comment, but thanks for the inspiration

Your comment reminds me of a comment by Gordon Murray, better known for designing the McLaren Formula 1 cars. He pointed out that fuel efficient cars that are fun to drive are easy to make: they just need to be small and light. There's no magic bullet that will endow Hummers (or other over inflated SUVs) with a small carbon footprint; technology can only chip away at the edges.

If enterprise IT were a Formula 1 car, then it would be something like the Mercedes-Benz W196, good in its day but heavy and slow based on what is possible today. Bolting a supercharger onto the W196 will not make it competitive with an MP4-24. It might accelerate a bit better, but the cornering and breaks will still be somewhat lacking.

You need to rethink the architecture of your business. It might still have four wheels and one driver, but everything else should be up for grabs. New, lighter and stiffer, materials (such as SaaS and Web 2.0) let us strip weight out of our business, creating something which the W196 will be unable to compete against.

Just another argument for the Business-Technology story

We did automate it all, on an ever growing scale. Then, we found out we had to govern it all as well. Maintain, change, retest, re-release, OMG

CRM and ERP were the next answers: one big carpet for all, amen. Well, that didn't work either. And, in the meantime, not only did the degree of automation explode within the company, but also the size of the IT department

Well, that didn't help either, creating one big elephant and still having to tweak and tune bits of that, that's where the conflicting cycles really start to hurt

Agile fixes some of these problems, although most Agile evangelists think documentation is evil period. I think reverse documentation during / after the go-live can be very cost efficient. Applications / federations without documentation, now that's evil

Turning your organisation into a network, business and IT-wise, will help too. I complained in a blog post about the size of IBM (no shares myself indeed), can anyone tell me how to move a 400K people company in any direction?
Integration will help glue the parts back together, make them sourceable, shoreable, cloudable, buyable and sellable

And, last but not least, we always always all of us make the mistake to “fix” an organisational or business problem by wheeling a flashy, techy solution. Preferrably by a third party…