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

The Death of Enterprise Architecture

ea-tombstoneThis morning I read a rather despondent post by a peer seemingly on the verge of giving up Enterprise Architecture.  Not a particularly happy thought.  It was reminiscent of the death knells I heard a few decades ago and seems to repeat each decade.  

At that time large corporations had just come off of a great high on Strategic Planning, Enterprise Architecture, and other master planning activities.  There was a great trough of disillusion regarding any planning activities.  Comments like “things are always changing, so planning is a waste”; “you can’t plan for everything”; and other criticisms of planning and design were popular in the culture. 

Such comments resonate well in the cowboy culture of American Business; except when it comes to production where tremendous efforts to plan resource utilization are common.  Look at the success of ERP software as an example. 

My thoughts on ERP mega-success verses other Design and Planning software moderate success draws me to the conclusions I had back during the first trough of disillusion.  At that time “Architecture Practice”, that is the design of physical dwellings, had hit a slump or rather a restructuring.  I had been informed a career in designing buildings was going to be a difficult undertaking as investment in construction had dropped and one of the cost cutting measures development organizations and people were taking was to reuse designs (patterns and practices) rather than create or customize to individual preferences.  The perceived cost verses the benefits of hiring an architect were not in balance.  As such the question I had for my advisors: Will I be on a street corner with a sign “Will design a house for food” seemed poignant. 

Fast forward to today.  Many of my peers back then left the profession within two to four years seeing that the industry restructuring had reduced the capacity of resources needed to meet demand.  

There are strong parallels to today.  With the advent of best practices, templates, etc. the needed capacity for parametric designers (i.e., template completion staff) has reduced.  As such the role in EA has more and more become closely associated with IT presales and support.  This maybe because of its origins in information technology presales and support.  

Whether this is good or bad is up for discussion.  On the positive side such roles enable one to learn and develop soft skills working with line of business and possibly executive management.  On the negative side it often constrains one to focusing on the technology aspects of an enterprise.  Those thoughts of working to define the business are often far from reach.  Your role is to translate business capabilities defined by the business design into technology requirements, determine which technology is most appropriate, or defined implementation details. 

Notice I did not mention defining the business or business model.  Until you are in the inner circle of Executive or Line of Business Management you are unlikely to be given the opportunity to define or influence the business design.  If lucky, you’ll be asked to document the business model.  This would be the entre into business design.  From there if you can provide insight and value regarding the business model choices from other than a technology perspective you may be invited into the inner circle as an “intern”. 

The thing to remember here is that, its their business, not yours.  You’ve been invited to give insight, not criticize or make decisions.  Unlike Frank Lloyd Wright you don’t have a successful brand as a business designer, that enables you to dictate all the aspects of a design your client will have to accept if s/he wants a “Frank Lloyd Wright” House.   The closest to such defined business models that owners accept as given would be franchises like Mc Donald’s, etc.  There the business model has reached into the best practices, Patterns and Practices level.  

So what does that say about Enterprise Architecture and where it should report to?  Yes, designing the business is possible, but it will take time and effort to gain trust to be given those opportunities.  Understanding your role as a translator of business capabilities to technology will likely be the core of your practice.  While business model design and definition will be needed stills, the freedom to change these are not often granted.             

 

Saving your way to Bankruptcy

How often have you hear “Honey I bought it on sale and saved us a ton of money”? Really? Did at the end of the month you could see your bank balance increase? Often, we hear similar words inside an enterprise. We’ll saved 1000 man-hours with this new project.   Can you really save man-hours? I’ve not seen any place where time could be saved, much less get paid interest on it.

So, if these questions seem logical, why do we continually hear internally and from vendors about all the time savings? Possibly because emotionally we all like the idea of bargains and savings. The problem becomes that savings is not always savings.

Several years ago, I help develop an economic justification methodology specifically for my employer. As I had done this previously for other employers it wasn’t a large stretch if all they wanted was a standard ROI procedure.   I had brought up to management building an business case on time savings would have little value as CFOs and other management would know time saving is not economic benefit unless you do something with it or avoid having to get more resources to accomplish the goal.

The simple examples: I could automate a process using technology “saving” one hour a day per person. If I can defer hiring additional resources (cost) to accomplish a goal for a smaller investment in the technology, then I’ve actually saved money. If, however, I “save” one hour per day of staff time and nothing is done with that time, then I’ve actually lost money. If I continue to save time and money this way, I’ll be bankrupt in no time.

My advice for avoiding such a problem is while in the planning phases of a new initiative consider what you’ll be doing with the savings. Will the staff be able to effectively use that additional hour a day? This could be getting out one more proposal to a potential client, exchanging knowledge between peers, or any number of other activities. The key here is to have a plan on how that savings is to be used.

New Instructional Video Channel coming

Working on first instructional video for Digital Advisors and Enterprise & Business Architects for my new YouTube channel you can subscribe here: https://lnkd.in/gdxzmyW

KPIs – Key Performance Inhibitors and a method to transform theses back to Indicators

This month I am dividing my time between several initiatives at work:

  • Technology development activities
  • Process adoption
  • Metrics definition
  • Skills transfer

A rather interesting and eclectic combination of activities. But as I started to ponder these I started to reflect on the metrics definition activities of past and the relationship to other initiatives on my list. My goal is to create a suite of KPIs for my group that is useful in advancing our success. With that premise several things come to mind.

  • KPIs or metrics that truly indicate how the organization is progressing to its goals; rather than those fool us into believing we’re doing well when we’re not
  • KPUs that the organization believes in; that is, we have control in positively effecting these and can relate to achievement of our goals
  • KPIs that are diagnostic; they provide insights to help us determine what we can do better

This is a tall order considering people often are suspicious of how measurements are used. Especially if such has been used in the past not as guidance but justification for other agendas. This typically results in KPIs that are meaningless but always show green, even in the face of disaster. Such have a witnessed before within sales organizations that measured success by size of backlog rather than quality of backlog or customer satisfaction. This eventually became a game of musical chairs with the unlucky sales rep. at the end of the cycle taking the hit for a bad backlog he had nothing to do with.

Based upon such experience, my belief is that KPIs need to be a serious discussion and negotiation between all levels within the organization. Staff must believe that these measurements are able to be influenced by their actions; Management must believe these measurements indicate status of the journey to goal achievement.

These seem simple enough, except that the altitude that each party operates at is different. If you’re a Senior Executive you’re often looking at corporate performance: profit/loss, customer satisfaction, market share, etc. If you’re a programmer in IT you’re focus is on cost and time of delivering an application, response time of system, uptime, etc. This difference in metrics can and often does create misalignment between management and staff.

The results of which is often KPIs become Key Performance Inhibitors as staff become disillusioned with measurements as they can’t relate their measurements with goals management focuses on rather than how their measures relate to business measurements.

This conundrum can be address with a method called Hoshin Planning. Hoshin Planning is nothing more than a cascading set of matrices of goals, strategies, and measurements that relate one altitude of measurements to another. While the technique works well, it does require additional effort between management and staff to be explicit about the goals, tactics and measurements as well as reasonable in setting measures and targets that assignees believe are achievable. This however, is not a simple twenty-minute exercise and like all planning requires constraint revision in the light of new information (i.e., planning forecasts are not accounting transactions).