Accenture has plowed $450 million into services oriented architecture (SOA) technology. With that much in the game, couldn’t it have done better than a talking head in its downloadable video?

(Truth In Journalism department: I stopped watching after either five minutes or eternity had gone by — I’m not sure which. Maybe some graphics appeared after that. If so, it was way too late.)

Accenture divides SOA implementations into four levels. The first level is dabbling just enough that a few vendors can include you in their “The following companies use our products” logo page in their PowerPoint presentations. The fourth level has something to do with business process flexibility and becoming Fully Buzzword Compliant (FBC).

(Truth in Journalism department again: I’m working from memory. By the time the video got to this subject my eyeballs had glazed over so my recall on the details might not be perfect.)

I shouldn’t be so sarcastic, I suppose. Level Four sounds suspiciously like a position KJR adopted a long time ago: That your focus should always be on how projects will improve the business, not on implementing the technology.

There is one clear difference, though. Lots of companies follow the KJR approach. According to Accenture, no company, including Accenture, has achieved SOA level four.

But Accenture knows how to get you there and will be happy to help.

Here’s what I don’t get: SOA was supposed to make things easier.

Let’s review. First we had assembler, and assembler jockeys who could talk to business people, figure out what they needed, and churn out huge amounts of write-only code that still somehow let the business move forward.

Then Admiral Grace Hopper invented COBOL to make things easier. Which it did until someone invented structured programming to make it harder again by making sure COBOL jockeys weren’t allowed to talk to end-users anymore.

After that, Codd and Date invented the relational database management system (RDBMS) to make things easier. Once everyone got over the need for ideological purity and accepted indexing technology, RDBMSs did make things easier, too. After awhile, even relational design stopped being an interminable obstacle. Someone must have goofed here. The most likely mistake: Data designers actually talk to end-users. That’s my guess, at least.

Somewhere in here, Fran Tarkenton gave up running toward his own end-zone to avoid getting tackled and invented Computer Aided Software Engineering (CASE). CASE was supposed to make things easier, but it never actually worked, so the methodology that started to evolve around it — making sure developers never talked directly with end-users — never became important.

CASE never got fixed, probably because right about then someone invented object-oriented programming (OOP) to make things easier. OOP was supposed to be more natural than structured programming, because objects were business thingies which business people could understand more readily.

OOP would have made things easier too — if for no other reason than because unlike COBOL, OOP provided “encapsulation” which means the subroutines that were (ahem) routine to FORTRANers finally made their way into mainstream IT.

Fortunately, the methodologists came to the rescue again, giving us Object Oriented Analysis (OOA) to make things harder. Not to cast aspersions on a family of methodologies with many fine attributes, but OOA does have its drawbacks. One is that it generates enough paper to decimate the Amazon rainforest. A second is that its terminology and artifacts are impenetrable to the average string theorist, let alone merely bright business managers.

And of course, OOA makes sure developers don’t talk to end-users. OOPs.

There’s a pervasive myth that technical people can’t talk to non-technical people. In this mythic universe technical professionals only marry other technical professionals. They give birth to little newborn technical professionals, go to churches, synagogues, mosques and temples with congregations composed solely of technical professionals, and have backyard barbecues only technical professionals attend.

This must be true, because otherwise, the moment technical professionals leave the office they magically acquire the ability to speak to everyone else, only to become selectively aphasic once more when the next workday begins.

I know far too little about SOA to say what I’m about to say with such certainty: I’m willing to bet the methodologies that are starting to envelop SOA make sure developers don’t talk directly with end-users.

Otherwise, SOA would still be making things easier.