How the Zachman architecture provides a framework for business analysis

Architectures provide structure and context. The Zachman architecture can provide a framework for business analysis.

Generic Business Architecture

The diagram shows a generic architecture.

• The business process architecture shows the key business processes and their inter-relationships
• The information architecture demonstrates the information that is used and created by the processes.
• The application architecture shows the organisation of software applications that support the processes
• The technology infrastructure architecture shows the hardware, system software and networks that support the operation of the applications

Architecture may be considered, at least in part, to combine the business and techical views of the,

• Business processes
• Information
• People
• Location
• Business and technical cycles
• Strategy

of an organisation.

Business rules can impact all aspects of the architecture.

These are all concerns that a business analyst can, or should, be involved with. These concerns aspects are neatly summarised in the infographic by which most people recognise the Zachman architectural framework, one of the best known representations of an enterprise architecture.

The Zachman architectural framework

The Zachman framework is a 6 * 6 matrix.

The columns represent different aspects or artifacts of concern to an organisation.

The rows represent different views of each aspect or artifact.

The columns of the Zachman framework

The columns cover the six questions that are the concern of all business analysis work:

• What – Data
• How – Processes
• Where – Locations
• Who – Responsibilities
• When – Timings
• Why – Motivations (Ends and Means)

The rows of the Zachman framework

The Zachman framework further defines these six elements as 6 rows.

Zachman says that the significance of the rows is often misunderstood.

Each row  reflects a different view, or 'perspectives' of the things in the columns, ranging from, top to bottom,

• Ideas to physical things
• Conceptual views of senior management to the physical views of the people who make these ideas real

Things in the top three rows are described using the 'business' language of the organisation.

They describe the perspectives of the business stakeholders in any change programme or project.

• From the point of view of IT and business change programmes, these rows are the main focus of people with job titles such as
  • business analyst
  • product owner
  • business architect

• The top three rows contain the artifacts that provide
  • the basis for defining a business architecture
  • context to work of the business analyst

Things in the bottom three rows are described in the more technical language of the people who make the ideas work.

• These lower rows involve IT staff and other roles needed to get things to work in a complex human environment
• The IT roles that that work at this level have job titles such as,
  • Solutions architect
  • System designer
  • Programmer or developer
  • Tester

Although business analysts are particularly concerned with the top three rows, they will also need to understand something about the perspectives in the lower rows.

The third and fourth rows can be considered as forming an interface between the business and technical perspectives.

At the interface, business requirements and models can be reviewed by designers, developers and testers to ensure that they are,

• understandable
• a reliable basis for building a solution

These rows contain the artefacts that will be discussed, developed, tested and implemented by teams that are following an agile approach.

The top 3 rows in more detail

1. Identification ('Contextual')
   1.  Lists of business (data) entity types, business processes, etc.
   2. This is described as providing the ‘executive’ perspective.
   3. Zachman defines the models at this level as ‘scope contexts’; they are essentially lists of the organisation’s information assets.
   4. Many organisations have never defined a complete and agreed list of their business processes, business data concepts or other vital assets.  Such lists can be the basis of glossaries that are agreed and reused throughout the organisation ; ownership of the business glossaries should be at senior levels in the organisation.  Having such glossaries greatly facilitates the work of business analyst.
2. Conceptual
   1. The assets identified in bullet 1 are defined in business terms.
   2. This level is said to give the ‘business management perspective’.
   3. The assets are modelled at the conceptual level.  For example,
      1. Data is modelled in terms of business concepts and business associations between those concepts
      2. Processes are modelled as the business transforms and business events, outcomes, inputs and outputs.
      3. According to Zachman, the models at this level are collectively known as ‘business definition models’.
      4. Note that data modelling is sometimes seen as a purely technical activity.  The Zachman framework makes it clear that such conceptual models are clearly in the domain of the business; all business analysts should be able to create such conceptual models.
      5. At this level, the business analyst is busy talking to the business stakeholders.
      6. But the BA also needs to communicate regularly with the technical and testing teams who can be considering options for creating and verifying solutions.  We believe that the most effective way of working is in cooperative multidisciplinary teams such as those seen on agile projects.
3. Logical
   1. The same assets are now modelled so as to show the logic
   2. The ‘architect’ (‘business logic designer’) perspective
   3. At this level, the models are of ‘system entities’. ‘system transforms’, etc.
   4. The models may well look similar in style to the more conceptual models created at level 2; there is a natural progression between the levels.
   5. This level may be thought of as the crossover from the business oriented roles such as business analysts and architects to the more technical roles such as solutions architect.