If your IT architecture is like nearly everyone else’s IT architecture, you’re stuck with IBM’s IMS, largely because it’s hard to get rid of.
But if you think that’s a problem, take a tour of the Mississippi River here in Minneapolis. Or just read about it here: “Feds, state of Minnesota both deny responsibility for hidden hazard beneath St. Anthony Falls.”
St. Anthony Falls (pictured above) was, for a very long time, an essential ingredient of Minneapolis’ commerce infrastructure. Among its contributions: It powered a lock and dam to support barge traffic, while powering sawmills, flour mills, textile mills, and hydroelectric generation.
Regrettably, the location’s geology turned out to be too fragile to sustain the falls in the face of all that commerce. The falls would have disintegrated had the Army Corps of Engineers not, from 1874 to 1876, installed a massive concrete wall to protect it.
That was 150 years ago. Between then and now the wall has gone without any inspections or maintenance.
Or ownership. The Army Corps of Engineers says the wall belongs to the State of Minnesota. Unsurprisingly, the State of Minnesota insists the wall belongs to the Army Corps of Engineers.
All stakeholders, no ownership
Think of the Wall as Minneapolis’s metaphorical IMS — dangerous to leave alone and unmanaged; expensive and tricky to get rid of.
Read much about IMS and you’ll be told that just about the entire Fortune 1000 still uses it, and that “its security and scalability are ‘unmatched.’”
That’s almost certainly an exaggeration, a convenient excuse to justify leaving it untouched. I say this because Amazon.com doesn’t use IMS, and yet it’s still able to handle comparable transaction volumes without sacrificing the flexibility and adaptability associated with more modern database management platforms.
(And no, AWS’s October failure isn’t relevant: Its outages had nothing to do with scaling limitations. It was a good old-fashioned DNS goof-up, not a DBMS that couldn’t handle the transaction load imposed on it.)
What does the St. Anthony Falls wall have to do with this?
The wall has no owners either — major stakeholders yes, owners no. In a typical business IMS also has no owner.
Except that it does. Look at IT’s org chart and you’ll find it, as plain as day. It’s the box labeled “IT Architecture Management,” a function that has loads of authority coupled with no budget to speak of.
Loads of authority coupled with no budget to speak of is an almost perfect definition of bureaucracy. Its authority gives it ample clout to say no, while its lack of budget means it can never say yes in a meaningful way.
Except you still own it
Looked at from a different angle, however, the concrete wall has not a lack of owners, but two of them — the Army Corps of Engineers and the State of Minnesota. IMS, and, more generally, any technical architecture saddled with “chronodebt,” also has more than one owner. Not always, but squint just a bit and their ownership will come into focus.
Imagine your applications portfolio includes a commercial application suite that’s built on IMS (or some other problematic platform). The vendor that licenses the suite to you is even more of an owner than your technical architecture team.
Which gets us to a good-news/bad-news situation, the good news being that you’ll have an awfully hard time finding a commercial enterprise suite built on IMS. Like the dinosaurs that legacy systems are often likened to, they’re long gone.
The bad news? Where there’s a lot of IMS there’s a whole lot of legacy systems whose “vendor” is you.
Unless you can get ahead of the risk
IMS differs from the St. Anthony Falls concrete wall in one crucial respect: Unlike the concrete wall, there’s little risk that IMS will fail catastrophically. That might read like good news, and it mostly is. There is accompanying bad news, though, namely, that IMS has little risk of catastrophic failure.
Why is that bad news?
When it comes to the concrete wall, if I was a bettin’ man, I’d bet the State of Minnesota will bear whatever costs there are to be born to make sure the concrete wall doesn’t fail catastrophically. That’s because, if the wall comes tumbling down, the Army Corps of Engineers will experience serious embarrassment, but in the city of Minneapolis, pedestrians will have to wear snorkels.
Brinksmanship favors whichever owner anticipates the most damage should risk become reality.
The reason IMS’s small likelihood of calamitous harm is also bad news is that there’s nothing on which to build a sense of urgency.
IMS deals out death by a thousand cuts. Its hierarchical data model is archaic, but then, as a general rule, IT has to integrate with it, not design and build major applications on it.
No, the thousand cuts are the difficulty you’ll have finding talented staff to work on it.
Somewhere in all this there’s a way to extend the concrete wall metaphor to the difficulties of recruiting talented and motivated staff interested in supporting IMS-based applications.
I’m sure there is. Danged if I can find it, though. In the meantime, if you’re stuck with a concrete-wall technical architecture, now isn’t too soon to figure out who, other than you, owns it so you can start building a sense of urgency for doing something about it.
See also:
