Business analysis for business agility
Business agility is the ability to rapidly but safely change in response to or in anticipation of changes in the external environment. Organisations can ensure that their business analysis activity is targeted on achieving business agility.
Potential drivers for change are summarised in the acronym, ‘PESTLE’.
- Political
- Economic
- Social
- Technological
- Legal
- Environmental
Business agility is becoming increasingly important in a world where the rate of change and the competition for customers and resources is accelerating.
The agile business analyst is an agent of change. As such, they can help the business to respond to change in a timely and advantageous manner.
The 3 + 1 elements to optimise business analysis for business agility are,
- Business processes
- Data analytics
- Business rules
and person to person communication.
A framework for managing change
Framework for an enterprise architecture
An enterprise architecture is, among other things, a tool that can help to map business change to technical responses and technical advances to business opportunities.
The accompanying diagram, based on Zachman’s framework for an enterprise architecture, highlights six concerns or aspects (my words, not Zachman’s) of an organisation that can be described, modelled and specified at various levels of abstraction, from idea to reality.
The dividing line between the top and bottom three rows was not taken from the Zachman model, but reflects a possibly arbitrary and personal division between:
- Rows that are populated with artifacts created mainly by business oriented roles such as business analyst and business architect.
- Rows that are populated with artifacts created mainly by more technical roles such as solution architect, designer, systems integrator and developer. This is why, in the accompanying diagram, we refer to the lower three rows as ‘technical views’. We accept that not everyone would make such a classification.
The intent of the following paragraphs is not to describe the Zachman framework in detail; he does a great job of doing that himself. See Zachman framework and The rows – what are they?
The intent is to highlight aspects and views (perspectives) that are immediately relevant to the work of a typical business analyst or business architect. And the intent is also to show how the analyst can use the Zachman model to help their organisation achieve greater business agility.
The columns of the Zachman model
The six ‘concerns’, referred to above, are shown as the column headings of the grid. Collectively, these concerns describe a ‘system’.
The business analyst needs to understand an enterprise in terms of these six concerns. The analyst should understand the concerns in their own right and in terms of their relationships with each of the other concerns.
We can consider the columns as areas where the business analyst needs to demonstrate their capability.
The rows of the Zachman model
For each of these concerns, we have six views or ‘perspectives’ these are the rows of the grid.
Going ‘down’ the rows takes us from idea, at the top, to reality, at the bottom. Going from row to row affects a series of ‘transformations’ of the original idea, progressively turning that idea into reality.
The top three rows show business oriented views:
- Identification and naming of relevant aspects (Contextual view).
- Descriptions and business (conceptual) models of the aspects; (Conceptual view).
- Logical models of the aspects (Logical view).
The artifacts (or artefacts) that populate these top three rows are typically created by people with role titles such as business analyst or business architect. These artifacts are abstractions of the real world.
The abstractions, or representations, created by the business analysts and architects are turned into reality in a further series of three ‘transformations’ by people with roles such as solution architect and developer. These are the bottom three rows of the grid.
The bottom three rows are populated with technically oriented models and other artifacts. These describe the ‘technical systems’ and tools that support the business systems.
The final transformation (the ‘bottom’ row) creates (instantiates) the thing itself, i.e. the organisation or enterprise.
Zachman not a methodology or a decomposition
Zachman insists that his model is not a methodology. However, organisations can create methodologies that reflect an understanding of the model.
Zachman also insists that the rows do not show increasing levels of detail. However, the models and other artifacts associated with each row will probably demonstrate additional details as each successive row gets closer to the real thing. If using the Unified Modeling Language (UML), for example, the models in the lower rows will feature additional icons and ‘adornments’.
Deriving an architecture and methodology from Zachman
In building the enterprise architecture itself, and in creating methodologies that reflect the Zachman model, it can be useful to think in terms of additional levels of detail.
Zachman states that the rows on his model should not be thought of as levels in a hierarchy; each row provides a different view of the same thing.
The higher the row, the more abstract are the associated models. Not everyone thinks at very abstract levels.
The models in the descending rows introduce additional artifacts, which might be considered as adding complexity. Interpreting these models generally relies on special training.
The ‘layered’ approach supports understanding by hiding details from people for whom they are not relevant and who perhaps would not understand them, due to lack of training.
By understanding each column as an entity and as a contributor to a system, and by being aware of how each layer is supported by the layer below it, we will be better able to propose and manage changes to an organisation’s systems efficiently and effectively. We need to do this in order to continuously support strategic objectives and realise game changing opportunities in rapidly changing business environments.
In other words, we have a tool to boost our business agility.
Three plus One
We will focus on 3+1 areas of capability that are critical to successful business analysis and business agility:
1. Business processes – The HOW on Zachman
2. Business data – The WHAT on Zachman
3. Business rules – Impact all columns on Zachman
Plus
People (Inter-personal) skills – Relates to the WHO in Zachman
Business Processes (The ‘How’ on Zachman)
Organisations must continually improve their ability to align themselves and their processes with the changing external environment and to rapidly adapt their responses to business events. This is a major factor in the achievement of business agility.
Many, if not most, of an organisation’s processes provide routine support. But some, perhaps a critical minority, are strategically important and deliver the value created by the organisation. Crucially, the goals of these processes directly support the goals of the organisation.
Read more on business processes.
Business Data (The ‘What’ on Zachman)
Process transparency is key to boosting business agility. Data is key to achieving that transparency.
The essential data of the organisation are the concepts on which the organisation is built. Such concepts include Customer, Supplier, Product or Service, and the various artefacts associated with business transactions such as orders, payments and receipts.
The ‘conceptual view’ (row 2) of the Zachman framework contains models of the (data) concepts.
As well as the concepts themselves, it is vital to understand the associations between the concepts; these are captured as business rules.
Business Rules (Affect all columns on Zachman)
Also key to boosting business agility is mastery of the business rules.
Business rules must be visible and be owned by the business. As with processes, rules must be continually aligned with the changing external environment. Rules are incorporated into the processes and the data.
People (Inter-personal) Skills
Business analysis is a people oriented job. Business analysts enjoy working with people, with all the attendant challenges.
Obviously, to do the job of business analyst, a person needs empathy. They need to be able to listen. Those ‘skills’ are perhaps a part of a person’s nature. But there are many skills that can be learned. We refer to such skills as ‘people skills’ or ‘interpersonal skills’.
Essentially, people skills are to do with communication. We may also refer to people skills as communication skills.
Specific people skills include:
- Making presentations
- Facilitation
- Chairing meetings
- Interviewing
- Negotiation
- Report writing
- Team leading and leadership
The business analyst can also usefully learn some of the skills of the sales and marketing team, e.g.
- Understanding the difference between features and benefits
- Understanding people’s ‘pain points’
- Achieving a win – win situation
- Motivation
Implementing Three Plus One
A great way of implementing 3 + 1 is through the creation of a business analysis centre of excellence.
