All Posts in Organizational Effectiveness

|In: Architecture|Last Updated:

There are, according to the KJR Manifesto, no best practices, only practices that fit best.

More often than not, though, “best practice” refers to neither. Most so-called best practices are really no more than minimum standards of basic professionalism.

Take a situation I’ve run into several times over the past few years: Whether due to mergers, acquisitions, and divestitures, years of IT being stretched too tight, or just plain sloppy management, IT can’t produce an accurate business applications inventory.

Clearly these IT organizations aren’t in sync with “best practices,” which call for instituting:

  • PMO (Program Management Office): The body responsible for reviewing, approving, and tracking all IT-related projects. The PMO matters because it’s the projects it oversees that change the applications inventory.
  • CMDB (Configuration Management Database): A repository that keeps track of What’s Installed Where. Business applications are among the “configuration items” the CMDB keeps track of, along with every piece of real and virtual hardware, server OS instances, DBMS instances, development environments … every item IT has to keep up and running.
  • CAB (Change Advisory Board): The organization responsible for reviewing all “change requests” (read “installation requests”) to make sure development teams, IT infrastructure teams, and anyone else trying to change the IT production environment has dotted all requisite i’s and crossed all corresponding t’s. Also, for making sure someone updates the CMDB to reflect every change.
  • EAMS (Enterprise Architecture Management System): An information system that keeps track of … well, of all layers of the enterprise architecture, from hardware at the bottom to platforms layered on it, to information repositories, applications, and the business capabilities, functions, and processes that depend on them.
  • ARB (Architecture Review Board): Enterprise Architecture’s enforcement arm — the organization that reviews all IT-related plans to ensure they conform to the company’s technical standards. And, for making sure every change results in an update to the EAMS.
  • Forms: Lots of forms, to make sure each change consistently updates the CMDB, EAMS, and enterprise project portfolio to keep them consistent with one another. Or, as an alternative, application integration that makes sure an update to any of these systems synchronizes the others.
  • MA (Mandatory Arbitration): With three different committees, each responsible for finding flaws in the creative work of other people, do you think all parties will agree? Envision the oarsmen on a trireme with multiple captains directing them to row in different directions.

Forget (or at least delay) best practice. Achieving the minimum standard of basic professionalism in all this is more than ambitious enough. And that’s having a single, trustworthy application inventory. What it will take:

Count each application once. Is the application installed on multiple servers in multiple locations? Doesn’t matter. Count it once. Do you have separate Dev, Test, Prod, and possibly other intermediate instances? Doesn’t matter. Count it once.

Do you have multiple versions or releases installed? That does matter — count each of these as separate inventory entries.

Determine application granularity. If you, like most businesses, rely on large-scale suites to support major business domains (e.g. Workday for HR, Salesforce for CRM, SAP for ERP), the suites aren’t granular enough. Make each module an entry.

If your business is at the other granularity extreme, microservices are too granular to track in the inventory. Go up a level and track the applications microservices assemble into.

Manage app/platform dualities. To take an example, SharePoint is both an application and a platform for building applications. Track these uses separately.

Track the bare minimum. For each application track its name, version, product owner (or non-Agile equivalent), IT support lead, a brief description, and vendor. If you can’t easily implement the inventory on a spreadsheet you’re being too ambitious.

Related: If you find yourself tossing around terms like “metadata,” stop unless you’re planning on using an EAMS for the job. Don’t even daydream about metadata until you have an accurate inventory.

Survey the business. Ask each top-level executive this question: “What are the five applications your organization relies on the most? Please reply; also please forward this survey to your direct reports, asking them to respond and also to forward it to their direct reports.”

Use the results to validate your inventory, but be careful. Your business respondents might not use the same application names you used in your list.

Enlist the PMO and ARB. Ask them to let you know of any new applications being installed, updates to existing ones, and retirements.

And finally, instill in everyone the first rule of inventory management: What the inventory shows today will be wrong by this time tomorrow.

