What is a use case? – Free training for BAs
About the course
‘What is a use case?’ is a mini course in our new series, ‘Free training for business analysts’.Access the course
What is a use case? – Click to viewBuild a business analysis centre of excellence
Getting started
This article considers things to consider when you build a business analysis centre of excellence.
Governance and Management in Business Analysis
Effective governance and management is central to the development of a business analysis centre of excellence.
Business analysts should be familiar with:
- Governance frameworks such as Val IT and Cobit
- Principles of portfolio, programme and project management
- Principles of risk management, business case production and benefits realisation
Planning the Business Analysis Centre of Excellence
- Create a vision and high level goals for the centre based on support for the organisation’s strategic objectives
- Create qualified, quantified and prioritised objectives as landmarks on the plan for the iterative development of the centre
- Integrate the plan with current and proposed change initiatives and IT interventions
Techniques for Business Analysis
Relevant techniques for business analysis include:
- Process improvement
- Business data analysis
- Business rules management
- Business case production and benefits management
- Risk analysis
- Communication skills
Projects – Business Analyst Participation
Project participation overlaps with all the other areas in the above model of a business analysis centre of excellence.
Each of the areas our model will be refined on the basis of project experience.
Change – Role of the Business Analyst
Change management is at the heart of a business analysis centre of excellence. It overlaps all the other areas in our model.
Business Analysis Relationships
Relationships include the structure of the business analysis organisation as well as its relationship to other organisation units within IT, the business units and with external suppliers.
- Relationships with business units may be orchestrated though the IT Director / CIO
- As well as relationships with operational business units, ensure that there are effective relationships in place with Finance, Human Resources, Legal, Sales and Marketing
- Vital relationships with IT include IT strategy, Testing, Architecture and Design, Programming, Release Management, Programme and project Management, Technical Infrastructure and Support
Boost business agility with Three + One
Business agility
Business agility is the ability to rapidly but safely change in response to or in anticipation of changes in the external environment.
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.
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 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 the 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 effects 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.
The layered approach supports understanding by hiding complexity from any stakeholder that doesn’t need to see it.
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
In a related article, we also describe, ‘Agile business analysis‘.
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 (The ‘Why’ 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.
See also this post on 14 steps to business agility.
Video – ‘Basics of data modelling – Part 1’
Introduction.
This video introduces the basics of data modelling. Data modelling is fundamental to creating a business level data architecture.
Duration: 8 minutes. See also, ‘Summary of the video content’, below.
Summary of the video content.
The video is based on a scenario concerning insurance policies and the customers who buy them.
The business view is of course highly simplified; we are trying to explain data modelling, not the business of insurance.
Two classes are identified, Customer and Policy. These represent actual customers and policies.
A class is a sort of blue print that defines the company’s concepts such as their concept of a customer and a policy. The concept identifies the attributes, or data items, for each concept.
The concept of a customer includes attributes such as:
- Customer name.
- Status.
- Post code.
The concept of a policy includes attributes such as:
- Policy number.
- Policy type.
- Purchase date.
- Price.
Data modelling at the business level is sometimes described as concept modelling. The model itself is described as a conceptual model.
There is an association between the two classes which is labelled, ‘owns’. I.E., ‘One customer owns or more policies’.
The associations capture business rules, such as the rule that to be a customer of this company, it is necessary to have purchased at least one policy.
Another business rule states that a policy must be owned by at least one customer but may be owned by many customers.
Notes on the model.
These notes refer to terms in the Zachman framework such as the distinction between the conceptual and the logical views.
As mentioned, the video describes a conceptual business level model, not a ‘normalised’ logical model. A logical level data model shows such adornments such as ‘foreign keys’.
This introductory video does not describe how to resolve the so called ‘many to many’ associations. This is often more relevant to the logical level view. Arguably the logical level is more relevant to the solution architect than the business analyst or architect, although of course the same person may take on all of these roles.
The notation used in the video is a simple form of UML.
Many analysts consider that UML is too technical and complex to be used for business modelling. This is not correct if UML is used appropriately.
In common with most modelling notations, UML comprises mainly rectangles and lines. It also has other, so called, ‘adornments‘.
UML refers to artefacts such as attributes and various graphic devices as ‘adornments’. It provides a range of adornments relevant to different stages of a projects, e.g. requirements discovery, design, implementation, etc.
Use only adornments that are relevant to a particular stage. And obviously, only use adornments that you and your stakeholders understand. Just because something is available in the UML, it doesn’t have to be used.
We provide an overview of data modelling in our e-training course, ‘Introduction to business change’.
Online training for business analysts – Video overview
We have released two online training course in a series for business analysts who wish to self study for recognised qualifications.
The series is called, Guide to Success.
The courses published so far are:
- Introduction to Modelling Business Processes. This supports syllabi 3.3 and 5.0 for the BCS Certificate in Modelling Business Processes.
- Introduction to Business Change. This supports the syllabus for the BCS Foundation Certificate in Business Change.
This video concerns the course, ‘Introduction to Modelling Business Processes’.
Requirements – What’s the problem?
The definition of requirements in terms of solving problems and satisfying objectives, originally specified by the IEEE, is now widely used.
It is referenced by both the IIBA and the BCS international Diploma in Business Analysis. It is the definition that we often refer to at Capiro.
In this article for the IREB Requirements Engineering newsletter. September 2017, the authors examine this definition and some of its implications.
The IEEE definition of a requirement is probably not perfect – What is? But it does highlight that solutions cannot be defined in a vacuum – they need context. That context is the problem that needs to be solved or the objective that needs to be realised; problems stand in the way of the achievement of objectives.
The article emphasises the importance of looking at the big picture. Problems and objectives (goals) tend to be related to other problems and objectives. Proposed solutions will each demonstrate varying degrees of support for the achievement of corporate (strategic) objectives. Stakeholders will have differing opinions as to what constitutes a problem, a goal or a solution. Any one solution will have implications in terms of risks, costs, benefits, stakeholder support, implementation challenges and operational characteristics.
The authors invite comments on their article.
Please note that the IREB newsletter is free and that you can sign up with IREB to receive it regularly.
Communication skills get you talked about
Communication and interpersonal skills are the secret sauce of the most successful business analysts and business architects. And the further these professionals go in their careers, the more important these ‘soft skills’ become.
We have included two articles by the same author on communication skills.
The first covers interpersonal skills in general and provides a ‘top 10’ list of relevant communication skills. Interestingly, the list starts with ‘listening’ as a communication skill. You may be able to think of a few colleagues who could usefully take this one on board. The article also links to another on communication skills for interviews.
The second article is on soft skills for the IT industry. Unsurprisingly, this list includes communication skills and listening skills. It also includes ‘negotiation’ – this has to be one of the most important skills for business analysts and business architects to acquire.
Most of the skills mentioned can be learned. Others such as creativity or flexibility, whilst being desirable characteristics, may be trickier for some analysts.
You may care to score yourself against the suggested skills.
The business agility manifesto
The subject of business agility has been gaining increasing traction over the last few years.
Ever since the presentation of the agile manifesto, which was primarily related to computer programming, the word agile is appearing in ever greater number of contexts. As Bertrand Meyer, in his book, ‘Agile, the Good, the Hype and the Ugly’, asks, “Who wants to say they are not agile?” And as many consultants, trainers and authors can confirm, use of the ‘A’ word is great for driving sales.
Business agility goes beyond software development. It concerns, among other things, the ability of an organisation to continuously and safely adapt itself to changing environments and customer expectations and demands. However, as with agile itself, there are many opinions as to exactly what business agility is. And now we have the Business Agility Manifesto. It offers a checklist to see if your organisation has business agility.
Its authors are Roger Burlton, Ronald Ross and John Zachman. All very well known in their own spheres of business processes, business rules and business architecture respectively. Along with business data, these aspects are critical to achieving business agility. We focus on them, for instance in our Three+One approach.
The authors describe the manifesto as a pathway forward – Into the ‘Knowledge Age’.
Will it trend? See what you think.
Data capture at the speed of thought
Yesterday’s technologies.
One thing that hasn’t evolved that much for the average computer user is how to get what they’re thinking into the computer. Most business analysts probably still think primarily of the old technologies.
We’ve had keyboards forever. And many business analysts spend a significant proportion of their time as an (untrained) typist.
Unless we can ‘touch type’, business analysis activities such as writing up interview notes, reports and business cases tend to be relatively slow and error prone.
We perhaps concentrate on our actions at the expense of the quality of our content. We ought to be able to use our minds more efficiently and more creatively.
Today’s technologies.
Voice input can help, but is problematic in a noisy office.
Various forms of scanner are great for a limited range of jobs.
It would be useful to make business analysis activities more efficient. And as a business analyst, you might want to offer your users something really innovative. Nice idea, but how easy is this in practice?
There have been some great innovations for specific roles such as surgeons who obviously need to work ‘hands free’ of everything except the tools of their jobs. We are getting an insight into what is coming. Which takes us to tomorrow’s technologies.
Tomorrow’s technologies.
How about being able to tell the computer your innermost thoughts without touching anything? An article in Wired magazine takes a look.