Generic Business Architecture
Before looking at the Zachman framework for an architecture, take a look at the accompanying diagram;
- The business process architecture shows the key business processes and their interrelationships.
- The information architecture demonstrates the information that is fundamental to the business. This information might include concepts such as Customer or Product. It is
valuable to a business to have such concepts defined and agreed at a senior level of the business. It facilitates communication between the business and IT. - The application architecture shows the organisation of software applications. Considered hierarchically, we can also see how this layer of the architecture supports the business view
of processes and information concepts. - The technology infrastructure architecture shows the hardware, system software and networks. Considering this hierarchically, we can see the relationship between the software applications and their deployment onto hardware and their support by middleware and common system services.
This generic architecture can highlight where the business analyst interfaces with a more technical architects, designers and developers.
Architecture may be considered to comprise the processes, information, people, technology, infrastructure and motivation of an organisation. These are all aspects of an organisation that a business analyst can, or should, be involved with. These aspects are neatly summarised in the infographic by which most people know the Zachman architectural framework, one of the best known representations of an enterprise architecture. Below, we show our representation of that infographic.
Zachman Architectural Framework
In Zachman, the 6 aspects are represented as columns in a 6 * 6 matrix. The columns are:
- What – Inventory (Data)
- How – Process
- Where – Distribution networks (Locations)
- Who – Responsibilities
- When – Timings
- Why – Motivations (Ends and Means)
The Zachman framework further defines these six elements at 6 levels (rows), ranging from the conceptual view to the technical you. As a business analyst, you are likely to be particularly concerned with the top 3 levels. These top three levels of the framework may be the basis for defining a business architecture for your organisation. They identify the progressively more detailed views of the organisation models that you are likely to be identifying, analysing and modelling. They can provide context for your work as a business analyst on any project.
Levels 1 to 3 of the Zachman framework are briefly described below. Levels 4 to 6 are summarised in the fourth and fifth bullets.
- Identification, i.e. lists of business (data) entity types, business processes, etc. This is described as providing the ‘executive’ perspective. Zachman defines the models at this level as ‘scope contexts’; they are essentially lists of the organisation’s information assets. 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.
- Definition, in which the assets identified in bullet 1 are defined in business terms. This level is said to give the ‘business management perspective’. The assets are modelled at the conceptual level. For example, data is modelled in terms of business concepts and business associations between those concepts. Processes are modelled as the business transforms and business events, outcomes, inputs and outputs. According to Zachman, the models at this level are collectively known as ‘business definition models’. 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. At this level, the business analyst is busy talking to the business stakeholders. 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.
- Representation. The ‘architect’ (‘business logic designer’) perspective. At this level, the models are of ‘system entities’. ‘system transforms’, etc. 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.
- The fourth level was described as the engineer perspective. Zachman uses such terms as ‘technology entity’ to describe the artefacts created in the models.
- The bottom two levels concern increasingly technical perspectives and specification.
An enterprise architecture can help form a bridge between the business and IT, between CEO and CIO. It looks to future capability specifying where the business wants to be, what it wants to be doing and how it will be structured to achieve this. Even if a business analyst is not involved with senior and executive management at the strategic level, they should thoroughly understand the strategic ambitions of the organisation. Architecture further demonstrates how IT will support the organisation’s vision.
The enterprise architecture can help to align the strategies of the various organisation units to ensure that everyone is aligned to achieving the corporate goals; everyone should know where their part fits in the overall scheme. Critical success factors (CSFs) and Key Performance Indicators (KPIs) can be defined and translated into measurable objectives for business units and individuals. Trying to obtain this level of unity on a particular project can be one of the most challenging jobs for a business analyst.
