Business Process Management / design patterns / expense / Financial Management relationships / financial setup / Generic / generic objects / management capability / management to transaction / motivational factors; benchmarking / offer / party / revenue / Risk / suppliers / universal objects

Zachman Framework and Myths

Myths in a Sea of truth

We often tell ourselves this framework doesn’t work for reason x.

  • My situations unique for reason “y”.
  • My situation doesn’t allow me to acquire rows 1 and 2.
    • Your okay; we have a highway analogy to guide you and your job will need to understand the way your organization fits into the system.
  • I must challenge all those who feel they cannot see the value and suggest you not associate your work Enterprise Architecture.

Zachman’s Ontology (Zachman Framework)

In fairness I am not an expert architect; I am the consumer and person who cleans up the mess when people don’t get it right.

  • Without the 1st row you are unable to understand the boundaries of the organization and it’s mission.
  • Without the 2nd row you are unable to understand the process and sequence to acquire the definition.
  • Without the 3rd row you are unable to understand how to represent the organization.
  • Without the 4th row you are unable to design the specification based on the representation, derived from the understanding of the mission and definition.
  • Without the Rows 1-4 the selection of the components in the architecture will be in excess of the next row.
  • Without Row 5 you have no reason to have the conversation.

If you fail to understand and respect the requirements from rows 1 and 2; you will force the need for someone like me.

Risk of higher cost models

Perhaps you celebrate and claim success until the auditors come to visit and inform your stakeholders that your changes cannot be explained nor traced and now your organization has a management non-conformance.

The first two rows in the Zachman framework (ontology) tells the EA what the two audiences need from technology and the architect as the owner of the systems.

  • Business people rely on technical people who wear Enterprise Architect hats; they need them to own the technology strategy.

Think about this scenario;

The two stakeholders have grown fond of an apple tree in the middle of the forest and they hire you to help them “because the tree will not produce fruit and doesn’t look healthy”.

You do some research

The golden rule with growing apple trees; they must have direct sunlight.

You don’t have the trust built within your team nor with your manager;

What makes sense?

Will your stakeholder feel you’ve honored the importance of the apple tree and you haven’t had the critical conversation?


Value can be measured by “the growth” and “the new fruit” which results each season.

  1. The tree in the center of the forest surrounded by taller trees which block the sunlight from reaching the apple tree.
  2. The larger trees roots smother the smaller tree leaving little moisture from reaching the branches of the apple tree.

Any approach that fails to highlight the fact that the tree must be moved to a location with direct sunlight would not be truthful and you may cause more harm than your concern for your role.

Value is not the fact that you left the tree in place and built around it.

Sure in this scenario the framework of having direct sunlight cannot be achieved and the tree is doomed.

Do you make the rest of the forest look well designed and plan for 3 years?


Do you simply tell the top 2 stakeholders that they must move the tree outside the forest to realize growth and produce even 1 apple?

What motivates you to do any of the following;

Will you ignore the framework to avoid the difficult conversation?

  • Most people would.

Unfortunately, the majority of the managers who were polled about the types of employees they would prioritize a person who get’s along over a person who has diverse perspectives.

If your manager rewards based on fact or reality;

  • Does the manager view the value to your clients in having zero difficult conversations?
  • Absolutely, they want someone who get’s along.
  • Not someone that suggest bad news to the executives
    • Political Suicide – All employees who are willing to have difficult conversations early to ensure the investment meets the context and definition of the STRATEGY.

As an auditor the decision making process has non-conformance

  • Management activities

As an auditor the control design “ineffective”

  • Dependent upon the number of defects and those dependent on the control.

The analogy  meets the criteria to elicit the following;

Column 1 “what”
Column 2 “how”
Column 3 “where”
Column 4 “who”
Column 5 “when”
Column 6 “why”

Explain Rows 1-3 in the framework for Business and Enterprise Architects

The following defines a RACI with deliverable(s)-Row 1 and 2 would be the Business Architect role to acquire and manage
Row 1 – Executive scope and context through identification of each column.
Row 2 – Business Managers Definition of the following;
Entities and Relationships (functions), Process inputs/outputs, Distribution definition locations, Roles Definition, Movement Definition(frequency & boundaries), Means Definition (business end and business means)
Row 3 – Architect – Systems Logic C1-Inventory Representation C2 Process Representation C3 Distribution Representation C4 Responsibility Representation C5 Timing Representation C6 Motivation Representation

Row 1 – Executive – Scope Context – C1-Inventory Identification C2 Process Identification C3 Distribution Identification C4 Responsibility Identification C5 Timing Identification C6 Motivation Identification
Row 2 – Business Management – Definition of each column
Row 3 – Architect – Systems Logic – Representation of each column
Row 4 – Engineer – Technology Physics – Specification of each column
Row 5 – Technician – Tool Components – Configuration of each column
Row 6 – Enterprise – Operations (users) – Instance of each column

Wearing the BA hat;

Global standards for example ISO doesn’t change often “the projects” and “the way the standards are used change by org”; as continuous improvement and problem management refer to the post project scope typically.  The key is knowing when and what applies by design we can.

I take this a step further; I structure the Enterprise Project files by each column (naming the context, in order as shown in row 1.  The child folders represent each column and within each of these a folder with row 2 another with how row 2 and 3 transition from BA to EA roles.

Results-predict the intended behavior and reference architecture


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s