All Posts in Technology

|In: Architecture|Last Updated:

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.

Comments

|In: Industry Commentary|Last Updated:

Travel is supposed to broaden the mind. Regrettably, after more than 21 years of writing this column, my mental ruts seem to resist travel’s broadening impacts: Everything I see turns into guidance for running businesses, IT organizations, and all points in between.

And so, following a couple of weeks touring in Rome and exploring bits and pieces of Sicily …

> The Romans built the Colosseum in eight years, with no project management or CAD software to help them. It’s about 2,000 years old and still standing. That should worry us.

> The Colosseum’s construction depended on two innovations: concrete, and interchangeable parts built to standard specifications. If any Roman architects, artists, or engineers suffered from change resistance, those who embraced the innovations apparently drowned them out.

> The Colosseum’s standard program was executions in the morning, followed by slaughtering exotic animals, followed in turn by gladiators trying to hack each other to bits.

I think this means we have to give the Romans credit for inventing standing meetings with standard agendas.

It also suggests they were early victims of the consequences of bad metrics. Because every day started out with executions, the Roman courts had to convict enough suspects of capital crimes to fill out the program, whether or not a sufficient number of capital crimes had been committed. I presume the parallels are obvious.

In any event, combining the morning executions and gladiators who got the old thumbs down, a million corpses exited the Colosseum’s fabled arches during the years it was in session, although the pace slowed a bit when Rome became Christian and did away with the gladiators.

I guess that was progress. Speaking of which, for the Roman Empire, conquest was what you did if you could. Now, it’s frowned upon. That’s progress, too, I guess.

> While walking through the Pantheon our guide pointed out a row of headless statues. They weren’t, he assured us, early examples of Dr. Guillotine’s work products.

It was due to Roman parsimony. Coming from a practical society, Roman artists figured out the average statue would greatly outlive the person it had been carved to honor. And so, they designed their statues to have replaceable heads.

In IT we call this “modular design.”

> We didn’t spend all of our time in the Colosseum (and Pantheon and Forum). We also toured the Vatican, where, in the Basilica, we saw evidence of St. Peter’s tribulations. As it happens, visitors rub St. Peter’s feet for luck. No, not St. Peter himself but a bronze statue thereof. Bad luck for St. Peter. After centuries of this his feet are being rubbed right off, toes first.

I’m pretty sure we in IT have parallels to muster. If not, elsewhere in technology land I’ve read we’re running out of helium, one birthday balloon at a time.

Sicily has been more relaxing, at least from the perspective of spotting IT parallels. I’m hopeful this might mean I haven’t completely lost my ability to disconnect from the world of information technology. But there is Mount Etna, an awesome and awe-inspiring site.

> On the not-a-parallel-at-all front, shortly before its recent eruption, data integrated from a variety of sensors reported a 10 centimeter increase in the mountain’s elevation (about 3 inches if the metric system isn’t your bag; also about 3 inches if it is your bag only you don’t need me to handle the conversion for you).

Where was I? Oh, that’s right, 10 centimeters, and I hope you aren’t so blasé that you aren’t awed by our ability as a species to measure such things with such precision — a precision that allowed geologists to warn everyone potentially in harm’s way so they could get out of harm’s way.

> On the back-to-parallels front, Mount Etna doesn’t have just one crater, although the main caldera is enormous.

It has hundreds of craters. That’s because, when pressure increases and the old eruption paths are plugged, the magma doesn’t metaphorically say to itself, oh, gee, I guess I’d better calm down and head back to the earth’s mantle.

Nope. The pressure is there, the result of physical forces that can’t be eliminated and physical laws that can’t be repealed.

The result: The magma has to go somewhere, and where it goes is the path of least resistance, culminating in it pushing through the side of the mountain, resulting in a new eruption and new crater from which it spews out.

The business/IT parallel is, I trust, clear: Good luck trying to stamp out shadow IT, which is also the result of pressures that won’t go away just because you want them to.

It’s time for me to head back to the beach. The IT parallel? None.

Ahhhhhhh.

Comments