Never Mind the TLAs, Good EAI Matters Anyway.
That made sense in 1997, when even BUYING something for $100k+ meant you’d spend another $200k+ in salaries customizing it. We did it for a fraction of that, with our raw talent and genius… oh we sure beat the system, didn’t we…
Then the system came back and beat us. Hard.
Over time, our legacy custom built software system became like a Soviet nuclear submarine — it was overly specialized, somewhat dysfunctional, costly to maintain and almost impossible to upgrade. True, we had the ability to customize any aspect of the system “on the fly,” and we could work our big bizdev deals into the platform (and therefore we could somewhat realistically promise anything to our partners), etc… but as time went on, the asymptotic curve of required effort vs desired result became punishing.
I knew this. I saw it coming, and I saw it happening. But I resisted anyway. Most of it had to do with cashflow (as in “We’ve got a system working, maybe it’s not the best, but come on… spend another wad just to make it BETTER? We’ve got marketing budget to cover...” etc )
Also, part of my reluctance was due to the opportunity cost, ie, an unwillingness to take current projects/improvements off track while conducting a system rebuild, with a very limited staff.
Those are all very ordinary issues, and those issues, in one form or another, predate software or even computers… or even technology. The pain of upgrading an established system is big. Even the ancient Sumerians grappled with legacy system issues: Despite having a new and improved language, it took the people of Mesopotamia many centuries to fully upgrade from their legacy systems for conducting business and civic affairs — and here we are today still using the 60 sec / 60 min / 24 hour clock!
So far so good. Nothing new here. Ok. Let’s figure out how to upgrade our e-commerce platform, balancing all these concerns.
But wait. There was just one more thing holding me back from embracing a new platform: Distrust of management consulting B.S., and in particular, all those pretentious-sounding TLAs used by software platform providers… and the analysts who cover them. “TLA” is a joke which, I still enjoy using. Let’s say I’m talking to a client/partner and I’m trying to explain some part of a software system (be it ERP, CRM, or some-such). I might say, “Well, that’s just another TLA,” and the other person says, “What’s a TLA?” and I say, “Three Letter Acronym.” <insert laugh track> I swear, I came up with the one myself. Yeah, I know, so did a bunch of other people. TLA. Hah! Gets ’em every time.
So anyway, we’ve all grown up, we’ve all accepted the industry nomenclature, we realize those analysts and consultants are actually pretty smart people, we’ve all gotten used to the fact that an “architect” is really just a software designer not someone who went through a very demanding and rigorous form of professional training blending art, design and engineering toiling long hours through many sleepless nights and having to present projects to a jury bi-weekly only to have those projects ripped apart, we all accept that the term “architect” can even be used as a verb even though this is an offense to the English language and besides it would be sufficient to say “design” when talking about the act of designing a database or piece of software, and we all accept that the best practice of Enterprise Architecture Integration (EAI) is a key business best practice that will allow an enterprise successfully leverage its value proposition to its stakeholders…. across… multiple channels… or something.
No, seriously. I see the light, cause right now we’re stuck in a customized Soviet-era submarine, and it’s taking all our energy just trying to avoid running aground.
If I had to do it again, I would have asked for a bit more money and hooked up with a good e-commerce platform…. well actually, if I have the luxury of perfect hindsight, I would have waited until 2001 before ditching my custom built, tricked-out, Soviet sub.