Zachman Ontology (Framework) and other Ontological Models

This past Friday a had a short but insightful email thread with a new colleague, Karen Morphy. I’ve been busily working on my –to quote a joke from my PDES Inc. / ISO10303 development friends and associates — Mother of All Frameworks. Except its not my framework or ontology. Its John Zachman’ s.

I had previous discussed my various discussions with John about the Architect Metaphor and the drafting paradigm that people only partly understand. My thought around such is that the Framework is a 2D projection of a Multi-Dimensional Problem-Solution Space. The issue I brought up then to John and continue to work; on sending him insights that I discover for he and I to discuss. [I am still a supporter of and hopefully contributor to the advancement of the framework] Is finding the logical/mathematical connection that binds the rows and columns together into a unified whole. The Unified Field Theory of Enterprise Architecture if you please.

I had agreed to read and review [soon to come on Amazon] Operating Model Canvas book by another colleague Andrew Campbell.

About a quarter in I found that it would provide some valuable insights to a project of mutual interest between Karen and I.   I fired off a quick note suggesting this may be of value as it focuses upon the “architecture of implementation” –cringe at the application of such a phrase, but in this context I think its true to my definition of architecture .

Her question back: “How does that differ from the Business Model Canvas? Seems like it puts the Value Chain at the center so there is more of a customer journey represented? Being a Zachman disciple, I see many of these as just a rearrangement of the Zachman ontology…”

