All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

Guess what’s now “best practice.”

A few years back it meant locking PCs down tight, preventing anyone outside IT from doing anything creative with information technology unless they could get it done with Excel.

“Shadow IT” … business departments implementing information technology without any IT involvement? An information security nightmare!

Nightmare? Look at the number of recent, massive data breaches whose targets have been … what shall we call the opposite of shadow IT … sunlit IT?

The actual evidence seems to show that shadow IT is, at worst, no less secure than sunlit IT.

The exact same cast of characters that advocated tight lockdown just a few years ago are now, without even a trace of contrition, writing favorably about how smart CIOs are supporting and leveraging shadow IT rather than trying to stamp it out.

Research current thinking on this and you’ll find the IT punditocracy has discovered IT has to handle some tasks more quickly than others. McKinsey, for example, calls it the “two-speed IT architecture.”

Welcome to the party, folks. You’re late. Did you at least bring some decent champagne?

To be fair: Just because these folks are latecomers, it doesn’t mean their insights are worthless. The McKinsey piece, while long on what the outcomes should look like and light on how to achieve them, is a fairly decent analysis.

Decent, that is, other than ignoring the significant role shadow IT will and should play in most two-speed IT architectures.

And, decent with this possible exception: “… companies need to improve their capabilities in automating operations and digitizing business processes. This is important because it enables quicker response times to customers while cutting operating waste and costs.”

If, by “quicker,” McKinsey’s analysts mean reducing cycle times for fulfilling orders, then fair enough. While the notion that information technology can be helpful in reducing process cycle times is hardly a fresh one, it’s no less valid today than it was when first introduced in the mid-1970s or thereabouts.

But “quicker” might also mean implementing new strategies or responding to marketplace changes. If that’s what McKinsey means by “quicker,” it’s way off, because optimized processes are one of the biggest impediments to rapid change. That’s because optimized processes need supporting infrastructure, and infrastructure encourages stasis, with “infrastructure” including:

  • Business process design. As these things go, this is the easy one. Designing an efficient process just isn’t all that difficult compared to what it takes to implement one. Visio is the most adaptive component of process infrastructure.
  • Design of business process controls. Beyond the process itself are management practices and process metrics. Designing them isn’t all that hard. Designing them so they don’t do more harm by getting in the way than they provide in benefits? Trickier. A lot trickier.
  • Design and build-out of the physical plant needed to support the business process. This could be as trivial as setting up a new cube farm, or as complex and expensive as designing and building a factory. Ignoring all other aspects of this task, whatever gets built will have to last long enough to be relevant until the company has paid off the design and build-out costs.
  • Design (or selection), implementation, and integration of supporting information technology. Presumably, KJR’s audience knows a thing or three about this topic. To make sure it doesn’t get lost: The integration part is, in most situations, the most expensive and difficult technical dimension of the task.
  • Employee training. The need to train employees is obvious. That their education is part of your business infrastructure is less obvious.
  • Investment in continuous improvement cycles until process optimization has reached the point of diminishing returns. No matter what the new process, it’s the organizational equivalent of a skill. Skills take time, and money, and effort to acquire and perfect.

There’s one more factor to take into account to understand why investments in business infrastructure put the brakes on business agility, and that’s the project failure rate.In most companies, more projects fail than succeed. That being the case, once a company has a process and its supporting infrastructure up, running, and optimized, the fear that implementing its replacement will fail isn’t merely very real. It’s realistic.

And when the odds of success are low, it’s perfectly natural for a company’s decision-makers to take what looks like the safer bet — sticking with that has worked, even if, in the long run, the result will be an obsolete company that sells and delivers obsolete products and services.

Especially because, in so many cases, by the time it’s impossible to ignore their obsolescence, it will be someone else’s problem.

* * *

Next week: Shadow IT’s role in a two-speed business (not just IT) architecture.

Comments

|In: Architecture|Last Updated:

Ben Franklin, we’re told, preferred the wild turkey to the bald eagle. It had, he argued, better character: Unlike the bald eagle it doesn’t steal food from worthier birds that caught their own, and doesn’t retreat from attacks made by birds a fraction its size.

Franklin didn’t comment on the wild turkey’s unfortunate resemblance to the turkey vulture.

In any event (you may take what follows wherever you like, but leave me out of it), the bald eagle’s noble appearance trumped the wild turkey’s noble actuality. So the bald eagle became our national symbol, leaving for the turkey status as our national meal and a decent bourbon.

What’s this have to do with IT? Franklin’s preference was architectural, driven by a set of core principles, while the Second Continental Congress’s preference was driven by superficial characteristics. (Okay, it’s a stretch. Sue me.)

Back to agile technical architecture and the role design principles play in its management. Last week’s column, you’ll recall, recommended establishing a small set of these to guide every project team that touches the company’s information technology.

To which a few correspondents politely suggested that design principles sound suspiciously like the sort of thing that looks fine on a PowerPoint slide but has little practical value.

A reasonable concern, so if you need convincing that a short list of big principles can be useful, consider the Ten Commandments. There are only (wait … carry the one …) ten of them, and of those a mere six govern human-to-human interactions. And yet quite a few folks consider them useful.

What topics should design principles cover? Not a comprehensive list, but to get you started:

  • Solve each problem once vs allow multiples: For most companies this is easy. To say. Solving each problem once keeps the architecture simple and streamlined, which is why most companies would prefer to have (for example) just one RDBMS instead of several.

The challenge is deciding what makes superficially similar problems the same or different. Take development environments. It would be tempting to standardize on just one, but as a practical matter it’s rarely possible. No matter how much you insist that everything be done in (for example) Visual Studio that doesn’t mean you can avoid JavaScript. And PERL. And …

  • Implementing functionality: Choices here are to either build everything to a common plan or to “buy when we can and build when we have to.” If the choice is to “buy when we can,” there are two sub-choices: Start with an integrated solution (e.g. ERP), using its modules whenever they’re a reasonably decent fit, or buy best-of-breed solutions.
  • Data integration: If you build everything to a single plan, you’re done. Otherwise you’ll almost inevitably have multiple commercial systems with some degree of information overlap. If that’s the case, your choices are:
    • In ERP-centric architectures, make the ERP database the hub of a hub-and-spoke data integration architecture.
    • Best-of-breed application portfolios generally become federated architectures. Two sub-choices here as well: An Enterprise Service Bus or something similar that takes updates wherever they happen and propagates them to equivalent data fields wherever they live; or an operational data store, which behaves a lot like the ERP database in ERP-centric implementations — as the hub of a hub-and-spoke synchronization system.
    • Or, you can choose to build custom point-to-point interfaces between systems on a case-by-case basis. It’s a bad choice, but it’s a choice.
  • Business logic integration: Just as you’ll find yourself with redundant data across independently designed commercial applications, you’ll also find yourself with redundant business logic. Somehow you need to keep this synchronized, too. Your choices:
    • Establish a single source of logical truth for each category of business logic, make it callable, and rip out the logic everywhere else, replacing it with a call, or …
    • Keep track of the redundancies and code in parallel whenever changes are needed.
  • Release currency: As mentioned last week, you can keep current or nearly so, or you can mortgage your future by waiting until you have no choice.

This is far from a comprehensive list of the subjects around which you can craft design principles. It’s to illustrate, not to fill in all the blanks.

Design principles like these guide design decisions on the part of application teams so they (1) do no harm; and (2) improve the architecture whenever they touch it.

That’s the point — that’s what makes enterprise technical architecture management agile.

And, as a practical matter, possible.

Comments