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.

“Digital” has replaced “Cloud” as the hot synonym for “Everything.”

No matter what a company plans to do and how it plans to do it, it’s now officially Digital.

Not that I’m a Digital skeptic. I’d just like, when we talk about “Digital,” to be confident we’re talking about the same thing.

Google a bit and you’ll find quite a few different accounts of why Digital is so important, along with several definitions, some of which, reprehensibly, make it a noun.

My favorite: Digital enables new business models. Examples include Uber, AirBNB, and Zipcar, all of whose “new” business models amount to being brokers — companies that bring buyers and sellers together in exchange for a cut of the action.

It’s a very new business model, certainly no older than the Phoenicians.

For whatever it’s worth (probably what you pay to receive KJR) here’s my take on why business leaders not only can’t ignore matters Digital, but have to embrace the subject. Truly Digital companies:

  • Observe: Constantly scan the technology landscape for the new and interesting.
  • Orient: Spend serious time and energy, at the executive level supported by staff analysis and modeling, investigating whether and how each new technology might turn into an opportunity if their company gets there first, or might turn into a threat if a competitor gets there first.
  • Decide: Far too many business executives and managers, and therefore whole businesses run away from the decisions that matter most as if they were rabid weasels (the decisions, that is, not the executives, managers and businesses). Digital businesses have to become adept at making fast, well-informed decisions.

And remember, it isn’t a decision unless it commits or denies the time, staff and budget needed to effectively …

  • Act: It isn’t enough to make the right decision and then either flail away at it or not actually do anything to make it real. Successful Digital businesses must execute their decisions, and with high levels of competence.

It’s OODA again. Digital businesses are built on OODA loops focused on the potential impact of new technologies. Not static list of specific technologies. New and interesting technologies as they arise and mature.

For Digital businesses the Orient stage has outsized significance, because many of us humans have a strong tendency to reject the new as either wrong or no different from the same old same old.

Digital businesses can no more afford to fall into that trap than the opposite extreme — dying from the shiny ball syndrome of chasing the next huge thing before giving the current huge thing a chance to succeed.

So Digital business have to establish methods, and not just methods but a supporting enterprise-wide culture, that let them go beyond the lip service of “that’s what we’ve been doing all along” to accurately recognize what really are familiar old concepts hiding behind shiny new buzz-phrases and what are truly new and important possibilities.

And none of this will matter if the company’s IT organization hasn’t figured out just how different the Digital world is from the standard collection of “best practices” followed by old-school industrial-age IT.

Recent history — how IT responded to two past transformational technologies, the personal computer, and the world wide web — illustrates the challenge. In both cases, IT ignored them completely until long after they’d become entrenched elsewhere in the business.

Why was that? Boil everything down and it came to this: When they first appeared, and for several years afterward, neither the PC nor the world wide web fit what IT did. They were out-of-scope, and outside IT’s current areas of expertise. CIOs didn’t know what to do with or about them, so it was safer and easier to declare them Someone Else’s Problem.

In the Digital era this attitude just won’t cut it because new technologies that can have an impact on your business are emerging faster than ever. Digital businesses need IT that provides technology leadership to the business, at all levels of the business, and at all levels of IT.

Technology leadership means more than just (for example) the CIO explaining to the other members of the executive suite how the Internet of Things represents a threat to the company’s current product line.

It means the IT organization knows how to recognize, research, pilot, and incubate new technologies. And, for those that succeed, how to integrate them into both the company’s technical architecture and IT’s organizational architecture.

All levels of the business and IT means the conversations between a help desk analyst and a workgroup manager about collaboration technologies are just as Digital as the CIO’s executive-suite conversations about the Internet of Things.

And are just as important.