Enterprise Architecture + Continuity Planning = Enterprise Engineering

The previous post I mentioned Failure Mode Effect and Criticality Analysis (FMECA) in connection with Y2K.  I thought I’d expand on the method and how it helps move Enterprise Architecture closer to Enterprise Engineering.  The distinction between E.A. and E.E. in my mind is like the difference between art and science.  I know some of my E.A. colleagues will take offense but I’ve been in both Architecture and Engineering professions and engineering is more formulaic.   

FMECA is derived from Systems Engineering Discipline, not computer systems but systems in general.  The method looks at the components that make up a function be it hardware, software, peopleware, etc. as a system.  Within that system some components are critical to the successful operation of the function.  The simple example I used to my client was certain components of a plane must operate in order for it to keep flying.  If the oven on a 747 doesn’t work it’s not going to crash the plane.  However, if an engine or a few engines the plane will not stay in air too long.  Which components and how long before critical failure is what FMECA is about.

You can probably see where I’m heading with this.  During Y2K, I asked the I.T. department and various business functions to image the business as a plane in flight and then identify the critical systems that keep it going.  I suggested that the processes, not the I.T., would be where to start.  Once the process were identified, the next step was to determine time to crash (i.e., the company dying) that the process failure would result in.  Next they were asked which applications were used to support those processes.  For strategy and I.T. consultants, this created a more robust version of a value chain.  After that I asked the I.T. departments to quantify mean-time-to-be repaired (MTTBR) With time to crash and MTTBR this gave us a means to prioritize which systems and applications to focus upon.

While may would argue that Y2K was a big nothing or a hoax by vendors, I would propose it did two things: 1) efforts expended prevents serious outages 2) it gave a greater appreciation of the impact technology has on business.  Thirty years ago computers in business were a benefit but not critical to most businesses.  Today what business would not consider information systems critical to their business.  Yet the continuity of operation and the risks associated with these have not been considered sufficiently by line of business and sad to say architects.  I think this may be so due to the lack of conceptual tools to address such.  For that I suggest E.A.s take a look at the systems engineering profession and the methods employed.   

A great reference is Blanchard’s Systems Analysis and Engineering

Advertisements

About briankseitz
I live in PacNW in a small town and work for Microsoft as a Enterprise strategy and architecture SME. I enjoy solving big complex problems, cooking and eating, woodworking and reading. I typically read between 4-8 business and technology books a month.

6 Responses to Enterprise Architecture + Continuity Planning = Enterprise Engineering

  1. I think you are doing a good job keep it up and even better keep doing it after the competition,Good luck man. I hope both of you will win this competition,

    • briankseitz says:

      Webhost, I’m not writing a blog for contest, competition or money. This is an unsponsored site that I’m usng to collaborate with others that wish to comment or enter into discussions on technical content and collate my ideas for writing a book some day on Enterprise Engineering.

  2. Harry says:

    Harry
    I was wondering if you ever thought of changing the layout of your blog? Its very well written; I love what youve got to say. But maybe you could a little more in the way of content so people could connect with it better. Youve got an awful lot of text for only having 1 or 2 images. Maybe you could space it out better?

  3. Garmin 1490t says:

    Good day, Wonderful site, in which did you come up from the facts in this summation? Im glad I found it though, I am going to be checking back soon to determine what other posts you have.

  4. Pingback: Enterprise Architecture – a Laymans View | IntoInfrastructure

  5. Pingback: The Ingredients of a Successful ITO/EA Team | Into Infrastructure

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: