The Business Context Model; As Good as it Gets

The Greek philosopher Socrates said “In the world of knowledge the idea of the good appears last of all, and is seen only with effort”. This article proposes that as business analysts we must have the audacity to seek out the good of a project using thought and effort to find the real business goals early on.

A business context model needs to express the current business problem and to propose the goodness and scope of a project.

I vividly recall after one particular business context modelling workshop, a senior business manager at a government agency said to me “if only we had started project x in this way, we would have reached agreement about what we were trying to do so much faster.” I have received positive feedback from stakeholders in multiple projects and also from other business analysts who see this technique as a useful tool to engage the business and to orient themselves in the program of work.

The business context model should identify the actors (people, organisations, systems) who play a significant role in the business process or in the business domain, and the business areas of interest relevant to the scope of the work and potential change which may require exploration and further analysis.

At this early point in the project we are business modelling at a very high-level in a fairly imprecise way i.e. taking a helicopter view of the business. We should not model detail such as inputs, outputs, business rules, attributes, operations, or states. We are simply trying to set the scene. By doing this graphically, we gain all the usual benefits of modelling, not least using the business context model as a vehicle for merging differing business viewpoints quickly, and for asking the right questions.

We may start more detailed analysis alongside our context modelling depending on our style of modelling. We may create a snapshot context model to kick-start our project, or we may continue to correct the context models through the project, again, depending on need or style.

I have seen all manner of “context” diagrams – current state, future state, environment diagrams, system diagrams, network diagrams, communication diagrams, business process diagrams, relationship maps, organisation charts, etc. Most of these use inconsistent notation within the diagrams themselves and, more significantly, do not set the scene for a newcomer. They are usually meaningless and business illiterate. Putting business context modelling “in context”, we need a snapshot of the business and its problem and another of its intention.

How do we start modelling context? After gathering the business customers in a room, the end customer is the first thing I draw on the whiteboard. Otherwise I am unable to ask meaningful questions about the problem or to begin the task of analysis. Then we need to discuss the problem and draw it; this represents the current state only and the reason for initiating the piece of work. The example below represents the current problem with importing and exporting goods in some countries.

 

For readers not familiar with the Unified Modelling Language (UML), a package indicates an area of interest. A stick man represents any actor in the business domain – a person, an organisation (which in turn represents its customer facing channel such as a website or business-to-business gateway), or a system. I prefer to show a system as a stick man because I need to remember, as a business analyst, that it is playing a part i.e. it is an actor in the business process, performing some of the business activities. I am not in the business of drawing a map of the organisation’s systems but of focusing on the business activity and business logic. It is also worth bearing in mind that when modelling context, we are not yet trying to elicit software requirements.

I use the UML notation for context modelling because the modelling language is consistent with other model artefacts, such as a business domain model (please see my article, The Importance of Business Domain Modelling in the November 1/08 Business Analyst Times). It is understood worldwide and by audiences outside the current piece of work, for example, another business analyst on another project, and I can reuse or trace to elements already created.

I have always had positive feedback from my business customers while using the UML notation. Moreover, they have always understood what we have created together in the UML. There is no perception that I am using “IT speak”. In workshops, I talk about the business objects that we are interested in and only briefly mention, as we go along, the four or five simple symbols that I will introduce that day. I can only say that, as a business modeller and analyst, it is so much better, so much easier, so much quicker and so much fun compared to all the other techniques I have tried and used over the years.

The following business context model expresses how to “make good” the import / export problem expressed above. The scope of the project is indicated by the boundary box. I have named the new package as “new bunch of stuff” to highlight that we need to think carefully about a new name. We can include important statements such as business objectives – they may be sourced from a project brief, from some statements made and clarified in the context modelling workshop, or from any other source such as a staff communication from the Chief Executive.

 

Critical to the business modelling activity is traceability, from our solution defined elements, such as a use case, to the original business statements, such as business outcomes, objectives, benefits or scope statements, which the project activity is addressing. By including significant project statements in our model we begin immediately to create traceability and business engagement to clarify meaning.

Spending an hour or two in workshop with our business customers at this stage will save hours of revisiting these discussions amongst individuals. The workshop might be intense and hard going but it sets us up well for a smoother run when we begin modelling proper.

