All Posts in Architecture

Enterprise Technical Architecture Management

|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

|In: Architecture|Last Updated:

Old, old, theological IT joke:

Question: If God could create the entire universe in just six days, why does IT take so long to implement a new system?

Answer: God didn’t have an installed base.

What’s this have to do with keeping the joint running? At the risk of pointing out the obvious, in modern business, speed matters. If your company doesn’t continually improve its products, services, and practices as fast or faster than your competitors, pretty soon your customers won’t be your customers anymore because why would they?

The more sophisticated version starts with Colonel John Boyd’s OODA loop (observe, orient, decide, act). Very short explanation: If your OODA cycles are shorter than your opponents’, every time you Act you re-set them to Observe, effectively paralyzing them.

In business, speed matters. And in the 21st century, no matter what a business decides to do, it will need new or changed information technology to do it.

And yet, for the past few decades not only have a lot of business and IT executives actively slowed down IT, but many of their slow-down practices have been enshrined as “best practice,” while much of what’s required to speed things up is deemed too troublesome and expensive.

Three examples among many:

  • IT Governance: Governance is about is making decisions. But when the term “governance” enters the conversation, the subject is really preventing bad decisions and the preferred mechanism is a committee.

But preventing bad decisions means requiring everyone to ask permission before, for example, sneezing. And even the most efficient committee mostly makes decisions when it meets, not when someone asks for a decision. Committees can’t avoid causing delays.

Instead …

A faster and more-effective form of governance is educating everyone about the organization’s goals and priorities and making sure they’ve bought into them; keeping managers and supervisors in the loop; establishing a “culture of discipline”; and then entrusting most decisions to those closest to the action.

More effective? Yes. Most committees consist of people who represent constituencies, legitimizing constituency interests as a factor in making decisions (read “the silos win”). Decisions are political compromises — not a bad thing, but decisions and actions rooted in shared purpose and goals are usually better.

  • System integration: So many IT shops interconnect applications and databases with a spiderweb of custom-programmed batch point-to-point interfaces.

In one extreme case I worked with, IT Operations had more than a thousand interface jobs that had to run in strict sequence each night. Another client estimated that 80% of the total effort in most of its applications projects was invested in not breaking the interfaces.

No argument, uttering the words “federated architecture” makes it sound easy when it’s anything but easy. But in the long run the alternative to implementing some form of planned and engineered integration isn’t saving money. It’s wading through molasses.

Federate your architecture, or else achieve equivalent integration through some other means (two alternatives: use an ERP system as the architectural hub and primary access point; or build and rely on an operational data store for the same purpose).

  • Shadow IT: Who can get more done — 10 teams, or 100 teams?

This isn’t, for a change of pace, a trick question. The answer is inescapable, and yet most IT organizations, instead of being grateful for the help, do their best to stamp out shadow IT.

In case you’re unfamiliar with the term and the phrase isn’t self-explanatory, shadow IT is information technology implemented without the IT organization’s involvement or permission. You’ll find the case for encouraging it in “Stop stomping out shadow IT” (KJR, 9/4/2012); no point making the exact same points again here.

Let’s connect the dots.

Dot #1: In addition to adding to IT’s bandwidth, shadow IT adds speed for another reason: It’s beyond the reach of IT governance.

Keep it that way.

Dot #2: One disadvantage of shadow IT is that it produces “islands of automation” — un-integrated systems that usually make someone somewhere re-key data from the shadow IT system into existing systems and vice versa. Re-keying is error-prone and expensive.

Dot #3: As part of IT’s efforts to support shadow IT, it should change its role, and name. Maybe “Integration Systems” (IS)? IS can and should take its now-well-engineered system integration to the next level: Its new job is to provide APIs to shadow IT groups throughout the enterprise.

Far from adding risk, the impact is the exact opposite: By pushing all access through well-defined APIs, integration won’t just be easier.

You can make it as safe as you want.

Comments