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
Leave a Reply
You must be logged in to post a comment.