IT environments tend to become more and more Complex. When planning for new or additions and changes to existing (IT) environments, the necessity to invest in decent preparation and high level design isn’t challenged. Not challenged because alignment with the long term business goals is key in many organizations.

In practice we see increased fragmented preparation and design cycles. IT-components are being broken up in smaller and smaller parts in response to this increasing complexity. When going unchecked these endeavors unwillingly create new and increase existing gaps between actual IT implementations and these long term business goals.

Long-term inability of closing these gaps puts the company at risk, wasting critical company resources dealing with various side-effects like:

inability to quickly adopt new or phase out outdated technology,
increased costs of ownership,
increased time spent during exploration and preparation phases,
fuzzy business objectives and requirements,
misconceptions throughout all the phases of the product and service life cycle.

At the same time we see companies adopt agile teams that use an iterative, demand driven and pragmatic approach to IT implementation, change and run. These teams have a limited business scope that works very well. This helps the teams to perform in an flexible and productive way.

As a side effect the increased productivity and flexibility is also increasing the speed with which misaligned gaps are created and evolving. Without an architectural guiding mechanism, traditional long term business objectives will be harder and harder to realize.

For example, allowing each of the agile projects to pick their own implementation based on the short term requirements only. This will undoubtedly create problems in terms of compliance and other requirements set out throughout the business.

While creating ‘small, simple and easy to organize’ working environments within (complex and challenging) environments is a proven concept, we need teams to be aware of and be able to understand the long term consequences and even risks introduced by their day to day IT choices. Traditionally this is where architecture steps in.

My personal observation is that either architectural initiatives are absent or are struggling to keep up with the pace of the organization. This is either because they are still operating rather traditionally (define, design, validate, instruct and adjust) or are in disconnect with the development teams throughout the organization.

The increased pace of agile development requires the architects to become more flexible and the agile teams to step up and take their shared responsibility. This requires the agile teams to develop a holistic awareness and actively involve architectural support throughout the stages of the development life-cycle.

This leaves us with the question: How can we help these organizations and enable agile teams to identify and close gaps between the enterprise business objectives and the individual development initiatives without the latter losing their focus, flexibility and productivity?

A rather similar question was asked by John A. Zachman in the mid 80s, which he eventually answered through the creation of the so called Zachman Framework.

Basically the Zachman Framework is defined as an ontology diagram that allows anyone to describe any design covering all the (possibly relevant) business perspectives. Today the Zachman Framework provides a one-glance overview of the entire enterprise.

The Zachman diagram is a six by six matrix-diagram that shows the “5W1H model^[1]” on the horizontal axis. Basically the 5W1H model forces you to ask 6 questions (What, How, Where, Who, When, Why) over and over again to get the best possible understanding of the underlying motivations.

On the vertical axis the diagram differentiates six different (business) perspectives (Contextual, Conceptual, Logical, Physical, Informational/Data, Usability). Confronting each of these key elements results in 36 perspectives in which any given design can be described, explained and if done correctly, understood. The next figure shows a graphical representation of the Zachman Framework.

Figure 1: Zachman Framework ^[2]

Sadly there are some misconceptions concerning the Zachman Framework. The most common one is in which the Zachman Framework is seen as a methodology and can therefore be compared with architectural frameworks like: TOGAF, IEEE1471 or EA^[3]. This to my opinion is a faulty comparison comparing a methodology (how can we achieve something) with an ontology (how can something be classified).

Another misconception is the notion that the Zachman framework isn’t relevant anymore and should therefore be ignored. This is a notion that should be rejected in my opinion. The components used in the Zachman Framework are not prescribing and are not time constrained. My guess is that answering for instance: “what business model, why do we have these business goals” will remain relevant for a very long time.

The validity of Zachman is also recognized by various architecting frameworks in which Zachman is actively adopted within their toolset. For instance when reviewing “Developing Architecture Views” within TOGAF^[4] you might notice the reference. Finally new research proposals to adopt Zachman in smaller environments using an action-research approach^[5]are already formulated.

Zachman has helped me personally to plan, observe, reflect on and challenge designs and their implementations. A nice example is the introduction of the new GDPR regulations in Europe. Allot of my customers where uncertain where to start implementing these new regulatory demands concerning privacy and how this would affect their business. In these cases Zachman helped me guide the customer in identifying the domains affected and discuss how they are affected.

In conclusion, the Zachman framework provides a frame of reference that can help any size organisation to: guide, structure, focus, track and review their high level design endeavours and help increase the awareness of the broader business requirements within teams.

Want to know more?

Feel free to contact me my colleagues or have a look at :
https://www.amis.nl/wat-we-doen/architectuur

^[1]https://en.wikipedia.org/wiki/Five_Ws, visited 2020-03-10

^[2]https://sparxsystems.com/resources/gallery/diagrams/architecture/arc-zachman-framework.html, visited 2020-03-13

^[3] https://ea.rna.nl/2019/08/21/john-a-zachman-agile-at-82-85/, visited 2020-03-13

^[4] https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap31.html, visited 2020-03-13

^[5] https://ui.adsabs.harvard.edu/abs/2013EntIS…7..100N/abstract, visited 2020-03-13