Comments

|In: Cognitive Enterprise|Last Updated:

Culture is the new governance, and where it isn’t, it should be.

As my co-author Scott Lee and I pointed out in The Cognitive Enterprise, culture provides metaphorical lane markers. Formal governance mechanisms are more akin to guard rails — it you make contact with either one, something’s gone badly wrong.

Only sometimes, even culture is overkill.

Take posted speed limits. If you obey them because otherwise you might get a speeding ticket, that’s governance. If you drive five miles an hour faster than the posted limit, that’s culture — following an unwritten but near-universally accepted modification to what formal governance requires.

But when it comes to the choices drivers make about their velocity, governance and culture only matter when a far more powerful regulatory force isn’t in play — traffic.

When embedded in traffic, governance, culture, and personal driving preferences don’t matter. If the posted limit is 50 mph but the cars surrounding you are moving at a uniform 30 mph, you’ll drive at 30 mph.

It’s akin to states of matter. Light traffic is parallel to how gases behave — each molecule (car) moves along on its own with only infrequent interactions with other molecules. On public roads we don’t want these interactions to happen — they’re called “collisions” — which is why we have posted speed limits.

Heavier traffic is akin to the liquids, where fluid flows supplant individually independent molecular action. Driving in traffic is liquidity in action.

Add even more traffic and we discover how water molecules must feel when the temperature drops below freezing. Traffic jams and solid matter have a lot in common — nobody, whether drivers or molecules, is going anywhere.

(Physics minded readers might be wondering how the fourth state of matter — plasmas — fits into the picture. At the risk of beating the metaphor to death … race tracks?)

How does this fit into the broader subjects of culture, formal governance, and the decisions and results you, as an enlightened driver … no, wait, as an enlightened business leader … want to accomplish?

Heck, I don’t know. I just like the metaphor.

Not good enough? Okay, let’s poke at this and see where it takes us.

Most of us, most of the time, think about governance in such contexts as boards of directors, business change steering committees, and architecture review boards. At their best they help the organization maintain a fluid state, where everyone’s efforts pretty much line up with everyone else’s efforts, moving forward without a lot of high-impact collisions to disrupt the smooth flow of things.

Except that, for the most part, when the organization is already in a fluid state, traffic and culture make governance superfluous.

Part of effective governance is recognizing when not to say yes. Saying yes too much is like letting too many cars onto a road not designed to handle so much traffic. Effective governance tries to keep things in a fluid state so the organization doesn’t freeze up into solid-state immobility.

What counts as organizational gas? Consider so-called “shadow IT,” where business departments implement applications they need but that IT lacks the capacity to deliver (see “saying yes too much,” above).

Most of the German autobahn legendarily has no speed limits — it’s a gas.

But from Wikipedia: Any person driving a vehicle may only drive so fast that the car is under control. Speeds must be adapted to the road, traffic, visibility and weather conditions as well as the personal skills and characteristics of the vehicle and load.

When it comes to shadow IT, this isn’t bad guidance. We might imagine shadow IT governance following this sort of model, where driver’s education courses take the place of speed limits. You don’t want a shadow-IT free-for-all any more than Germany wants insane driver behavior on its roads.

On the other hand, forbidding business departments from using suitable information technology because IT lacks sufficient bandwidth amounts to … well, forget the metaphor. Refusing to allow business departments to operate at maximum effectiveness because that’s how your governance works changes risk management from one enterprise good among many to the only factor taken into consideration.

As for plasma: How about research and development? You want to encourage it, but in a safe environment … a metaphorical race track … where only trained drivers are allowed.

I’ve probably pushed this metaphor beyond its limits.

Still and all, I think it’s fair to say that too often, governance devolves into stifling, choking bureaucracy. With the right culture it’s needed far less often than it’s imposed, and when imposed it focuses on reducing costs and risks much more than on increasing revenue and opportunity. And often, traffic makes it unnecessary.

Comments