ebizQ's Business Agility Watch

From the ever-lucid Tony Baer, president of OnStrategies:

Is it merely coincidence that the acronym for Service-Averse Architecture is SAA?

For those of you whose hair turned white long ago -- if you have any of it left -- you'll recall SAA as standing for "Systems Application Architecture," IBM's ill-fated plan to standardize the way you wrote software for its countless mainframe, mini, and microcomputing platforms of the 1980s.

Why the history lesson?

Both SAAs are/were destined to fail. Both were developed on the principle of emphasizing expedience over architecture. If you have incompatible platforms, it's easy to specify software APIs, but it's more of a stretch to believe that a standard would ensure that an app written using the same standards for user access, programming interface, and communications support could paper over the architectural differences separating batch from interactive computing.

Similarly, skipping the user consultations or the up front architectural planning dooms a development team to repeating past mistakes... over and over again.

Of course, services are not the universal solvent -- not all apps or use cases lend themselves to the loose coupling that's intrinsic to SOA. But the implication of this modern reincarnation of SAA is that you actually want to expose applications as services, but aren't willing to do the homework.

Which reminds me of a friend of mine's senior year inscription in his high school yearbook: "For every question, there is an answer that is simple, direct, forthright, and wrong."