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.

6 thoughts on “Four Pillars: Thinking about enterprise architecture”

  1. Very interesting thoughts on the organization ecosystem and the IT systems. It would be interesting to see your thoughts on IT’s strategic value.

  2. Paul Strassmann and Nicholas Carr seem a very hazy long time ago now, so I guess your comment will catalyse me into another pro-strategic-value post. Thanks for the stimulus. Watch this space.

  3. Saw this. Said – thats Conways law restated (and restated well)

    So posted the following to my blog – naccent and rebuilding

    “CONWAYS LAW [1968] “organizations which [sic] design systems…are constrained to produce designs which are copies of the communication structures of these organizations.”

    THis requires a longer and more detailed post but I’d suggest two links

    *The original statement of Conway’s Law
    How Do Committees Invent?
    by Melvin E. Conway

    * And the very explicit drawing of the implications for enterprise architecture in
    Conway’s Law Revisited: Successfully Aligning Enterprise Architecture
    Date: May 1, 2002 By David Dikel, David Kane. Article is provided courtesy of Prentice Hall PTR.

    Be interested in your opinions

    Regards

    Dermot

  4. Dermot, thanks for your comments and links. I had posted earlier about Conway’s Law in the context of social software, you can see the post here:

    http://confusedofcalcutta.com/2006/03/13/blogs-and-organisational-structures-and-conways-law/

    I had seen the original paper and for sure it is likely to have influenced my thinking. I was trying to extend the point I guess, to cover far more than communications, and to bring it into amanagement theory context.

    I will read your post and follow the link to the Dikel and Kane paper, and will revert with opinions. Thanks.

  5. JP

    that would a case of great minds thinking alike :-)

    I been trying to use it with some MBA students on an MIS module. Some of them loved it and I think some of them haven’t got their head around it.

    Be very interested in any though

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.