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:

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

 

Advertisements

Modern IT Portfolio Management: Investment Profiles

Last night I reviewed of my notes interviewing investment brokers, portfolio managers the past few months and delved deeper into my growing collection of Wiley Finance Series of books.  This morning I scanned through “The Art of Asset Allocation” by David M. Darst searching for the next analogs in financial portfolio management to pair up with IT Portfolio Management.  It occurred to me the metaphors currently in usage in wall street: Bulls, Bears and other animals used to characterize investment behavior is close to but not exactly a match for IT Investment.  In a previous White paper I had researched and written for Microsoft’s Services division on Business Continuity and Disaster Recovery I had started to layout a third dimensional grid-work on the organizational decision behavior and environment.   As I re-read the insight I had working on various aspects of decision science I can see how to apply these learnings plus several other insights to IT Portfolio Investments.

Investor Profiles

The only downside to this approach is that most consulting firms prefer to adhere to the 2×2 matrix.  The logic behind such is they feel more than 2×2 or binary decision values confuses management and executives.  A little insulting to their clients if you think about it.  However, the objective is to communicate quickly to the client not show the complexity and nuance behind the analysis.  As such when I develop a more comprehensive tool, I’ll have to have it yield several simple 2×2 views of the decision for ease of understanding.  I did this with the design of the Cloud and APM Portfolio Tool for Microsoft IT Strategy and Enterprise Architecture services division a few months ago.  The feedback I got from my personal CxO advisory panel were very positive.   Expect to have a wireframe of the tool’s output to match the personas I’ve developed ready by end of next month**.  The it becomes a decision on what technology to build.

**I like the advice I got from Alan Cooper a few years back; “Design from the outside in”.  The common sense of it seems apparent, however, so few companies and developers do such.  Today all the rage is teaching developers and consultants to use personas.  Unfortunately, the lessons typically stop at using them as sales tools to justify what has already been built rather than design tools to ensure operation and aesthetics match with the enduser’s needs and desires.

Structure in Threes: Capabilitiy Models

Most of yesterday was dedicated to continuing to fix my wife’s IPhone contacts and syncing with desktop.  By 10pm I had finally reloaded a restored copy of her contacts to both laptop and phone.  Later today its back to AppleCare to restore her apps.  Apple is still suggesting using ICloud to sync multiple devices, but at this juncture its unlikely she will trust any cloud provider.  This has taught her a lesson businesses are either about to learn the hard way or have Enterprise Architects, like myself, developing disaster contingency and continuity plans prior to jumping to the cloud:  Technology changes that you run your business on require serious change management.  And even then the a poor implementation can require many hours to recover.  Another lesson or side benefit, she’s starting to see what my career really is about: enabling others,  preventing crises, and recovering from crises.  The unfortunate thing about the Enterprise Architecture profession is that goals one and two are what enables goal three, but goal three is the only one that gets other’s attention.

This morning before jumping back on IPhone recovery, I’m reading through the COBIT 5 management guide.  It’s rather odd how most standards, processes and models now take the form of the CMMI maturity model.  While I’m a supporter of the maturity model construct it has it’s deficiencies or rather I should say poor adaptation of the concept leaves deficiencies in the applied domain.  Often I’ve seen various organizations adapt the maturity model construct for their domain of expertise but as a marketing tool to infer gaps which their product or service naturally fulfills.  However, these capabilities are often not completely filled by the product or service as the capabilities have to be built with these tools, knowledge, processes and behaviors.

The COBIT 5 generic capabilities model points to level characteristics, level generic enablers, and generic level enabler capabilities.  However, it appears the rating of conformance is a subjective exercise.  May be that is acceptable at present as this field become more defined.  However, linking performance to organizational design then become more subjective also.  It may be the design methodology I’m working on will have to include the concept of tolerance and performance ranges (similar to physical product engineering) for the results of selecting the various design attributes.  I’ll have a better handle on that when I encode the governance model into a spreadsheet and link it to the organizational design spreadsheet.  The results should give me a more robust assessment criteria as well as a diagnostic tool for clients that will guide them to a more specific areas to address rather than a shotgun approach.

 

Structure in Threes: Chapter 1: An Architect’s View of Organizations – creating a coordinate system for an abstract space

Laying out the problem for a enterprise architecture coordinate system

As I start laying out the intellectual underpinning of the book I go back to discussions I had with my friend and mentor John Zachman who arguably coined the term and discipline Enterprise Architecture with his framework paper.  During those discussions I was keen to ask if he had identified the coordinate system (dimensions) that the framework displays as views or calls out the necessity to have plans for?  The answer was no with a challenge back to me to do the investigation for such.

Having been a student of residential architecture prior to my migration into the business and information technology fields I was well versed in the paradigm of physical space; 3D.  When specifying the physical design of a dwelling –prior to CAD/CAM systems– one would make drawing that collapsed the three dimensional world onto a two dimensional plane; a drawing.  With two drawings –that is each had one common dimension and one dimension that was orthogonal to the others– one could create another view that displayed the relationship between the orthogonal two dimensions through projection, thus giving the viewer a perspective that was hidden from sight.  Additionally, one could also create auxiliary views that were not perfectly orthogonal, giving more insight to areas of concern.

The problem with applying this physical space analogy in the business and information technology problem space was that the dimensions did not use the same metric space.   That is length, width, and depth all use the measurement units be they inches, centimeters, or whatever.  In the business and information technology problem space there is no common unit of measure.  At this point some of my CFO friends point out that finance is the common unit.  However, as I point out to them, its not common if its not common to all the views.  Data or Process structure does is not measured in financial units.  This was a vexing issues to me for a number of years until I started researching physics and came to the interesting conclusion that the dimensions need not be measured in the same unit but that the metrics only need to be related in some deterministic manner.

