Day: 19 June 2006

Four Pillars: Thinking about standards in an enterprise architecture context

In late 2004, we had quite a kerfuffle where I work, trying to decide what to do about Firefox. For sure it wasn’t the standard browser. For sure, if we blocked its use, it would not become the standard browser. So like everyone else we ummed and aahed, I spoke to my boss, and we agreed the following:

We would not support Firefox. What this meant was that no application would need to change as a result of Firefox being introduced. What this meant was that if anything went wrong, the “user” could not call up the support department and get it fixed. Firefox was unsupported.

We would not ban Firefox. People would be allowed to download Firefox, but, as per the no-support statement, they could not divert any resources towards making applications work in Firefox.

We would keep a careful eye on Firefox, reviewing matters and concerns over time. And with learning.

That’s what we decided.

Over time, as Firefox grew in popularity, it got better. The market made it better. The community made it better. Soon, I guess, it will become a standard. [And in the meantime, I will continue to play with Flock :-) ]

I’ve been thinking about this ever since that day in October 2004. And I wondered.

I wondered about standards-agnosticism. Could we start building systems that will work regardless of the “standards” in place, that are “unsupported”, that need minimal tweaking of the existing systems base, that are selected by the consumer, that are improved upon by the community, that stabilise through usage?

When Open Source meets the Beta mindset, maybe that’s what will happen. We will have more and more unsupported apps, because they work. And they improve. And they stabilise. And they don’t need supporting.

I wonder. There’s something peculiarly dissatisfying about having to change everything just in order to make one thing work. And knowing it won’t work anyway, that all we are doing is pandering to higher support costs, more lock-in points, more expensive ways of freeing up our own data.

Are standards just a euphemism for Officially Sanctioned Lock-ins?

I wonder.

Four Pillars: Thinking about enterprise architecture

This morning’s Wall Street Journal had an article headlined “It’s Not Easy Being Lean”, and reading it, I formed the kernel of this particular snowball.

In the article, a steel company called Nucor is characterised as having just three layers of management between the CEO and the hourly workers on the factory floor. And Toyota, one of the poster children for Lean, is mentioned as having at least ten layers. Separately, at least anecdotally, Google is rumoured to have a relatively flat management structure, with executives sometimes having forty or fifty direct reports. Why is this? Why does this work in some organisations and not in others?

Because layers by themselves are meaningless, it’s the level of empowerment and cohesion that matters.

What’s all this got to do with enterprise architecture? Let me posit a few “laws”:

  • 1. An enterprise IT department is a window into the soul of the enterprise itself.
  • 2. An enterprise’s IT strategy is a reflection of its business strategy.
  • 3. An enterprise’s IT architecture is a reflection of its organisation structure.
  • 4. Centralisation versus decentralisation, global versus regional, many-layered versus not-many-layered, these are all red herrings. What matters is High Cohesion and Loose Coupling, with its consequent empowerment, lack of duplication and consistency.
  • 5. These statements hold true regardless of the perceived quality of the organisation or of its IT department, in-house or outsourced. You cannot game the system.

Leadership, as per Max Depree, one of my favourite authors, is about three things:

  • Providing strategy and vision.
  • Saying Thank You.
  • And in between, being a servant and a debtor to your people. 

A firm “organises” to achieve a finite number of things:

  • Aligning execution to the objectives and strategy
  • Allocating resources accordingly
  • Using active feedback and feedforward loops to refine the allocation process in response to market stimuli
  • Having a sensible mechanism for escalation and conflict resolution

Enterprise systems and applications architectures enshrine what happens in the organisation. If there are independent fiefdoms then there will be duplicated systems. If there are meaningless control processes then there will be meaningless feedback loops. If decisions are pushed from pillar to post then the information related to those decisions will do the same. If there is no perceptible organisational strategy then you won’t find an IT strategy either. If rules are regularly broken then standards will not be adhered to either. If departments don’t collaborate then silo-ed systems are guaranteed. And so on and so forth.

If the enterprise needs investment, so will its infrastructure. If the enterprise is resilient and adaptable then this will show in its systems and application architecture. It is what it is.

So my advice is, leave other people’s best practices where they work best. In other people’s companies. Do the right thing. Do it the right way. Your systems will reflect your values whether you like it or not.