Structure in Threes: Organizational Design

Business Structure verses Organizational Structure

One of the interesting issues that came across my desk today as I was discussing a colleague’s new venture was the taxonomy and ontology of our conversation.  She wanted to cover multiple concepts in the same conversation which is a notable goal regarding economy of one’s time.  However, it became apparent that the terms being used were being overloaded during the conversation.  Example: Discussing the Business Structure and Organizational Structure both terms were used interchangeably.  However, when I hear the words Business Structure I think of the legal form in which the business is established (Corporation, LLC, Partnership, etc.).  When I hear the term Organizational Structure I consider whether it is centralized or distributed; a partitioning along functional, product, customer or geographic lines.  As I continue to develop the Business Design Tool (see below) the question becomes how-to ensure that the dimensions are orthogonal to each other while retaining the interconnectedness of these dimensions.

Organizational Development Tools

Many of the recent texts define various dimensions such as complexity, market, size, etc.  However, the interconnection is only a Infographic.  Perhaps these interconnections are only a probabilistic connection leading one to only heuristics.  I will make a interesting systems dynamic study at the Center for Understanding Change when I have some spare time.  In the meantime I continue to develop the Org Design and Modern IT Portfolio Management tools which are looking more and more like an enhancement to the Business Analysis System and Environment (B.A.S.E.) application built in 1994 on MS Access V1.

B.A.S.E. at that time performed a variety of management consulting analysis:

• Porter Competitive Analysis which has been advanced by Slywotzky’s Value Nets and then further by Osterwalder’s Business Model Canvas which the Org Design tool is working to further advance into a Computer Aided Design (CAD) tool for Organizational Development and Management Consultants
• BEAM which was created by Parker and Benson is being advanced through the R&D to a Modern IT Portfolio Management methodology
• MBA Product Planning which has been superseded by Design Insight’s (Peter Marks) Customer $APPEALS

This application will eventually become the basis for the semi-automated workflow for several of Intellectual Arbitrage Group’s practices and services

 

NextGen IT is on the horizon

The discussions the last few years with various domain thought leaders, analysts and industry executives lead me to the conclusion that not only the technology of IT will change but the model of how the IT Function operates will change from product: application/hardware standup & maintenance through pseudo-service (SOA, Cloud 1^st Gen) to a total service concept that integrates technology, people and process.

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