Modelling the business problem: Business Context and the argument for free diagrams

Having recently undergone a peer review, just before Christmas - this topic is sitting right at the top of my mind at the moment.

I wrote a business requirements document ( although in this particular company it's called a Customer Requirements Specification - due to the fact that the system teams can service other system teams as well as business areas.) In my opinion , the name of the document is far less important that it's contents, and I see no conceptual conflicts with referring to your client area as 'the business'. In practise , and for all intents and purposes , even if you are not directly interacting with an Operations Business Area , you are servicing your business clients, be they  another system area that requires a service from you , or a business ops area that requires new functionality or a new process.

One of the areas that I was questioned on was my choice of diagrams, and the contents thereof. I must be honest , I had an absolute ball researching the things I wasn't sure of , and making mental notes to update my definitions and internal frame of reference, but the one point I found myself sticking on was that fuzzy grey area around modelling the business context.

I ended up using "use case" notation - and I use quotation marks deliberatley as I am still not too happy with the end result which included about 3 comment boxes detailing the problems.

I found this method on another blog : The BA Times: The Business Context Model; As Good as it Gets.

It's a very useful way to describe the problem to the business , and to the architects, system team members, and while I have no real issues with the method - I am still very cautious about it's usefulness in a document where the business problem is already described in detail both in the introduction and in the tabulated list of stated needs.

In my experience, and strictly talking in terms of the business stakeholders and users that I have dealt with, they are far more comfortable with pictures that are not UML, and short bullet points to describe the needs they have.

To contrast the UML method with the diagrams that I prefer to produce for the business sign off - I have produced two diagrams , using generic terms like : The Business Problem , and Area of Interest.

This is the first one :

And this is how I would model the same problem:

The purists among you will note and probably froth at the mouth that this is not a workflow standard diagram , neither is it proper UML, or BPMN. And yes - you would be wholly correct.

My response is this  - for the purposes of getting your head around what the business problem is , and the points along the way in the high level business process that are hot spots and points of contention, this diagram is far more useful than the first one .

Note - I am not saying that the first diagram is not useful, and I am not saying that mine is better . I am saying that given the environment that I have my experience in , and the users that I have dealt with thus far , the second diagram lends itself more to being presented to the type of business users that are not interested in learning what all the funny pictures mean in BPMN, or UML. You really do need to explain less about the second diagram, and it will prompt more questions than the first.

And questions are good. If they are asking questions , it means they are thinking about how you have described their problem , and deciding if you really understand it. A 45 minute meeting going over and over how you have described their issues is infinitely better that walking into a room , having the users take one look at your use case , tell you it's fine and walk out.

There are people ( and the author of the blog I have referenced appears to be one of them ) who will claim that Use Cases are simple and easy for users understand. And they are mostly right on that point. Use Case Diagrams are a very succinct way of placing a process , or set of "uses" from the business in context.

They also however - miss out critical details about what's wrong with the current process , and what the business's stated needs and problems are. Which is why I do not like them for anything except the finest grained of system and business process definitions in a functional requirements document.

I am a stickler for doing things the right way - but I am even more of a stickler for being efficient and getting people to understand. Understanding , agreement , consensus , and coming to the same mental picture of that damn swing that we all know so well are far far more important than producing pretty little standards-compliant diagrams that no-one but you and your fellow BA council members can understand.

by Stephanie

IT BA and BA : what's the difference ?

OK Cherubs , here's a thought. Debate rages all around about BA's and what is a BA exactly . While we have been blessed with the thorough and extensive work in the Business Analysis Body of Knowledge® (BABOK ®), and the rising star of the International Institute of Business Analysis IIBA®and its various local chapters, there is still a lot of debate around whether a  BA focussed on Business processes only – also sometimes called a Business BA ( don't you love the redundancy in that term ? A Business Business Analyst, what a mouthful!), and an IT BA need the same skills necessarily, and what those skills should be.

Chief among the sticking points is calling an IT BA by another name, such as a Systems Analyst. The BABOK®  is clear in its definitions , anyone who does anything that is remotely considered under the auspices of the work of a BA , is considered to be working in the realm of BA'dom. This includes (but is not limited to ) System Analysts and Process Analysts, as well as Project Managers.
This article however will focus on something that I find to be a very contentious issue, hotly debated amongst my previous and current colleagues. If we are going to make a distinction between a BA , and an IT BA, then which do we need on a technology project , and why should the IT BA do the business requirements at all?
I’ll start by listing what I see as the main differences between a BA and an IT BA.
In general all BA’s should be able to:
·        Analyse and document business processes.
·        Conduct Stakeholder analysis
·        Elicit, identify, analyse and decompose business problems.
·        Produce from this analysis a Business Case.
·        Refine the business problems into a set of Business Requirements
·        Propose and document a solution for the business problems which can consist of any one,  or a combination of the following within the business requirements document / specification:
o   TO-BE Business Process
o   Business context diagrams
o   Business conceptual Domain Models
·        Elicit , identify , analyse and decompose Solution Requirements.

see also Requirements Analysis  for some background and a more information

All of the above does not require the Solution to include any technological aspects.

It is when a technology solution is required that we see the rise of what is more commonly being referred to as the IT BA .
An IT BA should further be able to ( in my opinion):

o   Elicit, identify, analyse and decompose Solution Requirements that consist of

  1.      Functional Requirements
  2.      Non-Functional Requirements

The IT BA therefore, it is presumed and assumed should have some background in technology. Many graduates with IT focussed degrees , become junior developers , moving through the systems analyst role, and eventually taking on the role of IT BA. This is not always the case however, IT BA's, and BA's come from many different backgrounds.

Further to that - in my opinion, the IT BA  should also be able to hold their ground , and have substantial input into the architecture of any solutions. As the person who understands ( hopefully!) the business problems and needs more so than any other project member, they must be able to discuss and debate the merits of various approaches with the project Architect, and Developers. It does not matter how fabulous they are at documenting anything, because people are uniquely shaded by their own perspectives. An Architect will have a leaning towards their own personal preferences in technology and platforms, developers will present solutions that fit within their preferred languages, and it takes a strong person to ask the questions regarding the 'fit' of the technology design onto the solution requirements and back to business requirements. Which is in itself a constant process of re-evaluation throughout the project. Don't hesitate to ask those questions of yourself and others , even when you think you have everything nailed down.
 
There is in my view a  distinct separation of a BA role and an IT BA role , and the outputs they should produce in a project cycle. In an organisation where the roles are distinct and occupied by different people , the BA will do the analysis of the project up to the point where the business requirements are documented and signed off, and will hand over  at that point to the IT BA.
This is where, things start to go pear-shaped. And where many good people lose the plot, so to speak.
In theory - at each stage of a development cycle, the previous role player hands over perfectly executed , exquisitely documented  outputs. There is,  in an ideal world, no shades of grey, when the BA hands over the business case or business requirements to the IT BA, they are getting the best possible representation of the business needs , without exception.
The reality is however that projects start late, they are delayed and impacted  by people who are sick, people have sick children/dogs/parents/spouses. They have car accidents and flat tyres. Key stakeholders miss meetings , or are not identified. Strong willed business stakeholders hijack meetings to push their own agenda's.  Any number of things can go wrong , or be missed in the first stage of requirements elicitation. And when the project is high profile, and impacts the business deeply and badly , there is constant pressure to deliver things quickly rather than properly.
Yes - the IT BA will be given the best possible document that the BA can produce, but it will be subject to any number of negative factors. The IT BA must therefore operate under the assumption that the requirements need to be managed , and QA'd. Even updated , added to , or in some cases scrapped entirely and replaced.
This begs the question - why even bother with the split approach anyway? Surely it would be better to just have the IT BA do everything ? That way , they would be able to make sure they do the best they can do , and at the very least , even if they do a bad job documenting the business needs , they'll understand them , and be able to make a brilliant solution anyway?
I think not. I think that both the BA role and the IT BA  role should be involved in all parts of the project from the start to the end. Buddy Buddy works. And it works well when the BA's on the project collaborate effort skills and knowledge.

The roles and responsibilities stay the same , but the collaboration of the two uniquely positioned viewpoints means that the processes , the analysis , the outputs and the resulting requirements definitions are, within the constraints of the project , the best they can be.

This does not mean necessarily that there will be two people working on the project. In organisations with resource constraints, or where there is no distinction between BA's and IT BA's , there will often be only one BA assigned to a project.

It is these projects where the BA's ability to don different hats becomes critical. If this is you , you must be able to do the BA work as a BA, focus on the Business definitions , concepts , problems and terms. Talk about the solution in terms of what the business will want to achieve.  You should then effortlessly be able to step out of that role , and converse technically with the relevant development team as an IT BA regarding the mapping of those business requirements into functional requirements and solution architecture, while maintaining in the back of your mind anything that might impinge on the business needs.

Globally the role of the BA is becoming more recognised as a profession in it's own merit , and as this thinking gains ground, it becomes ever more critical that BA's step up to the challenge of delivering on that expectation. This means we all need to be able to play different roles, BA, IT BA, technical advisor, systems process analyst, process designer. User Champion.

Yes - User Champion. If that role has not been represented correctly on your project ( a senior VP Exec is NOT a user champion. ) then you need to take on that responsibility , at least to the extent of owning the Functional Requirements and relating them back to an actual business need.

Don't know what a User Champion is  ? Check out below for some interesting reading :

http://www.frontend.com/design/the-user-champion.html
http://tc.eserver.org/19312.html

A BA is not someone who takes notes and writes down what the users want. A BA questions , probes , elicits information , and gathers details. All of this for the purpose of creating a unified view of the problem , it's solution and the road map to get there. In order to accomplish this they will need to play various roles, produce several artefact's and acquire and hone many skills, all of which combine to produce a uniquely skilled individual. An individual who is capable of filling those messy inconvenient gaping holes between Project Managers , Users , Architects, Developers , Business Management, Development managers and  Executive Stakeholders.

If you're up to the challenge , it can be one of the most stimulating environments to work in. Nothing can ever be the same , and therefore everything changes , all the time.

A last word of advice : If you don't like your cheese moved, don't become a BA.

IIBA®, the IIBA® logo, BABOK®  and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis.

by Stephanie