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

 

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).                  

Discipline Maturity Lifecycle: Enterprise Architecture example

Spent this morning thinking about operating models in IT organizations and ITIL initiatives.   After a few minutes of pondering , hearing a group next to me at a conference extol the virtues of the 4hr days a few thoughts came back to me; the IT discipline is still in a low state of maturity.  If I was to use a human scale, the IT discipline is like a 5 year old copying its older brothers thinking it is all grown up.  Sure the IT Discipline has many elements that other more mature design and development disciplines have, however, the behavior, standards, ethics and other aspects around the profession have yet to develop.

This revelation is not new to me, years ago I had started quantifying how other design disciplines evolved and matured.  I had presented a corkscrew diagram at some conference back then and left it as an interesting phenomena.  As I was in a keynote session the image popped back in my mind and the book I had started but never finished.

What triggered that thought process was a discussion of the Enterprise Architecture discipline/practice.  This had triggered another memory of drafting a paper and proposal to create “The Architect’s Office” within an IT Organization I was working in.  Some of the issues are still the same which were taken from my studies in residential architecture and later field experience:  Architectural Practice is not like Howard Roark in Anne Rand’s The Fountainhead the majority of the time.  It is a social and community effort.

There are two aspects to successful architectural firms:

  • The Practice BOK –the body of knowledge and activities used to perform and deliver value to the client.  This is where most practitioners focus when discussing the discipline.  The mechanics of deliverable creation.   While this is the      foundation of any discipline and it grows as it matures, it is only part of the practice.  Many EA firms have yet to take that jump into operating the discipline as a business as opposed to only a methodology of delivery.
  • The Business –the selection of market, the value defined to be delivered, and the means on how value controlled and delivered (aka the Business Model).   Without knowing your business model Enterprise Architectures are prone to produce limited value to customers though providing what was requested.       Eventually, the practice could end up in a different business or on the corner with a sign “will architect for food” as the activities performed do not deliver an acceptable cost benefit ratio to  clients. This suggests that architects need to understand their market and alternatives to their delivery of value.       Many residential architects left the calling in the 70s & 80s as customers failed to see the value they provided over general contractors that had draftsman on staff.

Governance Visualization

Reading Enterprise Architecture -creating value by informed governance.   The one take-away I’ve gotten so far from the book has been confirmation of Stafford Beer VSM’s concepts: the recognition that management and control within an enterprise need to be designed with the same discipline and rigor or more that are used for products and services.

Designing effective governance directly effects an enterprise’s ability.  In an environment and economy that demands that enterprises be flexible, adaptive, efficient and effective, having the appropriate governance system is a critical enabling factor.  Some of the spectacular business failures of the past decades have not been failures of product, production process or services.  These failures have been lapses of effective governance.  This goes beyond the financial and ethical scandals that have brought about SOX legislation.   One only needs to look at the issues that the US Government is going through.  Almost everyone is looking towards the government with frustration and wondering why it does not appear to be working or unable to get things done.  A simple look indicates a failure of governance by the very body that has been delegated that responsibility.   I bring these circumstances and events up as proof-points to my original premise; management and control have gotten complex enough in today’s environment that governance needs to be designed and built.

If I haven’t lost you reading this you’re asking now what?  What do I do if I buy your premise?  As an Enterprise Architect, the next step appears simple but is quiet hard: recognize that governance is a subsystem in the enterprise which is a system in the environment.  Usually Enterprise Architects spend significant time articulating how the value creation process is exposed by a product or service system.   Or Infrastructure Architects focus on creating the information system that enables or embodies this creation process.   However, the sub-discipline and practice of governance creation is still emerging as a practice within Enterprise Architecture.

The diagrams below are but one visualization method on how governance can be displayed.  While overly simplified, I find this method clear and concise to communicate in a less jargon filled discussion.  The first diagram illustrates how the management system aka governance reacts with both the environment and operations.  The management senses the environment and operations and sends control instructions to operations to adjust to environmental needs.  In this context environment is the ecosystem that the business operates within.

In this second illustration the system is diagramed in more detail showing how the management system is partitioned is to sub-control activities and the mechanisms (triangles) used to coordinate activities.   This does not take the place of business rules, charters, and other textual representations of governance, however, it does enable visualization on how the components interact as well as help identify gaps in governance.

 

Enterprise I.T. Strategy and Governance Vacuum

Over the past two years I’ve been observing the dialog within the SharePoint community around governance.   There are hints that the community is evolving as several people are now discussing the role of business in governance.   This discussion was missing during initial treatments of the topic at conferences I attended.  It was emblematic of the IT community as a whole during the past decade.

Much of the focus of IT governance has been on execution of permissions for access to information or applications.  While this is important and the end goal of governance, this is the equivalent of law enforcement more so than actual governance which is the process by which decisions on access is made.  IT organizations have become surrogate business asset management boards and in some cases the role has been pushed down to the lowest levels of IT.  A natural result of such unrestrained delegation has been this focus on execution with the decisions on who and how information assess becomes an ad hoc process or left to those that build but do not use the systems.

IT Catch-22

These factors have left IT organizations frustrated as the businesses as they serve.  IT organizations are either blamed for not “just taking care of it” or being “too arrogant, bureaucratic, unresponsive and out of touch with business needs”.  IT Leaders are not complacent about this situation, but confused as to how to address it.  Candid discussions the past two weeks with several organizations facing these challenges confirm this.

 

If an IT organization attempts to just take care of managing an enterprise’s information it faces the challenge of understanding what information is needed, who needs access, how it is to be used, and a variety of other attributes for this information.  All this and then attaining agreement and adoption from the business community.  This is a tall order for a organization that has spent the majority of its efforts on deploying and maintaining technology.  One only need look at IT group budgets over the years to understand where its capabilities and competencies lay.  One could blame MIS directors and CIOs for this however, this is what they were missioned and incented to achieve throughout the past decades.  The typical IT Executives had been constantly receiving directions to lower costs of the infrastructure, increase capacity, and maintain the current technology.  If one looks at IT Industry focus over the past several decades aside from the technology generations the one initiative that stands out is TCO, Total Cost of Ownership.

Doing the same thing and expecting a different result…

When management consulting started to address Information Technology management it has continually put its efforts into optimization of existing resources.  This is equivalent to efforts that these firms put toward manufacturing hard goods products.  The thoughts behind doing so was that human labor was cheap but equipment was expensive.  So methods such as operations research to cut idle time through scheduling and a limited version of portfolio management meant to reduce capital holdings became the prevailing wisdom of the day.  Most enterprises unaware that the paradigm of work was changing from expensive equipment to expensive labor accepted this IT strategy.  During the 80s human resources became more expensive than physical resources, however, the management strategies and techniques have not kept pace with this reality in most enterprises.

Acceptance of this old strategy has meant that over time enterprises and IT organizations as a result, spent what resources not devoted to technology deployment and maintenance to developing competence on cost management or cutting.  The areas of information strategy and architecture that had started in parallel were gradually thinned out, demoted and discounted as the orders of the day was cost management.  Enterprises had by default outsourced their information management strategy to vendors.  Those that disagree with this assessment can look no further than the details of most technology strategy groups within IT functions and see the primary activity is around technology purchase, deployment, maintenance optimization.   Very little investment has been put forth on developing information management verses information technology capabilities.  Of the fifteen organizations I’ve surveyed the past two months, all had Portfolio Management initiatives with a mission on reduction of application and hardware investments, only two had just the start a practice for the management of information as an asset and both are struggling with understanding how to ensure alignment with business.

This is not a condemnation of enterprise management, management consulting or the IT organizations.  This is just a reporting of what I’ve seen over the decades as someone who has cycle through multiple  functions within the business and multiple organizations.  The circumstances, the decisions and actions made have resulted into the situation enterprises are in today.  Like issues with the US Economy or the Environment these are results from the build up of small effects over a long period of time.  Long horizon effects is something that most people and therefore organizations are not well suited to address, especially with the instant gratification culture we’ve developed into today.    So it should not be unexpected that managing information –a new discipline — has not developed as a competency in the business side or IT.

 I’m going to show them … a world without rules or controls, borders or boundaries. A world where anything is possible. Where we go from there is a choice I leave to you

Where does that leave business and IT?  Businesses need to reexamine their role in managing information.  I say information specifically not information technology.  Business members cannot delegate the responsibility to manage their information.  Abdicating control over this critical component results in losing control of the business itself.  For IT figuring out how to partner with the business to address complex issues is key.  Discussing EA with my fifteen IT organizations and on LinkedIn CIO Network forum the questions I’m repeatedly asked is “how?”.  How do we partner with business?  How do we get business engaged with information/technology decision issues?  Senior and technical leadership within IT organizations asking these questions does not suggest arrogance to me.  IT’s focus on IT specific issues without linkage to the  business paradigm and goals suggests a blindness or one dimensional quality which can be seen as arrogance by other disciplines in the enterprise.

I don’t have a magic formula for Business-IT engagement other than to open a dialog.  However, for dialog to occur a common language or effective translation needs to occur.  IT organizations need to develop an understanding of business and the means to translate business concepts into IT execution.  This is more than just a word for word translation but an active exchange where concepts such as business models are investigated for IT enablement options, the alternatives are relayed back to enterprise executives and line of business management as well as the consequences of choosing an alternative from a business perspective so joint decisions can be made.  This model of engagement is not new to industrial enterprises.  Marketing, Engineering, and Manufacturing now team on making decisions in most leading corporations since the 80s under the banner of concurrent engineering.   This is focused upon decisions about products and goods sold.  Today as products and services include IT components, IT organizations should be prepared to “participate” not direct in these teams.  Likewise IT needs to prepare itself to discuss business strategy, organization and operations on more than just a technology thread.  Failure to be able to converse on content beyond IT will continue to relegate the IT organization as a suspected subordinate function.

How this effects Enterprise Strategy and IT Governance?  Without the executive and line of business management participating in governance as full members the IT organizations will always be viewed as autocratic and detached from the business.  IT organizations need to prepare, educate, and reach out to other’s as a colleagues.