In the early days of modern computer networking, SNMP (simple network management protocol) and CMIP (the Common Management Information Protocol) vied for dominance. SNMP’s main advantage was its simplicity. CMIP was more elegant and complete.

SNMP is still in wide use. CMIP is more footnote than deployed technology.

# # #

Agile development relies in part on an old, old, principle: Big systems that work started life as small systems that work. The need for TLAs being what it is, in Agile the small system that works is called the Minimum Viable Product (MVP). It’s the system’s irreducible core, and the team’s earliest development goes into defining, programming, and perfecting it. From that point forward, everything else the team builds constitutes an enhancement to the MVP.

Waterfall methodologies aren’t all that different, except for one thing: Agile teams deploy the MVP for actual business use, while Waterfall teams don’t release software into the wild until the whole application is finished. As a result, Agile but not Waterfall teams learn of needed course corrections while in course.

# # #

I know a woman who tried to launch a business. It was, she told me proudly, so complicated that she was one of the few people around who could get it started and make it work.

She wasn’t and it didn’t.

# # #

Which leads to this week’s big idea: Simple is hard. Every increment of less simple is even harder. Starting out harder instead of simpler is usually the wrong answer.

It’s that simple.

Which in turn leads to enterprise architecture, why it’s so often disappointing, and an encouraging trend.

Why it’s so often disappointing: Enterprise architecture is intrinsically complicated, and that’s before its brain trust worked as hard as it could to wrap an impenetrable lexicon around it that separates the Cool Kids Club from lesser mortals who just want to put EA to practical use (for more, see “The Dark Secrets of Enterprise Architecture,” Bob Lewis, CIO.com, 6/8/2018).

Enterprise architecture is intrinsically complicated, and if you buy into this week’s big idea, that makes implementing it intrinsically problematic. Which, combined with numerous recent conversations and inquiries over the past few months, has led to a eureka moment:

Application rationalization is enterprise architecture’s minimum viable product.

What’s commonly called application rationalization is really three different rationalizations within technical architecture’s application layer: (1) true application rationalization (AR); (2) application portfolio rationalization (APR); and (3) application integration rationalization (AIR).

Application rationalization rates the health of each application in the company portfolio, assessed separately from all other applications.

Application portfolio rationalization looks for redundancies in the application portfolio — different applications that provide similar services.

Application integration rationalization reviews the interconnections used to synchronize redundant data, and to collect and present data from multiple “systems of record” (the IT view) as if they were a single coherent “source of truth” (the business perspective.

Together, AR, APR, and AIR determine the optimal disposition of each application, and of the collection of application interfaces and integrations, and then develop a plan of action for achieving those dispositions.

These dispositions range from replacing an unhealthy application; to updating otherwise serviceable applications that are too many versions behind what their vendors currently support; to re-writing those whose functionality is necessary but whose engineering is, to use the technical term, hideous; to sunsetting all but one of a collection of redundant applications … to list just some possible potential dispositions out of the complete list of possibilities.

Also, while this description emphasizes the applications themselves, undertaking any rationalization within the application layer almost always has ripple effects throughout all parts of the business that make use of the affected applications … which is to say, at one time or another, the entire business.

Changing any application will affert how the work supported by that application gets done.

The impact could be negative — disruption. But that doesn’t have to be the outcome. Unhealthy applications usually lead to some level of pretzel logic in the business processes and practices that make use of them.

For example, a process that could otherwise happen in real time might include one or more one-day delays as a consequence of the need for overnight batch processing.

Another process might require users to consult three or four different applications just to figure out what’s going on so they can respond to what should be a straightforward customer inquiry.

So rationalizing the application layer can, if everyone approaches the situation from the right perspective, lead to more effective employees and a more effective business.

All by cleaning up the technical architecture without ever admitting that’s what’s going on.

# # #

If you need help cleaning up your organization’s application layer, don’t be shy — use the Contact form and we’ll schedule a conversation to talk it over.

“He stabbed me in the back and then threw me under the bus,” a colleague complained, once upon a time.

“Well, at least he got the sequence right,” I managed to keep myself from saying, recognizing that discretion is sometimes the right solution for even the best of straight lines. I was also was just smart enough to avoid offering just-too-late advice.

There will come a time, in your career as in mine, when you find yourself on the wrong side of backstabbing, under-the-bus throwing, or scapegoating, either separately or in some combination.

In case you are or might be vulnerable, here are some pointers.

The first: As is almost always the case, an ounce of prevention yields the usual utility, so be on the alert for warning signs. Some I’ve seen:

Your manager isolates you from key relationships. Backstabbers and scapegoaters rely on their ability to control what others hear about you. If you have positive working relationships with some people who matter and your manager lets you know he’ll be their liaison from here on in, to ensure everyone hears a consistent message or some such pretext … watch out. There’s a good chance the consistent message will be that you’re the source of whatever problems might be cropping up.

Your manager informs you that it’s important to control what his manager hears. There are a couple of variants of this:

Variant #1: “She won’t have the patience for the complexities of the situation.” She might not, unless it’s something that’s about to blow up. And as your manager probably doesn’t understand the problem to the level of depth you do either, and as it is about to blow up, guess who’s being set up to take the blame.

Variant #2: “Alarming her about the risks and issues we’re facing would be counterproductive. We need to handle this under the radar.” Same situation, different phony rationale. Especially in project situations, risk and issue management call for transparency, so everyone buys into the remediation plan.

If you’re told to conceal the facts, make sure you receive this work direction in writing, and make sure both your manager’s name and his manager’s name are on the documentation.

And if your manager accuses you of just trying to cover your posterior, your answer is, “You bet I am. If this blows up in all of our faces, I’m the one who will need the cover.”

Closely related: You decide to discuss a situation directly with your manager’s manager and she gives you air time but expresses no real interest in the situation or your recommendations.

It might be that you cry wolf a lot. If you do, stop. If you don’t, your manager might be setting you up to be a scapegoat later on when things do blow up.

You stop hearing from people you used to interact with frequently and casually. If this happens to you, it might be you’ve done something to cause it. Assume that is the case and take steps to fix whatever you broke.

Even if you didn’t break anything, use your concern as the entirely legitimate pretext for circumventing a backstabber’s attempts to warn people off when it comes to being your friend and ally.

And, it all blows up anyway. The fact of the matter is, it’s much easier to be on the wrong side of backstabbing, bus-throwing, and scapegoating than preventing them from happening. No matter how much you work to preserve and fortify your working relationships with the people who matter, backstabbers are what they are because they’ve learned how to succeed through these tactics.

They’re better at this game than you are.

If it happens to you, your manager will likely recommend that you not try to fight the outcome or dispute it.

Sometimes, that’s good advice: Fighting it keeps the subject alive, where moving on to something else can give you a clean start … so long as those whose image of you has been tarnished aren’t an important part of your future.

But don’t take your manager’s word for it. After all, his name is on your performance so he isn’t a disinterested advisor. More, if you decide to fight back your manager is left with two bad choices: (1) Back you, which means he expends political capital on your behalf, or, (2) participate in burning you instead.

For your manager it’s a no-win situation. For you it’s a tough, tough choice.