Zachman Framework
I find it so surprising that in today's world, I came across a whole bunch of people who call themselves as “Architects” who have no idea or clue as to what the Zachman Framework is. I am not trying to be critical towards those people, they are probably very smart and know their stuff, but I figured maybe its a time for a crash course.
John Zachman is the author of the “Framework for Information Systems Architecture” that is broadly accepted (in the world) as a framework for managing change in Enterprise environment. John was also one of the key contributors to IBM's key methodology and techniques in the 70's.
The Zachman Framework in the context of Enterprises is simply a logical structure for classifying and organizing the (descriptive) representation of a Enterprise that are key to its Management. It derives from corresponding structures of older disciplines of Architecture/Construction, Engineering / Manufacturing which organize entities created over the process of designing and producing complex products such as an airplane or a building.
The Zachman Framework in the context of Enterprises is simply to establish a common vocabulary and set of perspectives for describing complex enterprise systems. The framework is influenced by principles of classical architecture and is reflected in the set of rules that governs a relationship. The framework at the end of the day provides a blueprint (or Architecture) for an enterprise's information infrastructure.
The scope of this framework is of an enterprise's infrastructure comprising of six perspectives - planner, owner, designer, builder, subcontractor and the working system. There is no guidance on sequences, processes or the actual implementation, but the focus is to warrant that all aspects of an enterprise are well-organized and exhibit clear relationships to reflect a complete system regardless of the order they are established in! What a novel idea!
Major principles that guide the framework are:
- Complete system can be modelled from the answers to the questions why, who, what, how, where and when.
- The above 6 perspectives capture the critical models required
- Constraints for each perspective are additive i.e. those of a lower row are added to those of the above row to provide a growing set of restrictions.
- Each column depicts a different abstraction to help reduce the complexity of any single model
- Model in each column must be unique
- And along the same lines, each row must be a unique perspective
- Lastly each cell is unique
- Also, columns have no particular order
The framework contains 6 rows and 6 columns yielding 36 unique cells. Check out an image here. The rows are broken down as follows:
- Scope - Corresponds to an executive summary (for estimation of size, cost and functionality).
- Business Model - Depicts all the business entities and their processes alongwith their interrelationships.
- System Model - Depicts the data elements and software functions that represent the business model.
- Technology Model – highlights the constraints of the tools and technologies being considered or used.
- Components – represents the individual modules that can be outsourced to different teams.
- Working System – depicts the operational system.
The columns are broken down as:
- Who – depicts the organization (i.e. people relationships) alongwith the work allocation and structure of authority and responsibility in an enterprise.
- When – depicts the even relationship (or time) that establishes quantitative level ands and performance criteria for enterprise resources.
- Why – details the goals, objectives, business plan, knowledge design and architecture of an enterprise i.e. the motivation.
- What – describes the entities involved in each perspective of the enterprise.
- How – shows the functions within each perspective.
- Where – depicts the intercommunication and location within an enterprise.
So, what does it all mean?
The perspectives (i.e. rows) are abstract at the top and become more specific (thus detailed) as you move towards the last row, with an implementation “emerging” at the last row. This implies the perspectives can be mapped to a product development lifecycle with the top rows being used early and the bottom rows gain more importance during the next phases. This makes the top two rows business oriented and the rest of them more technical. The “business concepts” from the top rows must be embedded into the business objects (or components) in the bottom rows and can be refined over time as long as their relationships don’t change. Since the order of the columns has no prescribed meaning they can be arranged to align with the object-oriented design.
Frameworks can be used recursively to manage the complexity of enterprise architecture. Also since the Zachman model are procedural, there is not reason why it cannot be mapped to to say the Rational Unified Process (RUP), with the requirements being captured in the why column and the associated actors in the who column.
The framework for Enterprise Architecture is purely a tool that when used correctly can be an asset for both technical and non-technical management alike. You can find more information at the Zachman Institute for Framework Advancement.