All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

Running IT is hard enough when all the CIO has to contend with are changing business demands. But these are far from the only “condition fluxes” IT has to deal with.

Take an example: Imagine some aspects of the business you support depend on a reliable, predictable, and immutable definition of the second.

No, not the second what, as in what comes immediately after the first.

The second. The unit of time representing 1/60th of a minute. The unit of time defined by the frequency of cesium atoms oscillating between their two stable quantum states.

The unit of measure on which, the meter, lumen, gram, ampere, degree (Kelvin), and mole depend.

The unit of time that’s in the process of being redefined by the world’s metrologists, a job title I just know most KJR community members aspire to. And before I mosey on to the next point, a thank you to my now-retired business partner, Steve Nazian, for pointing out the coming temporal redefinition to me.

Okay, maybe I’m overstating its potential impact, given that the change in a second’s length will be, at most, about one part in nine billion. Or maybe not, depending on the future of quantum computing.

Anyway, the question to be answered this week isn’t about the second itself. It’s about the coming challenge of tracking down all of the change’s ripple effects. Physicists and engineers around the world might, that is, have a whole new Y2K-like challenge in front of them.

Which (at last!) almost brings us to the point of this week’s rhetorical random walk: How well-documented is your technical architecture?

One more step and we’re there. The point isn’t about your architecture. It’s about you technical architecture management practices, not about how complete and up to date the documentation of your technical infrastructure, platforms, information repositories, applications, interfaces and integration, is not to mention the many-to-many mappings connecting your applications and business capabilities.

Here’s the point

Technical architecture management includes the concept of what’s usually but erroneously called technical debt, to correct which error I’ve suggested the term “chronodebt.”

I’ve defined chronodebt as the accumulated cost of remediating all IT assets that aren’t what engineering standards say they should be. chronodebt is what your IT organization owes the god of time.

Which leads to the question of what we should call the accumulated cost of remediating incomplete and inaccurate documentation of your technical architecture.

It’s chronodebt applied to IT management. It’s a debt that doesn’t come due until it suddenly approaches knee-capping-level urgency.

It matters because there will come a time … there always comes a time … when you need this information Right Now, because you need to track down the ripple effects of a redefined second, a modified business process, the integration requirements of new or updated software, integration of a newly acquired business, the need to provide documentation for a divestiture … really any change imposed on IT by changing circumstances beyond its control or ability to influence.

It’s management chronodebt – the entirely predictable result of striking the wrong balance between those management practices that are most urgent and which are most important.

Bob’s last word: The first law of preventive maintenance is that while you always have a choice between paying now And paying later, paying later almost always costs more.

But in order to implement any program of preventive maintenance, whether it’s managing IT architecture’s chronodebt or a factory’s mechanical and electrical systems, company leadership first has to recognize the existence of what we might call “management chronodebt” – the cost of having failed to invest in the management practices needed to manage technical chronodebt.

New on CIO.com’s CIO Survival Guide: The Edison Ratio: What business and IT leaders get wrong about innovation. Because when it comes to innovation, great ideas matter, But in the end, understanding the need to act on fewer great ideas matters more.

Completely inappropriate for KJR, but who can resist? I hereby nominate the distinguished judge J. Michael Luttig for membership in Bob and Ray’s “Slow Talkers of America.”

Comments

|In: Architecture|Last Updated:

Last week, posing as Tinkerbell, I asked you to let me know if you still find KJR valuable. Hundreds of readers took the time to answer in the affirmative.

For a writer, there’s no greater gift than having an audience. Thank you all for letting me know my weekly sermons are still useful.

# # #

I guess I’ll have to publish it here.

You might have already seen the now-not-so-recent piece on The Wall Street Journal’s editorial page, titled “It’s Time to Get Rid of the IT Department.” (Joe Peppard, 11/27/2021).

It isn’t all that different from Nicholas Carr’s tiresome and business-illiterate “IT Doesn’t Matter,” which, in 2003, led to his earning the Rocky and Bullwinkle Wrongway Peachfuzz award for polar opposite prediction. After all, here in the present, IT saved the world economy by enabling remote work during the COVID-19 pandemic.

That was after it became the centerpiece of business strategy, driving the Digital revolution.

Highly visible yet profoundly wrong ideas, even if they’re mere rehashes, require rebuttal, but the WSJ, by editorial page policy, doesn’t accept rebuttals. I guess they don’t like to be contradicted.

So I’ll have to publish my nominees for Mr. Peppard’s wrongest propositions here. Feel free to share.

Proposition #1: IT is a box on the org chart, with its own management hierarchy and budget, and that’s a problem.

KJR rebuttal: If a box, managers, and a budget are problems, they’re problems for every business function in the enterprise. Why single out IT?

Proposition #2: IT-as-partner is a bad thing. And I quote, The problem starts with what I think of as the “partnership engagement model” … While intuitively appealing  this model positions the IT island as a supplier, mandated to build IT solutions and deliver services to the mainland.

KJR rebuttal: Say what? IT as partner … more precisely, IT as partner in achieving intentional business change … is the polar opposite of IT as supplier to internal customers.

Proposition #3: IT is measured on inputs, not outputs. Examples: money spent, system availability, project completion rates, and, OMG! deploying technology on time, on budget and meeting the specs. These don’t, Mr. Peppard tells us, correlate with success.

KJR rebuttal: So fix the metrics. The solution to measuring something wrong isn’t to eliminate what’s being measured. And oh, by the way, if the specs are right, meeting them does correlate with success. If the specs turn out to be wrong, fix the process used to create the specs.

Proposition #4: The Crystal Ball conundrum. And I quote: The partnership model also assumes that it’s possible for the various corporate units to define upfront and many months in advance exactly what they will need from the IT department. The assumption is reinforced by the demands of the traditional yearly budgeting process.

KJR rebuttal: The problem isn’t reinforced by the annual budgeting process. It’s caused by the annual budgeting process. Solution: Fix the annual budgeting process.

Proposition #5: Decentralizing technology also requires some centralization. And I quote, excerpted from an account of an organization that supposedly has eliminated IT: Everybody has to use the same security protocols and software programming languages, and conform to a prescribed architectural blueprint when building digital products and solutions. But within those guardrails, employees have the scope to do whatever is necessary to get the job done.

KJR rebuttal: Presumably, these security protocols, languages, and architectural blueprint are created and maintained by IT professionals, who also establish protocols for assuring compliance. Presumably, these IT professionals live in a box somewhere on the org chart. What should we call that box? Wait … I know! … my hand is raised – call on me! … let’s call it “Information Technology!”

Bob’s last word: Boil it all down, and Mr. Peppard’s proposition is that business departments are in a better position to figure out the information technology they need than a centralized IT organization.

That is sometimes correct, and when it is, IT ought to support DIY IT efforts for all the reasons I’ve written about over the past couple of decades (see, for example, “Stop stomping out shadow IT,” 9/4/2012).

But Mr. Peppard ignores the very real complexities associated with sound, secure, and compliant technical architecture, and especially with integrating what would otherwise result in inconsistent islands of automation.

So DIY IT gets a thumbs up. IT-supported DIY-IT gets two thumbs up.

Making all IT DIY IT gets a big thumbs down.

Even if it does look superficially persuasive on The Wall Street Journal’s editorial page.

Bob’s sales pitch: In response to last week’s column, one commenter pointed out that I don’t make subscribing to KJR easy enough.

And so … if someone has forwarded this to you and you like what you read, here’s where you can subscribe: Subscribe – IS Survivor Publishing.

Comments