Replicating the model in a good modelling tool to formalise what was agreed in the workshop takes very little time and is simply a rubber stamp exercise, while of course having the enormous benefit of being straightforward, explicit and not open to individual interpretations and agendas. As an aside, in this example the scope context model took less time to create than the problem context model because I reused the model elements already created.

We can introduce other model elements for clarity. In this new example, the following context model expressing scope includes a package that contains a particular service offering (as an object) as a scope statement. We might also add primary information flows such as “customer order”. Of course, by moving the boundary box we can easily express the scope of another project.

 

A package in the UML can be used as a way of breaking up the mass of business complexity into manageable chunks; I use them to indicate a business area of interest. It is for each business analyst to judge just how these are cut, however it is important to name the packages in the same way that the business customers think of them. The general guideline is to use the package to contain a “bunch of stuff”. Hence, collective nouns are good words to use e.g. xyz management, family.  I have named packages as departments, areas of functionality that align with an industry pattern e.g. sales order management, or again, simply a ‘bunch of stuff’ e.g. border security.

If we put effort into seeing the good in a business or in a project we can easily set ourselves up well for further analysis and full traceability to the original business need, saving us so much time later. Each area of interest could be the basis for some business process relevant to the piece of work. The package name may become a swimlane of activity in the first cut of our business process, alongside swimlanes for each actor identified in the context model, if appropriate. The packages within our boundary box will contain the business logic, rules and use cases to support the business activities and interactions in scope. One of our goals as modellers is to give ourselves maximum opportunity to reuse model elements already created.

We can use context modelling for anything important we wish to think about, perhaps even for making family plans or for helping us to think through strategic decisions and commitments, and regulatory requirements. Below is an incomplete example that I baked earlier about reaching fulfilment in all aspects of life.

 

The packages, actors and associations have been depicted in this way to allow analysis to take place, the results of which may relate directly to elements in the context model. We are aiming to reduce our workload and reuse work already done. Using a good modelling tool, not a drawing tool, allows us to do this provided the notation is consistent and is used correctly, i.e. we do not deviate from the standard UML to Pidgin UML. After all, we do not use Pidgin English if clarity is the order of the day in our written material.

If we are honest with ourselves and listen to the problem statements made by our project managers (“it takes too long”), our solution architects (“the requirements are not clear or consistent with one another”) and our business customers (“I don’t have the time to review so much written work or indeed the time to wait for it.”), we would stop writing and spend only the time it takes to clarify a few significant verbal statements as a baseline for traceability purposes, and invest in the intellectual activity required to model the business. We must use our time asking all the right questions, listening carefully to the answers, capturing and structuring the knowledge gathered as clearly and as explicitly as possible, using a formal notation such as the UML.

As Jim and Michele McCarthy say in their book Dynamics of Software Development, which provides us with rules for delivering great software on time, “the real task of software development management is to marshal as much intellect as possible …” If such investment is made in the early stages of a project, the business analyst can capture the essence of a business vision, the goodness of a project and then focus on channelling the business intellectual property (IP) into the subsequent business analysis artefacts.

Modelling the business context is not a mechanical assembly line task to map some of the things that already exist in the organisation. It is an intellectual activity that requires the business analyst to elicit the business problem and to visualise with the business how to make good that problem.

In a future article, we will look at modelling the business process and the rules that govern the activities it comprises.

This article is based on one of the “Truth, Beauty & Goodness” presentation series given by the author in 2008 in Wellington, New Zealand. The author wishes to express her thanks to the following people for their thoughts and ideas freely contributed to this article: LD, BL, JM, HT.

Copyright © Suzanne Jane Maxted, November 2008.

 

---

Suzanne Jane Maxted is a Certified IT Professional Member of the British Computer Society. She gained a Bachelor of Honours degree from the University of Sussex, England, in Mathematics & Statistics with European Studies (French). Suzanne is a business analyst with 16 years experience from around the world. She is an accomplished workshop facilitator and presenter in the business analysis space and has given presentations to senior Member State representatives at the European Commission and at the United Nations, among others. She takes pride in applying logic and order to differing business viewpoints and in communicating common understanding. Suzanne teaches ballet to 3-8 year olds on Saturday mornings and fills her spare time dancing and having fun with her two little children. Suzanne can be reached at [email protected] or [email protected]