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.

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: One Enterprise’s Capability is another’s Function

Spent a portion of yesterday going through my project archive (two four drawer lateral file cabinets).  Mostly to clear out duplicated or outdated materials, but some was information mining for the book.  Typically on engagements I spend a fair amount of time to understand clients mental models, language and corporate culture with the objective to operate and communicate in the organizational structure with as little disruption as possible.  While this assists my clients, as I go to the effort of translating concepts into their language so they don’t have to spend the cycles.  This allows them to focus on exploiting the solutions, recommendations I propose and get value from these faster.  Which gets to the point of this post.

The mysterious language of strategy-speak.  Pick up any book on strategy the past decade or two and you’ll see a discussion on the importance of Corporate Capabilities.  The problem being though is the definitions are rather fuzzy.  Is CRM a function or a Capability or both or Software Product or now a Service?  Clearly if we are discussing the “ability” for an organization to manage customer relationships effectively we’re talking capability.  If we discuss the organizational unit tasked with preforming tasks associated with managing customer relationships it would be labeled a business function; which become even more confusing when we add the software products meant to enable performance of those tasks which could be either a product or a service.  And you thought your teenager’s language was confusing.  Those that enter the discussion without context need to spend extra effort to decipher if they can from the dialog.

Why I bring up this semantic problem?  This becomes a critical matter when designing an optimum organizational design.  I stress designing the “optimum” design; like product engineering there are many possible configurations possible.  However, there are a fewer configurations that fit the specific enterprise’s working environment, corporate culture and resources.  These are the high level design inputs parameters which affect the design decisions.  Unfortunately, there hasn’t been a metrics driven approach toward organizational design –something I’m in the process of remedying now through this book– that would include usage of concepts such as Taguchi’s Design of Experiments for design optimization.  However, to use such an approach one needs to standardize on terms such as these, the attributes and metrics associated with these.  Which again brings me back to my achieve and the broad spectrum of models and definitions I’m wading through to create a consistent ontology for Enterprise Design.

I had hoped to avoid the Yet Another Framework (YAF) trap, but I’m still seeing wide variance between associations and societies languages, as broad as what I experienced working on the ISO 103030 (STEP) standard.  My goal is not to create still one more framework, but rather the transformations similar to those John Zachman mentions as key with he discusses his framework. These would not be between cells but between other framework constructs.  The point behind such activity is to make the specific representation system any enterprise uses transparent to the design effort.

 

These materials though will likely be in the appendix or associated supporting website for the book, as it will likely be a long term effort and would delay development of the core design methodology.

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.

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.

Enterprise Architecture: The more we change, the more we stay the same

Last evening I started reading Business Architecture, Ulrich & McWhorter.  I was amazed at seeing the concepts I once extolled over a decade ago in my ZIFA presentation in print.   My mentor John Zachman back then had asked several provoking questions prior to then.  One was just confirming completeness his model of IT Architecture.  This was when time and motivation columns where not part of the framework.  We had several days’ discussion about what do time and motivation artifacts look like.

I would fall back to my dwelling architecture career of the past to answer; building schedules to name one, project plans to name another; both are concern with time or precedence of activity.  But is it important enough to be a dimension John asked.  It fits the reporter’s interrogatives: Who, What, Where, When, Why and How that I believe should be the columns.  “Did you ever think how hard and expensive it is to put a roof on a building without walls or a foundation.  It can be done, but it’s costly.”

The next one had to do with span and depth of Architects.  This was one of the most enjoyable discussions I had with John.  I had brought an old Architecture text book, creating architectural theory, Jon Lang.  In it Lang had described different levels of design, the span and granularity that architects of various types dealt with.  An Urban Planner is not about to design your house and his work products are likely to affect people for generations, look at how various city growth patterns.  These were established decades ago.  

Enterprise Architecture is much the same way.  Many corporations’ architectures are still the same, despite the addition of information technology.  These companies may or may not need to change depending upon the ecosystem they reside in.   However, as ecosystems start to interact with other ecosystems –think globalization—business models and architectures are exposed to others which may be more competitive.  Consider the “Japanese Auto Invasion of the 70s”, was it cheaper cars though cheaper labor as the Detroit elite suggested or was the old mass production model breaking down in the like of a different business model.  History now confirms the later.                  

When I present on Enterprise Architecture around the global, I still use the analogy of dwelling architecture.  The example I typically use to differentiate architecture from design and there is a difference is the various Gothic Cathedrals.  If you overlay them on top of each other each is different.  So it’s not the stone, glass and wood, but how you use these that determines an architecture.  These rules (Design Strategy aka Architecture) determine how the components relate to each other as well as usage of these as a system.

Going back to my technology example, consider the telegraph.  During its introduction it changed how business work around the nation and eventually the globe.  Now consider the next advance in communications technology, the telephone.  Initially productivity didn’t increase with its introduction.  Why?  Consider the old –in the relative sense—paradigm of the telegraph in business usage.  A business owner or manager would dictate a memo to secretary; she would courier it over to the telegraph office where it would be translated into dots and dashes; at the other end the dots and dashes would be translated back to text; couriered to the recipient business’s secretary who would read it to the business person.   Enter the phone; a secretary would take dictation then call the business at the other end, the two secretaries would exchange pleasantries and then dictate the information; which was then either handed to the other business owner or read to him.  During each of this information exchanges misunderstanding and transcription errors could occur.  A simple business transaction could take several days of back and forth.

It wasn’t until two business people broke the model and spoke directly to each other that a competitive advantage ensured.  Those business people that used the technology in a different way become more competitive.

Back to Ulrich & Whorter, they rightfully point out that SOA and Cloud are hyped as the next Holy Grail.  I believe they miss the mark though by tagging vendors and IT groups as the black hats in this story.  These stakeholders are both part of the problem and the solution.  However, business people share a lot of the blame as they continue to look for the silver bullet so they don’t have to think about managing their information or constantly reviewing and revising their business models.  Vendors and IT groups deal with information technology, not information management.  If you substitute drill presses, stamping machines, and an assembly line for servers, networks, databases and browsers we’re back to its not the stone, glass and wood but how you use them.  Vendors and IT shops are good to great at dealing with the mechanics, not so good on defining business models.   This is where Enterprise Architects come into play.  Unfortunately too many EAs are not EAs; they have the title but not the orientation.  They’re just technology or infrastructure architects with an inflated title. 

Failure to understand how to use the new technology in a new way will result in the creation of what my friend John Mancini of AIIM has labeled the Digital Landfill and create more of an Information Glut (think of hardening of a corporation’s knowledge arteries).         

You know you have an EA on your hands when s/he looks at business models & goals, economics, technology paths, organizational capabilities and how to translate these into a series of state changes for the company.     

What I still see on the horizon is Information Management Maturity.  Today I see signs that some organizations are seeing that need.  2020 Roadmaps talk to managing information more like assets.  Disciplines like Information Architecture while popular are still in its infancy, you’ll hear terms like taxonomy and ontology however, these are just exploratory projects in many corporations.  Technologies like SharePoint that could exploit the design intent that these terms represent are left waiting for the discipline to mature as well as a strategic execution system to deploy. 

    

For those of you wondering, these slides were presented in 1996 at the ZIFA conference

Ontology vs. Taxonomy

Yesterday I started preparing to archive materials, as I’m coming close to the end of another series of projects. Two years of work has yielded 1gig of data. Granted, there is going to be a lot of redundancy as I typically save major versions of work.  If I reduce that down, to a quarter, that is still a significant about a data to sift through and categorize.

During the past two decades I’ve become an ontologist  / taxonomist  by default.  Through the natural course of preforming enterprise architecture for my various employers and clients, I had been guided by necessity into learning various aspects of Ontology and Taxonomy.   While my employers and clients don’t pay me to be such, it became apparent I needed to develop those skills to accomplish the goals we agreed to during the start of the projects I’ve worked; more effective usage of information and the creation of knowledge.

It sounds like a simple charter, and many would start with implementing technology solutions such as SharePoint.  However, the problem with that approach is often that is where the initiative ends, with yet another technology platform change; resulting in the more tools & data, less information syndrome.  This is not to say SharePoint is bad, rather it’s a callout to both business leaders and technologist that SharePoint in isolation is not enough.  Consider a previous post of mine and ask yourself; has your SharePoint implementation become nothing more than a Web Frontend to a shared drive or possibly just an electronic routing slip for administrate forms?

The next question is to ask yourself is why?  The company either had great ideas to use SharePoint to solve some key information management problems or was piloting to see what it could do.  Where in the project plans was the plan on how to manage the information?  Did this item get lost in the shuffle of implementing the technology?  Had it even been considered?

Often as an Architect the deliverables I create are given a condescending smile by development and business alike.  Some of the unkind things I’ve heard are: pretty pictures but…we have real stuff to do.  Having grown up in the Architecture (houses) and Engineering (Aerospace) industries I find it interesting that still today while many I.T. organizations use the Architecture metaphor my mentor John Zachman defined decades ago in “Enterprise Architecture” , few still understand the role of engineering and design (those pretty pictures).

Those nice pictures (aka Systems Engineering Diagrams) keep you in line with the bigger picture when you’re in the weeds.  Also those diagrams help you isolate and diagnose where issues are instead of poking around with a sharp stick.  So too, Ontology and Taxonomy assists businesses in understanding the bigger picture of where information is or has been created from and what it is and means.

A simple example I often use harkens back to my days working on an ISO standard.  I will not bore people hear, retelling the story.  I save that for torturing those who attend one of my presentations.  The net of the story is that terms in taxonomy are important; however, equally important is the understanding of what those terms mean.  However, a term’s meaning is contextual though not always represented in taxonomy, thus the need to create ontologies also.   This is not a role for an I.T. person (system administrator or programmer) it’s a role that only business owners and leaders can perform with I.T. staff supporting the storage and display of such information.

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