Contenu connexe
Similaire à IIBA Multimodels
Similaire à IIBA Multimodels (20)
Plus de IIBA UK Chapter (20)
IIBA Multimodels
- 1. BA Core Skills - Overview & Intro
© Ability Engineering 2007 Page 1 of 26
- 2. BA Core Skills - Overview & Intro
© Ability Engineering 2007 Page 2 of 26
- 3. BA Core Skills - Overview & Intro
Imagine a typical business project which a BA may get called into.
The departments involved have a process, but only sort-of, and nobody really sticks to it.
Also, each different group within the department has their own set of tools & techniques for getting the
job done, and their own private stores of knowledge.
Mostly, they are using MS Word and Excel, with a bit of MS Project thrown in occasionally. Mapping
the interactions between the teams is a challenge: it’s mostly done via emails and meetings, with some
information kept on a shared drive, but with no clear organisation.
Those who, like me, are contract BAs are now looking forward to many months of lucrative work,
organising the business processes, understanding who produces what, and organising the knowledge of
the team.
Confident that we can significantly improve their business performance.
Except this isn’t a business project: this is an IT department. And the groups are all part of IT. There
are BAs, 6-sigma process modellers, UI and Ux designers and testers.
Sure, we have a process - sort-of. The BAs probably use one tool for requirements management and
another for use cases. The 6-sigma people another for processes.
And the UI designers use something else to create their wireframes. But they take input from the User
experience team, who use PowerPoint for their User Stories. And the testers use another toolset, but it’s
OK, because they get a 1-off email with a spreadsheet of the requirements, and keep their test cases
somewhere else….
And the poor Project Manager tries to make sense of it all with occasional snap-shots from everyone, but
keeps their own list of risks & issues. And the plan lives in MS Project.
And stranger still: this situation hasn’t changed that much in the 20 years that this author has been
involved in large-scale IT projects.
Has anything interesting happened in IT in the last 20 years…..
© Ability Engineering 2007 Page 3 of 26
- 4. BA Core Skills - Overview & Intro
BAs are typically charged with creating a single, coherent set of information about a project. We’ll call
that coherent set of data a ‘model’. Examples of models are Process, Use case, conceptual,
Requirements or User story/Journey.
These models have defined types of information within them, and many books get written about how
they can be created.
This presentation will suggest that just having one model type as the focus of a project means the project
will be limited in what is formally ‘known’ about the project, and that having multiple, linked models
can be hugely beneficial, both to the quality of the focal model, and to the project in general.
Some model types have evolved to capture particular kinds of knowledge. For example, the Business
Process Modelling Notation allows an accurate picture to be created for the processes within an
organisation. It records who does what activities, in what order, and what deliverables are produced and
consumed by each activity.
A great many specialist tools exist, which focus on the capture of individual knowledge types....
© Ability Engineering 2007 Page 4 of 26
- 5. BA Core Skills - Overview & Intro
Even if a project is focussed on one model type – for example, a BPMN Process Model – then there’s
much more knowledge which the project encounters as that model is created. So in a process model, the
BA will discover that some processes use functions of particular software systems, where those
functions might be captured in another form – the use case model for those systems. They may also
capture information about the organisation: not just who does which processes, but how those people fit
into the organisation, and who has what roles within the project.
© Ability Engineering 2007 Page 5 of 26
- 6. BA Core Skills - Overview & Intro
Having a number of different models in a project means we need to start to apply some of our BA skills
to ourselves. If this was a business, we might create a domain/conceptual/data model of what things are
known by the business. For a BP Model, it might look like this.
© Ability Engineering 2007 Page 6 of 26
- 7. BA Core Skills - Overview & Intro
A simple meta-model for Use Cases
© Ability Engineering 2007 Page 7 of 26
- 8. BA Core Skills - Overview & Intro
And another for the domain model of the business.
© Ability Engineering 2007 Page 8 of 26
- 9. BA Core Skills - Overview & Intro
..and there are lots more.
These are particularly important. They are part of the life of most BAs, but rarely make it into a
structured analysis tool. But they are vital to keeping a project moving forward in an organised way.
Knowing who’s doing what, who owns what, what the risks & issues are is just as important knowing
what the requirements & user journeys are.
© Ability Engineering 2007 Page 9 of 26
- 10. BA Core Skills - Overview & Intro
This is the one you’ll have learned on most UML courses: take the nouns from the text of the Use Cases,
and form them into a domain model.
© Ability Engineering 2007 Page 10 of 26
- 11. BA Core Skills - Overview & Intro
A more obscure example, but one which spans two areas which are normally spread across time and
organisation. Those who design a Data Warehouse or MI system to monitor a process, and those who
design the process in the first place may work in very different ways, but the ‘Business Event’ is a
shared idea.
So, link the Business Event from the Process world with the ‘fact’ in a fact/dimension model which the
data people use.
© Ability Engineering 2007 Page 11 of 26
- 12. BA Core Skills - Overview & Intro
A more down-to-earth example.
Most projects have loads of lists & spreadsheets of risks and issues, notes of meetings and actions, so
why not hook them up to the requirements/analysis/design artefacts which they refer to? This makes
reporting on them more informative: Risks know what ‘thing’ (requirement/use case/component ) is
causing the risk, and those elements know that there is a risk associated with them.
Simple stuff, but powerfull.
© Ability Engineering 2007 Page 12 of 26
- 13. BA Core Skills - Overview & Intro
But these models are all part of a larger picture. Together, then represent a rich picture of what we can
know about a project, from many points of view.
BUT, only if we choose to link the meta-models together.
So we might say that, for example, we may link
• RISK to a DOMAIN MODEL CLASS, to indicate that there’s a problem
• STAKEHOLDER to an ACTIVITY to indicate that the person OWNS the activity
• ACTION to a USE CASE, to remember that there’s an action arising from a review meeting which
we need to do concerning that use case.
• ACTIVITY to USE CASES, so show that the process activity needs to use that use case
© Ability Engineering 2007 Page 13 of 26
- 14. BA Core Skills - Overview & Intro
This is a fragment of a metamodel from a recent telecoms project.
The key item here is the Product Feature. This was the way that the product manager spoke about what
the solution did, and what the scope should be – always in terms of this- or that- feature.
So we made Feature the focus of the analysis.
Each product feature had a number of Use Cases: usually in two kinds: some where the user was USING
the feature, and some more where they were setting-up or administering the feature (this detail not
shown).
We tried to express as much as possible of the function of each feature into Use Cases, but there were
still some aspects which needed declarative requirements. A special type of requirement was the non-
functionals, attached to each Use Case, which specified the performance, frequency and volume
requirements for each use case – really useful for the designers downstream.
Unusually for this project, we also reverse-engineered some existing parts of the administration users
interface, to discover the Feature Settings. We made sure each setting got used in a use case somewhere,
and each action on the UI was a step in a use case.
Finally, we captured the Risk & Issues in the model, and linked those to any of the other items (links not
shown for clarity).
Also, we captured which product release each use case, requirement and feature setting was
implemented (links also not shown).
© Ability Engineering 2007 Page 14 of 26
- 15. BA Core Skills - Overview & Intro
This represents WAY too much information to manage manually – this is what computers are for.
So, get yourself some kind of tool, to which everyone can contribute knowledge, and from which
everyone can pull information, and whatever format they want: reports, spreadsheets, documents,
diagrams.
And find/write some standards about what knowledge belongs where (your own meta-model) and stick
to it.
© Ability Engineering 2007 Page 15 of 26
- 16. BA Core Skills - Overview & Intro
© Ability Engineering 2007 Page 16 of 26
- 17. BA Core Skills - Overview & Intro
© Ability Engineering 2007 Page 17 of 26