I don’t get it.

I just read Lucas Carlson’s excellent overview of microservices architecture in InfoWorld. If you want an introduction to the subject you could do far worse, although I confess, it appears microservices architecture violates what I consider to be one of the fundamentals of good architecture. (It’s contest time: The first winning guess, defined as the one I agree with the most, will receive a hearty public virtual handshake from yours truly.)

My concern isn’t about the architectural value of microservices vs its predecessors. It’s that by focusing so much attention on it, IT ignores what it spends most of its time and effort doing.

Microservices, and DevOps, to which it’s tied at the hip, and almost all variants of Agile, to which DevOps is tied at the ankle, and Waterfall, whose deficiencies are what have led to Agile’s popularity, all focus on application development.

WAKE UP!!!!! IT only develops applications when it has no choice. Internal IT mostly buys when it can and only builds when it has to. Knowing how to design, engineer and build microservices won’t help you implement SAP, Salesforce, or Workday, to pick three examples out of a hat. Kanban and Scrum might be a bit more helpful, but not all that much. The reasons range from obvious to abstruse.

On the obvious end of the equation, when you build your own solutions you have complete control of the application and information architecture. When you buy solutions you have no control over either.

Sure, you can require a microservices foundation in your RFPs. Good luck with that: The best you can successfully insist on is full access to functionality via a RESTful (or SOAPy, or JSON-and-the-Argonauths) API.

Halfway between obvious and abstruse lies the difference in cadence between programming and configuration, and its practical consequences.

Peel away a few layers of any Agile onion and you’ll find a hidden assumption about the ratio of time and effort needed to specify functionality … to write an average-complexity user story … and the time needed to program and test it. The hidden assumption is that programming takes a lot longer than specification. It’s a valid assumption when you’re writing Angular, or PHP, or Python, or C# code.

It’s less valid when you’re using a COTS package’s built-in configuration tools, which are designed to let you tweak what the package does with maximum efficiency and minimum risk that the tweak will blow up production. The specify-to-build ratio is much closer to 1 than when a team is developing software from scratch, which means Scrum, with its user-story writing and splitting, backlog management, and sprint planning, imposes more overhead that needed.

And that ignores the question of whether each affected business area would find itself more effective by adopting the process that’s built into the COTS package instead of spending any time and effort adapting the COTS package to the processes they use at the moment.

At the full-abstruse end of the continuum lies the challenge of systems integration that’s lying in the weeds there, waiting to nail your unwary implementation teams.

To understand the problem, go back to Edgar Codd and his “twelve” laws of relational data normalization (there are thirteen of them; his numbering starts at zero). Codd’s framework for data normalization is still the touchstone for IT frameworks and methodologies of all kinds, and just about all of them come up short in comparison.

Compare the process we go through to design a relational database with the process we go through to integrate and synchronize the data fields that overlap among the multiple COTS and SaaS packages your average enterprise needs to get everything done that needs to get done.

As a veteran of the software wars explained to me a long time ago, software is just an opinion. Which means that if you have three different packages that manage employee data, you bought three conflicting opinions of what’s important to know about employees and how to represent it.

Which in turn means synchronizing employee data among these packages isn’t as simple as “create a metadata map” sounds when you write the phrase on a PowerPoint slide.

To the best of my knowledge, nobody has yet created an integration architecture design methodology.

Which shouldn’t be all that surprising: Creating one would mean creating a way to reconcile differing opinions.

And that’s a shame, because a methodology for resolving disagreements would have a lot more uses than just systems integration.

Consider the Titanic.

Based on entire minutes spent Googling, it appears the ship’s lookout spotted the iceberg that sank the ship when it was about 2,000 feet away. This seems like plenty of time to steer around a hazard, and it would have been plenty of time — at 20 knots, almost a full minute — had the Titanic been, say, a fishing trawler.

It wasn’t. It was the biggest ocean liner of its day, and even with a rudder 78 feet 8 inches high and 15 feet 3 inches long, its turning radius at full speed was about 1,900 feet.

1,900 feet being a shorter distance than 2,000 feet, it appears there was enough room for the Titanic to miss the iceberg. But history and John Cameron tell us it didn’t miss.

What went wrong? It turns out the decision as to whether to steer around the hazard or to maintain course turns out to have been quite a bit more complicated than hindsight makes it appear. If this makes no sense to you: The ship might have missed the iceberg, which was after all in motion, by maintaining course; trying to steer around the iceberg might have resulted in impact closer to the stern, doing more damage; reducing engine power to reduce speed would have reduced the rudder’s effectiveness, to name three complications among many.

In the end it was a judgment call that took 37 seconds to make — enough time for the Titanic to have missed the iceberg. If you’re interested, read “The 30 seconds that sank the Titanic — fatal delay in order to change course doomed liner,” Jasper Copping, Daily Telegraph, 12/4/2011.)

Which has what to do with the worlds of IT, business, and their intersection?

Start with 20/20 hindsight. I’m assigning you the mission to allocate blame … sorry, to determine the root cause. You start with the most basic question: Was the problem that the ship’s turning radius was too big, or that it took too long to decide to change course?

The answer is, of course, yes.

And now (at last!) we’re ready for business, IT, decision-making, and all things Agile.

As we all know, IT has to adopt Agile. If you don’t use Agile techniques by now you’re two hops short of current thinking, current thinking having moved to DevOps, which is itself a hop short of what’s actually needed.

Among Agile’s many benefits compared to Waterfall alternatives are two sides of one coin that gets far too little attention.

Side 1 is Agile’s ability to reduce the damage done by the management fad du jour.

Something largely unappreciated about fads du jour is that in the eyes of the managers who sponsor them they aren’t fads at all. They’re responses to important business trends, marketplace shifts, new and better thinking … that sort of thing. But time passes, sponsors move on or lose influence, gratification is less than instantaneous, and the executive leadership team (ELT) moves on to whatever is next in queue.

But in the meantime, through various governance mechanisms rooted in Waterfall-based assumptions about how much time and investment is needed to make change happen, a very large fraction of the company’s total discretionary budget is directed to turn the fad du jour into operating business reality.

Which in turn makes it unavailable for other, more valuable but less strategic uses for timescales measured in years.

With Agile techniques, companies can slow down or stop business change efforts sooner and still get some value out of them because Agile delivers working stuff in timescales measured in weeks (sprints), and tangible business change in months (releases).

One of Agile’s most important characteristics is a governance mechanism that, depending which Agile variant you use, changes priorities dynamically in these same timescales.

Which in turn means fads du jour‘s resource commitments don’t have to be any longer than this.

Side 2 is the exact same thing, only instead of mitigating the damage done by fads du jour draining resources away from higher-value efforts, it accelerates the value provided by projects that with Agile deliver business change in months instead of years.

In Titanic Governance terms, it means decisions about how best to avoid various business icebergs can be made faster and changed faster.

While it’s stretching the metaphor just a bit, Agile itself is parallel to reducing the Titanic’s turning radius. Agile Governance, done right, decides to turn to avoid the iceberg faster.

Done wrong, the same old governance, unconsciously based on the same old Waterfall assumptions, can crash even the best Agile project practices right into the same old decision-delay icebergs.