6 years, 10 months ago

The Zachman Framework – The Perfect Tool for Operating Model Management


I have written previously on this blog about leveraging Enterprise Architecture as a methodology for the Operating Model creation and management. In this blog post I will briefly outline mechanism and benefits of using industry leading Zachman Framework as a specific tool for Operating Model creation and management. 

The Zachman Framework, initially named as A Framework for Information Systems Architecture, by John Zachman was published in an 1987 article in the IBM Systems journal. Since then it has been revised and enhanced by John Zachman a few times and the current version 3.0 is now owned and managed by the Zachman International.  The current version 3.0 shown below is available on its website. 

ZF3.0sm
Zachman Framework for Enterprise Architecture
All copyrights with Zachman International


On this blog I have covered various aspects of Zachman Framework and thinking behind it from John in a number of posts. His thoughts on using the framework to address complexity and changethe framework being ontology – a classification for Enterprise Assets and components are well documented in my previous posts and hence I won’t repeat in this post. I will try and briefly cover how the latest version can be used to address the Operating Model creation and management challenges.

Zachman is a two dimensional schema; the first dimension “the Abstractions” offers a way to classify the Organisational Operating Model from six unique aspects;
  1. What –  the Inventory Models within the Organisation e.g. List of Products
  2. How – the Process Models within the Organisation e.g. Product Selling Process, Product Definition Process, Pricing Process etc. 
  3. Where – the Distribution Models within the Organisation e.g. the Locations where Product is designed, sold, supported etc.
  4. Who – the Roles & Responsibility Models within the Organisation e.g. who plays what role in Product Sell Process, who is responsible for Servicing
  5. When – the Timing Models or Cyclical Models of the Organisation e.g. Peak / Off-Peak season of Product demand, When to release a new product
  6. Why – the Motivation Models or Business Objectives which drive the Organisation e.g. “Be the leader in xyz Product Market”, “Exit a Segment”
The second dimension of the Zachman Framework “the Perspectives” presents a classification system to record different view points depending on your roles. The framework offers six unique perspectives;

  1. The Executive Perspective – Typically board members and executive leadership perspective which defines the business context along with scope and boundaries of the Enterprise (or a large transformation or a division depending on what problem is Operating Model addressing)
  2. The Business Management Perspective – Typically business unit director’s, P&L owner’s, Product manager’s perspective which defines business concepts , definitions, high level requirements for the Enterprise (or a product or a service or a division, depends on what problem you are solving)
  3. The Architect Perspective – No this is not about IT yet…this is the perspective of the business logic designer, logical modeler who represents the Business Management Perspectives in logical constructs or structures such as Models, Design Logic etc. 
  4. The Engineer Perspective – This perspective covers technology models, physical models, specifications. Something which bring logical models close to physical reality
  5. The Technician Perspective – This perspective is all about implementation, tools configuration, applying tools and converting physical models into reality
  6. The Enterprise Perspective – This is the End User Perspective and covers the actual implementation. e.g. single product management system deployed in 12 different physical markets across different divisions. 

I am probably running out of time and space to explain all the interactions across these two dimensions in a single blog post (I will probably add a few posts on this later)…but just to cover a few specific points about Operating Model creation or management…

  • Operating Model is created through a series of transformations….from first perspective, the Executive Vision, Scope, Context through to Definitions, Logical Models, Physical Models, Configuration / Build and Implementation. 
  • The 6×6 Matrix of Perspectives and Abstractions contain only “primitives” – single entity only at a time and does not contain complex structure “composites”. 
  • This enables effective reuse of Enterprise Elements and isolating problems on one variable at a time. The idea is two (or more) primitives then can have interactions to create composites. e.g. Inventory is Processed across Locations by Roles at a specific Time to achieve a Goal.
  • John compares this Primitive Vs Composites to Engineering Vs Manufacturing. Operating Model creation is an Enterprise Engineering Task not Manufacturing Task. 
  • And by the way the classification system ensure that you are engaging right stakeholders and asking right questions along as you progress. 
  • You can create all sorts of interaction matrices as it suits your business problem. E.g. if you are solving the “Cost Reduction” problem a matrix of Data Entities, Locations, Roles Vs Process will easily surface the most redundant Roles, Locations, Processes by following above steps. 
I will just break a major myth and then stop this post…YOU DO NOT HAVE TO BOIL THE OCEAN TO DO ENTERPRISE ARCHITECTURE. You can choose the single, most important business problem and model that using this framework. It may be a specific product launch or a redesign of a geography or a business unit, similar concepts work. I rather prefer doing this in small chunks in a meaningful way to deliver business goals than do modelling for the sake of it for months. 

And before you ask, Zachman is a Framework. A Framework is a Structure. TOGAF is a Methodology. Methodology is a Process. A Structure defines something, a Process transforms something. It’s not either or both have their own purpose depending on what you are trying to achieve. 

So in summary if you are defining operating model for an entire enterprise or single division, use primitive elementary modelling using this 6×6 matrix and arrive at an Operating Model in iterative way. I will probably share some more example matrices in future posts. 


On a personal note….
Amit with John in a recent Zachman Workshop

John is still the driving force behind it and I have been privileged to understand this framework or this classification system from him a number of times in recent past. John’s passion for thinking of Enterprise Architecture as the enterprise business classification system needs to be understood, communicated and developed further by Enterprise Architecture community. I still hear a few architects or even a few senior architecture managers associating Enterprise Architecture only with technology. Please don’t sell Enterprise Architecture short, don’t undermine the capabilities and possibilities offered by this tool / method / framework. Applying it to resolve most complex organisation enterprise problems such as Operating Model is the perfect application scenario.