All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

“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.

Comments

|In: Architecture|Last Updated:

Don’t apply traditional IT portfolio governance to shadow IT.

Why? Start with two iron-clad rules of IT portfolio governance:

  • No business sponsor, no project. With shadow IT, sponsorship is automatic. If nobody in the business cares at sponsorship levels the project wouldn’t be happening. A formal governance check is superfluous.
  • The only legitimate outcomes are “no” and “when.” There’s no maybe, and no priority scoring. With formal IT, approved projects are those added to the master schedule, to start when the necessary staff are available to work on them.

With shadow IT, the whole point is that the business area undertaking the project isn’t willing to wait.

The entire reason businesses need so-called IT governance … really, business change governance … is because of scarcity. In most companies there just aren’t enough IT developers to satisfy the business appetite for change and improvement.

Scarcity isn’t part of the shadow IT equation. Rather than trying to get their slice of the IT developer pie, with shadow IT, business units own the whole pie.

Does this mean shadow IT should be governance-free?

Yes … but no.

“Governance” almost always means “a committee must review this.”

That’s the no. Just as we have to restrain our natural impulse to strangle idiots, so, in business, we should restrain the impulse to form committees.

The yes comes from what we might call the John B. Finch principle: “Your right to swing your arm leaves off where my right not to have my nose struck begins.” (Oliver Wendell Holmes usually gets the credit.)

Shadow IT projects (really, shadow business-change projects) have three noses in range:

Re-keying: Shadow IT tends to deliver “islands of automation,” unintegrated with the rest of the company’s applications and information portfolios. That often results in the need to re-key data from other systems into the shadow-IT system, and to re-key data from it back into the company’s systems of record.

The former isn’t a problem. If the department head decides re-keying into the system is just fine, it is, by definition, just fine.

But the latter? If the re-keying must be performed by employees who report elsewhere, the project might violate the Finch Principle. It doesn’t if they’re keying the data now and this just changes the source. But if one manager is shoveling new work into a different department’s inbox, it’s a Finch Principle violation.

Fortunately, there’s a committee-free solution readily available. All the manager whose nose has been put out of joint has to do is document the offense and its budget impact. The result: The Finch Principle violator has to bear the expense. The company budgeting process obviates the need for separate governance.

Data exposure: Imagine the point of a shadow-IT system is to facilitate working with an external partner. Now imagine it inadvertently exposes sensitive data beyond the walls of the corporation. It’s a clear Finch Principle violation.

Happily, there’s a committee-free solution to this too. It’s a policy, probably an existing policy: InfoSec reviews all systems that are used by or expose data to outsiders.

Data governance: A popular approach to IT integration is the “federated architecture” — an environment that looks like a unified whole even though under the covers it’s been assembled from a variety of COTS and SaaS solutions.

A major challenge for federated architectures is reconciling data definitions so that data entered into one system can flow into the corresponding fields in other systems without mishap. As those in the trenches know while those who rely on PowerPoint do not, semantic mismatch, not field-level synchronization, is the big challenge to systems integration.

Shadow IT systems will often ignore the usual controls for this because it’s an eye-glazingly boring problem. Unless, that is, you’re either responsible for the integrity of the IT architecture, or genetically predisposed to lexicography.

Even if integration happens through re-keying, semantic mismatches can pollute data in the company’s systems of record.

The solution, to the extent there is one, doesn’t require a committee, although regrettably, many companies rely on committees to handle data governance.

Companies that want consistent data create and maintain some sort of glossary (data dictionary or encyclopedia) for that purpose. Everyone who uses data relies on it.

Which in turn probably means you’ll need to create some form of “Glossary Police” to make sure even shadow IT projects adhere to its definitions. But please … don’t make the Glossary Police a committee.

You’re better than that.

Comments