While I have not completed my research on the actual measurement system, I have managed to come to grips with a conceptual model that has these dimensions at least connected in a probabilistic manner which is how I got into predictive analytics as a topic to include in the book.  This was further validated when I went back to basic engineering concepts where solution space was examined using statistics.  I refer to Taguchi’s Design of Experiments .

If I continue with my thought experiments applying physics concepts to business and information architecture I get to primitives like Space, Time, and Mass.  However, these dimensions are hard to relate directly to business and information technology as well as lack coverage for abstracts such as finance and information.  Does information have mass?  Can one measure the space finance occupies?  To quote a line from the movie I like, IQ, “Interesting concept”.  But I don’t smoke.   This has led me to another side project of build a information model of these dimensions which will be included in the appendix and discussed in the academic part  of the book.

Projects Past

As part of my office relocation project this month I’m reviewing, purging and scanning materials from my project archive.  Today I scanned a few of my 1980s projects at Rockwell International and Lockheed.  It’s amazing all the advanced R&D these companies gave me to do:  Building a PDM for the B1-B program, Developing and implementing Product Lifecycle Management, Group Technology Based Shop Floor Scheduling, Automated Archive and Retrieval of CAD drawings, Predictive Analytics of Aircraft Systems and Engines.  I wonder if current executive management will understand the lessons from this era; real mentorship, the discovery projects (e.g., IR&D), and the value of think time.

Rockwell 1983 PLM System Rockwell 1982 PDM Concept ETRAP 1982 Rockwell PDM Rockwell PDM - PLM 1983

Its also amazing how we managed to design and build these system with little automation and tools:  Modeling and Drawing tools such as Visio and ITHINK were not available. I started using a CAD/CAM system –Computervision CADDS III & IV– to diagram and flow chart as personal computers (no IBM PCs on market yet) were just starting to become available which resulted in senior executives asking me to build diagrams fro their projects also rather than using the graphics department.   I started studying some of the works of IBM guru’s then to add to my intellectual toolkit; Ed Yourdon, Gerald Weinberg, Tom Demarco. Robert Benson, and later John Zachman etc.   Never did I think I was going to continue in the IT field, join not one but two of the greatest IT companies (IBM and Microsoft), and have as mentors these greats in industry.  Today I’m still privileged to not only still maintain associations with such people but asked to collaborate together at times.

Structure in Threes: Design Strategy

Spent last night using the methodology I’m developing for the book to analyze the Data Insights and Business Intelligence line of business.  While I like Business Model Canvas  (Osterwalder, et al) for its visualization I find it lacking on the analytic side.  There are no metrics in the approach so the business model analysis subjective.  As such I’ve started to integrate Miles and Snow’s work and Peter Marks (Design Insight) -who’s methods I’ve used before for my major reengineering projects- and adapted these to provide a more metrics based approach.  Peter’s work was originally based on Product Design strategy which from my perspective from years ago and the basis of my R&D over the years is that an Enterprise is a product.  It happens to be a product with emergent behaviors; so the General Systems Theory and Industrial Dynamics research I did before and during my career at IBM has led me towards pushing the envelop in looking at Enterprise as a multidimensional exercise. Which became the topic of hours of discussion with my mentor John Zachman when we discussed expanding the framework.  We were looking for exemplars for Time and Motivation to ensure these were valid for inclusion.  The problem arose regarding behaviors which are motivation/intension but not.

I immediately though of my old drafting days and considered those perspectives auxiliary views. [For those who are not design engineering or architecturally knowledgeable, an auxiliary view is where to combine dimensions from two other views to create as third view that gives you another perspective]  Unfortunately, in the Enterprise Architecture space, we’ve not been keen on creating a dimensional coordinate system which is where my research activities have been leading.  While the metrics I’m proposing in my book are not as robust as those in the physical world (length, width, depth, and time) I think they’ll be consistent enough to be useful in analyzing an enterprise.

Business-Model-Canvas-PPT

The one easy dimension which seems to always get placed in the corner is resource, specifically finance.  I think this is because its both resource and measurement system which is confusing without context.  However, I’ve taken a page from Markowitz on Portfolio Management and think I’ve got a holistic approach that integrates with the rest of the methodology well.  Well back to office remodeling this morning.

Discipline Maturity Lifecycle: History Data-Point

Yesterday during my drive home, after listening to an interesting Enterprise Architecture and Strategy presentation, another data-point that all the design disciplines mature in similar manner came to mind.  One of the current enterprise architecture trends beyond the usual economic pressures and cloud is enabling enterprise agility.

Enterprise Agility is having the flexibility to change how the organization operates, the services it provides or uses quickly.  This comes at a price.  However, as the product industries as automotive discovered, this cost was minimal compared to the competitive advantage flexibility created.  

One only has to look at the history of competition between Toyota and GM during the seventies.  Doctors Ohno and Shigeo, developed the Toyota production system which was exactly counter to the prevailing wisdom of the day to use economic order quantity / economic production runs (aka Traditional Mass Production).  Dr. Shingeo’s creation of flexible machining concepts –Single Minute Die Exchange- and Ohno’s JIT concepts enabled Toyota to reduce time to create and field new models.  This change from industry standard seven years to five years made Toyota more responsive to the market (read that ability to adjust to the gas crisis).  Suddenly American Automotive Manufacturers market share dropped and never regained its former glory.

The value of this flexibility was not lost on executives from other industries.  Today, IT is now running to catch up to the other engineering disciplines on designing for flexibility, and with that the argument as to the value of such.  As the IT community matures, it will come to the same conclusion as Systems Engineers, to develop the practices around supporting the –ilities and the competence to balance between these –ilities (i.e., Design of the Total Offering).