Almost without thinking my reply came. It seemed so natural: “I see all of these models as either subsets of Zachman Ontology or auxiliary views (I.e. Combinations of columns or rows to create a specific perspective needed for illumination (same thing is done in other engineering fields)”

Which brings me back to the drafting metaphor and my original personal R&D. With so many I.T. and Business Framework popping up every day how is one supports to make rational sense of such. As stated above I believe all these others are simply views or auxiliary views of the Zachman Framework. These are not better or worse than each other, but specific perspectives needed to illuminate a specific item of interest, similar to such in the drafting domain.

 

Should you fire your CEO as part of the company’s next RIF?

It’s the next corporate off-site, the stock price is down, revenue is down, and margins are shrinking. The new CEO has had approximately one to two years in tenure. His recommendation to the board to “save the company and boost stock price” is to rebalance the workforce aka Reduction in Force (RIF). After several years of building up the workforce, capabilities, knowledge, and skills this seems the logical thing to do from his perspective. Lay off workers and get newer, cheaper employees. This is after stating its employees are its most important asset.

But is it? A decade or so ago several Blue-Chip corporations did such. Stock market reacted, as it does quickly with a momentary boost. However, as the years went on, the corporation’s product quality, customer service, and eventually its competitiveness dropped.

Solution? Hire back seasoned professions they laid off. Only problem, those employees when on to competitors, became competition, or now will cost the corporation more to hire back and will likely not have the same loyalty they once had (i.e., it’s now just a job not a career; they’ve learned from millennials all too well).

Given this state of affairs, should stockholders and the board consider laying off the CEO as part of that RIF also? Consider the statement: “Employees are our most important asset”. If so should the CEO be judged rather harshly for losing a large percentage of the corporation’s assets and value?   If intellectual property is really of value as inferred tens of thousands or possibly millions of dollars have walked out the door.   Would an executive at any company still be in place if they allowed a factory to be sold off for pennies less than what could be sold on the open market?

In the declining age of Superstar CEOs maybe a rating/tracking system is needed similar to those in professional sports leagues to see if those CEOs really do add value? Just a thought to ponder as I consider where to invest my retirement funds…

Structure in Threes: Revised Preface and start of Part One/Chapter One – An Architect’s View of Organizations

PREFACE

It has been close to thirty years since John Zachman coined the term Enterprise Architecture and introduced business to the Zachman Framework. Over the years, the metaphor has been used and abused, technical religions have grown around methodologies and still the term Enterprise Architecture is derisive.

• Is it an activity that produces a plan for building various systems?
• Is it the actual plan for an Enterprise?
• Is it a methodology to produce standard compliant designs?
• Is it a collection of diagrams that represent different types of information about the information systems used in an enterprise (the Zachman Framework Aka Ontology)
• Or maybe a specific set of standard components organized in a specific structured way

When I started the initial concept for this book years ago, I had considered creating a text that would provide methods for designing an enterprise; this being the goal of Enterprise Architecture or at least my belief is the goal. However, over the years’ experience has taught me five things:

1. Nothing is simple when explaining yourself; a lesson taught to me by John Zachman
2. Words have different meanings depending upon the context and experience of others; a lesson taught by Michael Kutcher, John Sowa, Gil Laware, and Frank Kowalkowski
3. The difference between a methodologist and a terrorist is that you can negotiate with the terrorist; a lesson taught by IBM CIM Architecture Department and TC184/SC4 & SC5 working groups
4. Thinking in the abstract and in multiple dimensions while technically possible by most, is often avoided in most enterprises in the name of speed and comprehension; a lesson taught by most managers and mid-level executives I’ve had to deal with
5. Nothing is foolproof as fools are so dam cleaver and Nature always sides with the hidden flaw; Murphy you were an optimist

Those insights came to light over the years of associating and working with those I consider giants and mentors in the field. Included in this book are vignettes of how those insights were developed; if for no other reasons than to pay tribute to my mentors and colleagues and to establish part of the context for the content in the book.

That being the bedrock I started building this work upon, I realized I needed to answer several questions first before I introduced my approach to Enterprise Architecture. The book itself is meant to be a practical guide on “practicing” Enterprise Architecture, a theoretical text explaining my perspective on what Architecture or more specifically Enterprise Architecture is, and how these fundamentals are expressed in practice.

Why Structure in Threes

Structure in Threes praxis guide toward the design of enterprise based upon a fusion of several concepts:

• A classic work from Henry Mintzberg, Structure in Fives, on strategy
• My original research and training in dwelling architecture from works by Vitruvius, Soleri, and Christopher Alexander
• Studies in Systems Theory from works from von Bertalanffy, Checkland, Forrester, Meadows, and Weinberg
• Studies and learnings from John Zachman

The title is meant both to honor Mintzberg’s leap of using a spatial reference to describe an abstract subject as well Zachman’s ontology that defines a multi-dimensional problem space that is enterprise.

About this book

This book is both a stand-alone work as well as a companion text for an educational curriculum taught by the author. The sole purpose of both book and curriculum is to raise the knowledge and skill level of practicing architects and associated stakeholders. While it will reference a methodology for demonstration it should not be construed as THE sole approach towards developing a praxis.

Simply put I am not intending to form yet another priesthood in the field. There are many paths to this destination and fulfilling the goal of designing an effective enterprise.

Part One – Theory and Methodology

 

An Architect’s View of Organizations – creating a coordinate system for an abstract space

In 1997 I had published an article “What is Architecture” to lay out the context for the full problem space I believe enterprise architecture should cover. In this article, I recounted an earlier discussion with several IT provider executives that I worked with. Primarily the dispute was around the representations of architecture, but quickly moved past representations to what architecture is.

My opponent in this discussion strongly advocated documenting a set of components in a hierarchy. “Here the architecture is these six devices connected together by this specific network type. That’s the architecture” He’d laid out a hierarchy of computing systems that looked much like an organizational hierarchy; One master mainframe at the top with a descending hierarchy of smaller and smaller mainframes, and eventually workstations or personal computers.

I had asked what was the rationale behind using a hierarchy and the selection of each component type at each level. The response was a blank stare. It was though I was speaking Martian to him. Then suddenly a rather heated response back. “O.k. tell me YOUR definition of architecture”.

Without trying to escalate what had become a heated situation I fell back to my original training. “There is a difference between architecture and design. Many people use the term architecture when they really mean a design….an architecture are the rules for the selection and usage of components and/or elements to achieve a stated functional objective. These can be structural and non-structural such as light & shadow, space, stone, glass and wood. This how these components are selected, used to fulfill an objective is the architecture. The actual instance of using these are the design.”

Defining the problem-solution space

From that discussion and the Zachman Framework I came to the conclusion that to effectively design and construct an enterprise one really needed to visualize this conceptual entity, Enterprise” in an abstract multi-dimensional space. A similar concept to how architects use the dimensional metaphor to define dwellings. What is missing in those dwelling visualizations (designs) are the rules that were used to create those designs. That is the architecture that was developed inside the head of the architect during his/her education and practice.

However, in discussion of those components, elements, and rules has not been a topic of discussion in most Enterprise Architecture narratives or methodologies. Instead what has been taught and discussed has been documentation/representation practices. This is equivalent to teaching drafting standards. And when rules are discussed it typically has been around sizing of components, not selection and use. Occasionally one gets into discussions around implementations: Mainframe vs Network, Network vs Cloud, etc. These are typically religious wars from vendors attempting to justify why their products are better or inclusion in the latest technology theme.

Hoping to avoid such conflicts, the first part of this text is aimed at providing the theoretical foundations for the reader to move past such religious wars by establishing the coordinate space for discussions on why and in what context to select and use.

Strategy, Resource, and Structure – the three dimensions of Organizations

Keeping with the theme of threes I believe that Strategy, Resource, and Structure are the primary dimensions of this abstract space where enterprise can be defined. This may seem to go counter to the Zachman ontology, however, if one looks at the ontology in an architecture context, the various dimensions are actually views of an enterprise. Thus, each box in the framework is a projection of one or more of these primary dimensions.

Class Structures in Dimensions

One other aspect of these primary dimensions is that each is actually a family of instances based upon the context in which these are used. A simple example, there are corporate organizational structures, software structures, business structures, etc. Each describes the arrangement and relationship between components. These will be discussed further in each dimension section to follow.

[Preview/Outline] Constraints in Design – Money Changes Everything

1. Money is both resource and measurement system for the game
2. Perishable Resource -Time the one resource that can’t be stored for later use
3. People – the multiplier resource

Strategy and Vision Analysis

Digging through some old files this afternoon to find this sketch from ’95.

After I had decomposed a Senior Executive’s Strategy and Vision to find some of the major weaknesses and suggest mitigations, he asked me into his office.  He had only put out the document a few hours before.  Mind you I had just joined the company a few weeks before when I sent the critique; other’s had warned me that was a career limiting move.  That this Executive didn’t like criticism.  So when he called me into his office shortly after sending my assessment.  Well you can imagine I figured; it was going to be one of the shortest careers in the company.

To my surprise and delight, he gushed over my assessment.  Saying it was a brilliant piece of analysis and wished others in his organization could do such.  All he could ever get from his subordinates was a weak “Because we’ve always done it that way” or other “I just don’t like it without any rational explanation.  His next request during the meeting was simple,  he asked me how I could do such so quickly.  I pulled out some paper, sketching out my process as I describe how I performed each step, and how each step fed the next in line.

Today I’m still analyzing strategy and enterprise architecture, design and construction; though my tools have matured some what, the objective of each step are still the same.

 

I guess the saying the more things change the more they stay the same still rings true.  Though many don’t realize, most of the new solutions touted are really the same ones from the past, just masked in newer technology

 

 

Organizational Design

This weekend I restarted efforts around organizational design dimension of business architecture. Its interesting to note that this is an area that most Enterprise and Business Architects do not address in their practice.  Perhaps as its been seen as non-technical and squishy, thus relegated to Human Resource Departments.  I think this is a tremendous oversight.  Both HR and Enterprise/ Business Architecture has a lot to gain from the synergies of working together.  EA/BA work is not all technology as it appears to be heading often.  This maybe due to the situation of EA/BA departments being rooted in IT organizations that are tasked with building out technology and see the others aspects (process, organization, economics, etc.) as a means to an end which Executives measure the IT organization on ( running back office software and fulfilling PC requests).

About two years ago I started some R&D around the organizational design vector of Enterprise / Business Architecture, came across an excellent book by Burton, Obel & DeSanctis on the topic and started to translate the materials into a analytic tool in EXCEL.  As I come close to completing the Business Model Evaluator spreadsheet, I plan on restarting this effort and linking to the BMC and Portfolio Management work I continue with.

 

…and yes this was the original vision I had for Active Directory way back when during my first stint with Microsoft.   Looking back twenty years its hard to believe we’ve progressed so much and so little.  I thought by now CIO Workbench (aka Enterprise Portfolio Management) would be a reality now, but the state of the industry is still a cataloging system for applications and a separate accounting system for tracking IT expenses.   The Value/Benefits Management work done at IBM, DMR, and Microsoft still is used as sales aids more than a investment management tool.  Guess I’m going to have to get funding and build out the system myself.

Internet of Things (IoT): Building a scalable Info-pliance (information appliance) business

Is IoT hype or a new level of capability

“The more things change, the more they stay the same” goes the story.  The Internet is a buzz around IoT (Internet of Things).  But just what is it? Your computer browser , Iwatch, house thermostat, light bulbs, your car?  Basically if technology vendors have their way almost anything could and should be connected to the Internet.  Sounds rather appealing don’t you think?  Imagine laying on the beach and turning you house lights on and thermostat up because you’ll be back home from your vacation in a few hours.  My thoughts are these are devices that create and/or consume information.  Turing on a light remotely has been done via multiple technologies for a while.  However, things change when the light gives you back information like, “I’m off/on, I’m about 70% in my forecasted lifetime. Maybe it consumes information to make decisions: a furnace filter telling your its time to change me because the airflow throughout the house is lower and the blower is having to work harder. Or possibly the furnace will tell you’re house to order a new filter to be picked up when you’re at Home Depot tomorrow.  These are what I will call “Info-pliances” as the primary function is based upon utilization of information, not simply having remote activation.

Now for the reality many devices will have to be modified to realize that dream;  consider the dozens of apps you’ll need on your smartphone because each speaks different language.   What about security?  That small little thing.  If you worry about having your credit card information stolen, consider what will happen when your door locks are just a simply scan or hack.  How about that security camera you bought to monitor your house when you’re away –vulnerabilities in webcams have already hit the news where hackers and the government can turn on your camera without you knowing.  You and you significant other could become the next YouTube sensation without even knowing.

All this sounds like I’m a fear-mongering luddite.  If you’ve read other posts on my blog you know I’m far from it.  During the 70s and 80s I might have well been Microsoft’s, Asus, Radio Shack and Heathkit’s greatest consumer customer.  I had wired up my Condo with all sorts of devices to automate my little place.  Thus driving my future wife crazy when lights would come on without her touch a switch, announcements that someone was approaching the front door, heat and air conditioning settings could be changed from my home office computer.  My home now has its own private datacenter and multiple networks running throughout, in addition being connected to Microsoft’s Cloud.  So if I’m not forecasting doom and gloom what’s this about?

First off most of these issues have similar analogs “in the real world Neo”.  Security and Privacy has always been a spy vs. spy game and is likely to continue to be such in the future.  The real issue to overcome will be integration and scalability if IoT is to become a practical and profitable business.  Consider the consumer appliance industry today.  Unless you are manufacturing high end products, with large margins, and a near first to market provider your market share and profitability is limited and days in market are numbered.  And even then smaller competitors are likely to replace your product and features at a lower cost to consumers.

Enterprise IoT Strategy

What this suggests that if an enterprise is considering entry into the Info-pliances market it would be wise to study the analog business.  Years ago there were many appliance producing corporations.  Over the years these have consolidated with many Brand names being just that, parts manufactured by the same company but Branded differently to segment the market on perceived value and status (Consider the real differences between a Firebird and a Camaro in the 80s).  This façade of differentiation was mainly a marketing strategy.   However, underneath such a strategy to be effective an enterprise needed several elements to come together:

First a product architecture that would enable interoperability.  This is based upon the assumption consumers want interoperability which appears to be the case from a casual observation.  In an info-pliance, this is all the more important as its value is based upon interoperability. With limited interoperability the perceived value of the appliance is less.

Second traditional economies of scale strategies may require reversing.  That is rather than looking how to ramp up production of a single product, vendors may need to create a collection of components than can be assembled and packaged into multiple types of appliances rather than one specific one.  Consider creating a modular family of components that can be assemble like Lego Blocks.  Electronics manufactures already do this at a lower level of capability.

Once such enabling capabilities are in place an enterprise could start a virtuous loop.  That is to say, adding new info-pliances cheaply because the use many of the same components and interoperate together out of the box.  This creates a double loop: Quicker time to market and increase market share loop, Increased customer value perception with each new device  Thus having the potential of creating a competitive advantage at another level.

Will info-pliances  take off and become the killer app of the decade?  Only time and the consumer will tell.

Internet of Things

During yesterday’s drive home and this morning’s drive into work I considered the latest Hype-cycle meme “IoT”, the Internet of Things.  That magical connection of every device to…  While we’ve had IoT in many forms prior consider X10 which many a RadioShack customer “wired” their house with, then PowerBus, etc.  Then as microcomputers truly became ubiquitous, home started getting wired for TCP/IP and later WiFi.  Now the amount of Wifi Hotspots around businesses and homes is staggering.  At an apartment a few years ago I was amazed to find no less than twenty-three private networks within range, no doubt all connecting various devices beyond a PC and providing services such as video and audio media.

Now as the term “IoT” comes into play I wonder if this and the “app” crazy has created the ecosystem that is the digital equivalent of what we all complain about airlines and hotels these days?  a la carte pricing and thereby cause the consumer and business to be the systems integrator.  The question become does “IoT”, “App Stores” and consumption economics become the perfect storm to devalue Information Technology and the complexity involved in integration.

I as this questions as more business executives question the value of enterprise and other technology architectures while in the same breath can’t understand why the pieces don’t fit together easily in just a flew clicks.  I wonder if that CxO’s car stops dead in the desert out of range of a cell tower will her or she be lost forever, given the likely inability to fix the technology they’ve asked for and become dependent upon.   About to decades ago and reprised the thought a few years ago, that one day businesses are likely to fail due to technology failure.  As this decade reaches the halfway point, I see that risk increasing beyond the obvious threat of hackers.

Structure in Threes: Business Design and Reengineering

The last round of brainstorming tightened up my thinking around the methodology.  Like all engineering endeavors I needed to identify the beginning point for creating the enterprise.  Most of the business model approaches are just that.  They document the existing and while that is necessary, is that sufficient?  When I’ve attended workshops focused on business models, often it ends up around optimization rather than innovation.  The strategy and planning methodology I devised and fielded for other corporations was purposely limited, because at that time these corporation’s business models were deemed untouchable.  Even though several people could see its useful life was coming to an end.  Secondly, reengineering a business model it difficult for most in management positions…their mentality is around optimizing the status quo.  Not a blame, it how they were successful and how they are managed in most corporations today.

The brainstorm I had the other day was along the lines I had decades ago when I suggested a practice that would design and build corporations custom for an entrepreneur.  Thus one has to look at what that means.  What would be the design parameters used in doing such.  The past month I came to the conclusion that businesses should be designed around the customer rather than businesses trying to find customers around them.  That insight brought me to using Peter Mark’s (Design Insight) tool Customer$APPEALS (C$A) to determine the design parameters for the “product” I’m building; an enterprise.

With C$A as a base one can use that to weight investment is the various aspects of the business model and value chain the enterprise participates in.  With that as the starting point my methodology has evolved to the following:

As of this positing I’ve tested this approach in two reengineering project that look to be successful and expect to do another pilot at another two corporations: one already in process and looking for another to pilot.  This “methodology model” will be one of several “views” in Structure in Threes” book and workshops I’m developing in spare time.  Expecting to have first workshop ready by summer.

Is Enterprise Architecture Completely Broken?

IASA Question Is Enterprise Architecture Completely Broken?

EA –that is credited to John Zachman– originally was “A framework for information systems architecture” a tool for MIS (aka IT) to “design” the components needed to support business objectives.  This was an evolution from a former methodology “BSP”  Business System Planning –also from IBM– which provide information to MIS directors and Business Executives to plan budgets/investments.  Later this budget prioritization was advanced by Parker-Benson in BEAM (refer to Information Economics).  EA roles became split into two camps:  Budgeting and Design.  The problems arise in that both roles forgot that the architecture role was that of facilitator rather than decision-maker and the primary stakeholders don’t have dialogs with these role holders typically.  This leaves rise to EAs creating visions and actions to create local optimizations.

Of course it is not too often that EAs are placed in a position that has the exposure and influence necessary to fulfill the role’s perceived charter.  Thus often EAs are glamorized programmers or software engineers granted the title after years of hard work in their domain by HR.  This gives them the title but not the scope or enterprise orientation.

More impactful to that position of influence; what CEO, COO or other CxO would grant that power to a non-executive.  While HR has toyed with titles such as CTO and CIO, the role of Chief Architect for enterprise has yet to be established in any meaningful way and has challengers to that title.  Books like “CFO, Architect of the business” are popular fair in the book trade.   And why would a COB/CEO/COO create such a role if they feel their role should be that, even if they don’t have the necessary architecture skills -after all they climbed to the top and are thus “entitled” to wear that crown.   However, it then gets back to a view of what an architect does/is.  Two schools or architecture: Architect as Decision-Maker, Architect as Facilitator/Advisor of Stakeholder’s Vision.

If one looks at chief design roles in other disciplines which have had more time to mature you’ll discover that such roles take years to develop an understanding beyond the mechanics of the discipline and how it fits in context beyond just building something.  This the senior role-holder must have a broader background than just Agile Development, DFD modeling, etc. and needs to step out into understanding the enterprise as a living organism. My recommendation is to study the Cybernetic Hierarchy in General Systems Theory to get beyond “Frameworks” and “Clockworks” through Adaptive/Dynamic Systems to Transcendental Systems.  These later types of systems capture more than frameworks do.  However with increases of information, increased thinking time is required to understand such data; something executives are in short supply of these days.

Business Model Enablement

One of the problems with Enterprise Portfolio Management (EPM) is its’ limited focus.  EPM to a large extent has been dominated by technocrats that act as though the entire enterprise is populated primarily by hardware and software; that is people exist to serve hardware and software needs rather than the reverse.

One can hardly blame management for this perspective and behavior when you consider the management systems in place such as financial systems have not evolved much since the middle ages.  Financial systems are “thing” based, listing such artifacts as depreciable assets.  While executives give lip service with such fraises as “People are our most important asset”, the majority of systems account for people as liabilities. When was the last time you saw a balance sheet listing the value of the people employed within the corporation?  This seems rather odd considering H/W and S/W requires people and their skill and knowledge to operate, maintain, and gain benefit from these other assets.

This brings me back to business models, currently the rage within executive and VC circles.  In the Business Model Canvas activities and resources hold a key position.  Its though these two components that value is realized as per the company’s value proposition.  Yet often neither the activity or resources boxes account for the people component –expect as either partners to engage with or customers to engage with.

Yesterday’s R&D activities has me investigating corporate capabilities and the associated competencies of people that enable these capabilities which are used to enable the business model.  Several years ago I developed a competency model that was associated with the process activities for a major function within corporations.  I see revisiting that work in light of business models will likely produce the alignment between people, portfolio, and business model that I’m looking to address in this round of R&D.