All Posts in Architecture

Enterprise Technical Architecture Management

|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

|In: Architecture|Last Updated:

I’m working on a (probably) three-part sequence on technical architecture, to be part of the IT Management 101 series I’m writing for CIO.com. As a famous person once said about health care, who knew architecture is so complicated?

This isn’t a substitute for it. It’s more along the lines of stray thoughts you might find helpful in assessing and managing technical architecture in your own organization.

Beware the seductive siren call of metaphor. The parallels between technical architecture and what professional building designers do are limited at best, and dangerous at worst.

The work of professional architects begins with a sketch and ends with blueprints. Technical architects don’t create blueprints, and if they did they would be embracing waterfall methodologies.

Agile methodologies don’t rely on blueprints of any kind. They often do rely on the equivalent of a sketch, but if so it’s the business analyst / internal consultant who draws it.

Crowdsourcing is a dicey way to gather data. Given how much information you’re going to want about each component in your portfolios, crowdsourcing it … sending out questionnaires to subject matter experts … is tempting.

Given that many enterprises can have a thousand or more components across all of their portfolios, crowdsourcing might not just be tempting – it might be unavoidable.

So if you do crowdsource your data-gathering, make sure you educate all of your information sources in the nuances of what you’re looking for.

And, assuming they do complete your questionnaires, curate the daylights out of the information they provide.

Version is data. Currency is information. You should include in your technical architecture database how current each component is, “current” meaning whether it matches what the vendor currently ships (fully current) or, descending through the possibilities, whether it has fallen out of support (obsolete).

Keeping track of which version of a component is deployed in production is relatively straightforward – just make sure than any time the responsible team installs an update they know to update the architecture database to match.

But what you care about is how current the component is, and you can only determine that if you know the product’s full version history, so you can match your production version to its position in that history.

Currency scores are, of course, perishable. As they change each time a vendor issues a new release, someone needs to keep track of this across every commercial product in every portfolio in your architecture.

It isn’t just your technology that has to stay current. You have to keep every piece of information you collect about each component in your architecture current, too.

You collect information about each component of your technical architecture. Some of it is constant. But quite a lot may change over time. For example, you’ll probably want to know how well each application supports the business functions it’s associated with. But business functions change, which means an application’s business function support score changes along with it.

So your information-gathering process has to operate on a cadence that balances the sheer effort required with the rate of decay of information accuracy.

Bob’s last word: Speaking of balancing effort and information it’s tempting to collect a lot of data about each component in the architecture. Tempting, that is, until you pivot from collecting it the first time to updating it on a regular cadence, over and over again.

In the framework I use, I’ve identified about 30 attributes just for the application layer of the architecture. That’s a starting point. An important part of the process is whittling them down to the essentials.

Because 30 is too big a number. Ten will usually do the trick.

Bob’s sales pitch: I’m still whittling down the CIO.com architecture articles to their essentials. I’ll let you know when they’re available for your reading enjoyment.

Comments