1.  Business Analysis Challenges

Getting real involvement from business people on business analysis and business development projects in general is a very real challenge.  Capturing and retaining the attention of those key people, who actually know what the business is really about, competes with a busy day full of priority decisions.  Business people operate in very dynamic situations and need very flexible approaches.

Running a business from day to day clearly needs reliability of processes and results.  But that does not imply that business analysis should (initially) focus on reliability issues.  You cannot deliver reliable results if your understanding of the business concepts is not valid.  Validity is the starting point.  In order to change something, you must understand it.  In most business organizations today there are very optimistic assumptions about the level of understanding of the business concepts among the employees and managers.  Incomplete knowledge is a risk to the reliability of the business operations.

The ultimate sign of success for the business analyst is that the business organization takes ownership of the content of the proposed 'what-if scenarios' that we aim to produce.  This means that what we do should make a lot of sense and should be easily communicated to the busy business people.

I am one of a number of experienced business analysts who think Business Analysis can be done better.  Let me quote Ron Ross and Gladys Lam from their recent book, Building Business Solutions:^[1]

On "What's Really Needed to Align Business and IT":  "So many IT projects end in failure and are simply written off.  Same old story, time and time again.  Why is it so hard? … The answer is simply that business leads are not being properly engaged at the onset in sketching out key elements of a winning business solution.  They're not asking the right questions in the right way of the right people at the right time."

I could not agree more.  The trouble seems to be related to the way we have traditionally performed business analysis.

Change is obviously an end-goal of business development.  I say:  "You cannot change what you do not understand!  Hence, understanding is very important for business development."

Bret Victor (former Apple user interface designer) said in his CUSEC 2012 keynote ("Inventing on Principle"):  "So much of creation is about discovery — and you can't discover anything if you can't see what you are doing."  This means that visualization, including the capability of drawing many sketches, drafts, proposals, and so forth, is of essence.

What it boils down to is how to make sense out of complex contexts.  "Sensemaking" (as a term) has become popular over the last 10 years.  It is basically the process that lies between perception and cognition:  making sense out of what we sense — turning sensory input into meaning.  There are at least a handful of flavours within different fields such as social psychology and cognitive science.  I will use "sensemaking" in a loose sense.

In all business development initiatives, there is a great need for a common model to describe the business concepts in a particular context.  That model must be visual in order to make sense intuitively.

Recently the Object Management Group (OMG) decided to adopt the 'concept terminology' in the forthcoming version 1.1 of the SBVR-standard.^[2]  What this means is that the business-side artifact is now called a 'concept model' (whereas it was previously known as a 'fact model').  Ron Ross has an excellent blog-post about this.^[3]

I have just under 10 years' experience working with 'concept maps' for business analysis.  Concept maps and concept models are roughly on the same level of abstraction.  I am certain that the considerable benefits of business concept mapping will support the SBVR concept model and will make it even easier to get SBVR concept modeling into the value chain of many organizations.

This article explains the whats and whys of the two.

2.  Concept Mapping is about Psychology

Concept mapping comes from learning psychology and has been proven to be a tool equally well used by both business experts and business analysts.

Concept mapping deals with people, language, and meaning, rather than engineering.  Learning from the business what the business is doing and where it wants to go is a people issue.  It involves brainstorming workshops, mapping the language of the business, and getting the meanings right.  What the business is doing — the as-is situation — is typically not well defined (and is fragmented and redundant and ...), and it may need some rework on the fly.  Finding out where the business wants to go is also learning.

Concept mapping is intuitive visual communication and has proven to be highly successful in business analysis.  Conceptual modeling (UML, Entity-Relationship diagrams, etc.) failed as a business-side tool, but concept mapping — coming from educational psychology — is readily accepted in the business communities.  Concept maps communicate extremely well and are fast and easy to produce.

Contrary to common wisdom, business analysis is not "just a documentation issue."  It is a learning process — not only for the analyst but also for the business itself.  Concept mapping works in this context because it is based on psychology (the theory of meaningful learning) rather than on an engineering mindset.  This implies that business concept mapping is a business task, as it rightfully should be.

Let us look at a very simple example, EU-Rent Car Rental.^[4]  The fictitious business of EU-Rent Car Rental is described in the OMG's SBVR document as follows:

EU-Rent rents cars to its customers.  Customers may be individuals or companies.  Different models of car are offered, organized into groups.  All cars in a group are charged at the same rate.  A car may be rented by a booking made in advance or by a 'walk-in' customer on the day of rental.  A rental booking specifies the car group required, the start and end dates/times of the rental and the EU-Rent branch from which the rental is to start.  Optionally, the reservation may specify a one-way rental (in which the car is returned to a branch different from the pick-up branch) and may request a specific car model within the required group.

EU-Rent has a loyalty club.  Customers who join accumulate points that they can use to pay for rentals.  EU-Rent from time to time offers discounts and free upgrades, subject to conditions.

EU-Rent records 'bad experiences' with customers (such as unauthorized late return from rental, or damage to car during rental) and may refuse subsequent rental reservations from such customers.

The text above is pretty clear and well written.  However, experience has shown that concept maps are indeed much more intuitive to read and understand.  Figure 1 represents almost all of the information in the text above:

Figure 1. Overview of the EU-Rent Car Rental Business.

The diagram is a 'concept map'^[5] and it really speaks for itself, which is the whole idea.  (This is sensemaking at work.)  Notice that you can read little sentences like 'Customer issues Booking' and 'Car Group has a Rate' and so forth.  The sentences are visual — they are the connecting lines between the concepts.  Concept maps can be drawn easily in brainstorming-style workshops, and they are easy to maintain, even by non-technical users.  Concept maps were originally designed and developed by Prof.  Joseph Novak (et al) with a learning focus.^[6]

Some things may change (e.g., sales channels), but the core of the business model remains conceptually much the same.

In addition to the concept maps, we need two 'documents':

1. The textual descriptions of the concepts, and
2. The necessary — longer-term — business rules.

Textual descriptions could be along these lines:  "Concept:  Car Movement.  Definition:  planned movement of a rental car of a specified car group from a sending branch to a receiving branch".

In business analysis there is often a need for some 'renovation' complementing the development of new concepts and processes.  We have found inspiration in 'design thinking' (see, e.g., Roger Martin's book, The Design of Business^[7]).  Design thinking is a mindset, which (as the name suggests) promotes the creation of ideas.  Since this is also true for concept mapping, the two techniques work really well together — true synergy in support of making sense for the business people.

Tim Brown, CEO and President of IDEO (a leading design firm), writes in Harvard Business Review:  "...  as economies in the developed world shift from industrial manufacturing to knowledge work and service delivery, innovation's terrain is expanding."^[8]  Over the last few years, more and more business people have accepted the idea of 'design thinking' as an approach to business development. To understand 'design thinking' it is important to understand the differences between 'reliability' and 'validity'.^[9]

Reliability is the traditional business management approach.  Managers are rewarded for providing measurable results (shareholder value and so on).  Investors and shareholders and bonus programs use analytical approaches to determine the reliability of the business.  This is the world of charts of accounts, budgets, forecasts, IT systems, corporate performance management, business intelligence, and — not least — quarterly results.

On the other side of the house, designers are rewarded for validity — for producing things that really are valid (in the market, in the organization, among the customers, employees, etc.).  It is the validity angle that is in focus in design thinking.  'Validity' is meant in the business sense.  If a change or a new thing provides business value (in new ways) it is valid, otherwise it is not. 

Validity comes by design — validity and innovation go together.  Reliability comes from engineering — robust systems, procedures, repeatability and so forth.  Concept mapping provides the necessary level of understanding and makes it easy to communicate "what this is all about."

A nice and easy way to do concept mapping is with the free tool called CmapTools, which is a tested, reliable, publicly-available brainstorming tool.^[10]

Note:  Concept maps are often confused with 'mind maps' and vice-versa.  Mind maps are not concept maps because:

• Mind maps are centric (like a snowflake); concept maps are true graphs (in the mathematical sense).
  
  
• The relationships between concepts are named in concept maps.  Not so in mind maps.  This is very important because the concept map is essentially a collection of little sentences, which individually convey meaning.  That information is not available in mind maps.  Cf. the example above to verify this.

3.  Concept Models

Ron Ross recently published the 4th edition of his book, Business Rule Concepts.^[11]  In it we find this example concept model.

Figure 2.  Sample Concept Model for a Library.

Ron calls this visual syntax ConceptSpeak, and it is a high-level visual abstraction of what can later become a fact model.

The business concept model in Figure 2 looks something like this using classic (Novak-style) concept mapping.

Figure 3.  Sample Concept Map for a Library.

There are some major differences between a concept map and a concept model:

1. The concept map is organized top-down (possibly also left-to-right). The concept model does not have such an emphasis on orientation (as Figure 2 demonstrates).
   
   
2. In the concept map there are only concepts (in the boxes) and 'linking phrases' (the named relationships between concepts). The concept model's concept of 'verb concept' is a linking phrase, but the concept model also has other kinds of relationships between concepts.
   
   
3. There are no visual syntax constructs for "logic" in a concept map — such as you find in fact models.
   
   
4. There are no implicit meanings in the concept map — such as 'fiction' being a category of 'book' as in the Figure 2 concept model.

As described in my book, Design Thinking Business Analysis:  Business Concept Mapping Applied,^[12] I have a business-oriented style of concept map, which makes the example look like this.

Figure 4.  The Library Example in a Business-oriented Style of Concept Map.

The differences to the Novak-style concept map are:

1. A circle denotes a 'business object'.
2. A rounded rectangle denotes a 'property' (of a business object).
3. A sharp rectangle denotes an 'example'.
4. An arrowhead implies a 'many' side of a relationship.  The absence of an arrowhead means a 1:1 relationship.

I call this style "Business Concept Mapping."

4.  How do these compare?

The primary goal of business-side concept models is and must be readability (power of intuitive communication, which enforces sensemaking).  In my opinion, business concept mapping leads the class, with Novak in second place and the concept model in third.

The Novak-style concept map has the least information but is most easy to grasp.  Business concept maps have more information but not quite as much as the concept model.  Business concept maps are a 'light concept model' — and the transition to a concept model proper is easy (almost mechanical).

Business concept mapping is based on educational psychology, and it is first and foremost visual.  It addresses the loosely-defined business reality well.  (There is a lot of gut feeling — aka intuition — out there.)  I like to avoid most of what looks like, or actually is, 'engineering' at the analysis stage.

That is why I like the term 'map' — the business concept map is a map of the business reality.

The concept model is somewhat more formal and complex.  That raises the bar for the acceptance.  However, the complexity is necessary down the line, once you start to construct solutions.  That is why the term 'model' is appropriate.  When to switch from business concept mapping to business concept modeling is a matter of circumstance (and of the audience, in most cases).  Both approaches are based on visual thinking, which is the heart of the matter.

One of the leading thinkers within information modeling, Malcolm D. Chisholm, has stated:^[13]

Conceptual models must capture all business concepts and all relevant relationships.  If instances of things are also part of the business reality, they must be captured too.  Unfortunately, there is no standard methodology and notation to do this.  Conceptual models that communicate business reality effectively require some degree of artistic imagination.

How does this relate to business rules?  The simple "EU-Rent Car Rental" concept map diagram introduced earlier in this article is very high-level indeed; in real life, you end up having multiple diagrams.  But you also end up having a collection of other things, including business rules such as these (from the car rental business context):

1. Each rental has exactly one requested car group.
   
2. The duration of each rental is at most 90 days.
3. Each driver of a rental must be a qualified driver.
4. If the drop-off location of a rental is not the EU-Rent site of the return branch of the rental then the rental incurs a location penalty charge.

If you think about this, some business rules could also be drawn up as concept maps.  (In fact, most can.) However, some of the rules are quite detailed, and some also include 'live data' (e.g., '90 days', or 'SUV', etc.).  You should use concept maps to get the overview and the structure in place, not more.  Later, you can easily transform them to SBVR Concept Models.

There is certainly synergy between concept maps and business rules — very much indeed.  Basically, business rules 'fit into' the concept maps.  From an overall perspective, all those rule statements contain business concepts in their formulations.  Business rules have their basis in defined concept maps.  SBVR is a formidable (technical) vehicle for taking business concept maps into the world of business rules.

You should divide and conquer:

1. Use business concept maps together with textual definitions for most business-level descriptions (no more, no less) — this satisfies the validity requirement.
   
   
2. Use the power of formal logic in business rules technologies only when it adds business value — this satisfies the reliability requirement of the day-to-day operations of the organization.

5.  Results

Business understanding is created via concept mapping.  Then, from the business analysis point of view, the design-thinking people learn from, and are inspired by, that business understanding (expressed as concept maps).  In that way, concept mapping is a prerequisite for the creation of new/changed business concepts (and processes).  Concept maps trigger the ah-ha! moments that design-thinking people get excited by.

Concept mapping is the preferred tool because synthesis is much about writing narratives.  Concept maps are great storytellers!  They are designed for it.  The process of developing concept maps in brainstorming sessions is highly supportive of creating understanding from different angles and perspectives.  The ah-ha's are bound to appear sooner than later.

Drawing concept maps is a learning exercise.  So is reading them and discussing them.  Changing them together in brainstorm sessions creates a very creative environment.  And add to this a lot of new business understanding as well as new opportunities.

Based on my experiences from many projects (since 2004 and ongoing), there is strong confirmation of the applicability of concept mapping to business analysis.  Many of these projects were data warehouse/business-intelligence-oriented business development projects; some of the projects were large analysis and specification projects in the public sector.

From this experience, there is positive confirmation that:

1. Concept maps are indeed intuitively easy for business people to understand, which greatly simplifies and facilitates more agile business analysis activities.
   
   
2. Concept maps are well suited for collective brainstorming sessions (workshops) where the concept maps are being drawn as the discussion goes on — for example, on a computer connected to a data projector.  (IHMC CmapTools was used for this.)
   
   
3. Concept maps can be reviewed, maintained, and enhanced by business people (with some guidance).
   
   
4. Design thinking and concept mapping support each other extremely well.

Client feedback has been overwhelmingly positive.  The business people quickly recognized the added value of concept maps.  The viability of 'meaningful learning' (which is the theoretical background of concept mapping) was solidly confirmed.

Time spent in the early days of the project on business concept mapping proved to be time well spent.  There is actual gain at the end, and the whole of the project is more safe and manageable.  This is because:

• You are certain that the end result is intuitively accessible for business workers.
• You understand the business 100 percent.
• The business learns hidden facts about itself — there are many ah-ha! experiences along the way.

The design-thinking approach used with concept mapping has repeatedly produced valid designs of business information at the level of concepts and relationships.  The acceptance by the business community has been much higher than anything else we have seen.  And the effect of producing more valid business information structures has, of course, been a platform for more reliable business management.

How does this compare to Ron Ross and Gladys Lam's approach (in Building Business Solutions)?  There is a lot of good synergy between the two approaches.  The Business Concept Maps (that my approach produces) will not only strengthen the Business Model and Policy Charter approaches (the BBS approach) in the eyes of the business people, but business concept maps will also serve as a very good forerunner for concept (fact) modeling.  I think there are a number of situations where a lighter, quicker, and easier approach is appropriate.  Concept mapping can then elegantly catch the ball from there, a bit later on.

It is astounding that we have not discovered many years ago that a lot of the analysis efforts are Learning processes (with a capital L).  Sensemaking is of essence.  Think about that — it is probably the key message that you have learned from me.  Thank you — and happy Concept Mapping!

References

[1]  Ronald G. Ross and Gladys S.W. Lam, Building Business Solutions:  Business Analysis with Business Rules, Business Rules Solutions LLC (2011).  www.brsolutions.com/b_building_business_solutions.php  

[2]  OMG, Semantics of Business Vocabulary and Business Rules (SBVR), v1.1, (2013).  [publication pending].  

[3]  Ron Ross, "'Concept Model' vs. 'Fact Model' … Where in the World are the Instances?" at http://bit.ly/156Gsym  

[4]  Based on Annex E of the OMG SBVR (Semantics of Business Vocabulary and Business Rules) standard (www.omg.org/spec/SBVR/1.0/).  ACKNOWLEDGEMENTS:  The EU-Rent case study was developed by Model Systems, Ltd., along with several other organizations, and has been used by many organizations.  

[5]  The technique of concept mapping was developed by Joseph D. Novak and his research team at Cornell University in the 1970s.  

[6]  B.M. Moon, R.R. Hoffman, J.D. Novak, A.J. Canãs, Applied Concept Mapping — Capturing, Analyzing and Organizing Knowledge, CRC Press:  Boca Raton (2011).  

[7]  Roger Martin, The Design of Business, Harvard Business School Press (2009).  

[8]  Tim Brown, "Design Thinking," Harvard Business Review (June 2008).  

[9]  Roger Martin, The Design of Business — Why Design Thinking is the Next Competitive Advantage, Harvard Business Press, Kindle edition (2009).  

[10]  CmapTools™ from IHMC (Institute for Human and Machine Cognition ), http://cmap.ihmc.us/  

[11]  Ronald G. Ross, Business Rule Concepts:  Getting to the Point of Knowledge (4th Edition), Business Rules Solutions LLC (2013).  www.brsolutions.com/b_concepts.php  

[12]  Thomas Frisendal, Design Thinking Business Analysis:  Business Concept Mapping Applied, Springer (2012).  

[13]  Malcolm D. Chisholm, Big Data and the Coming Conceptual Model Revolution, (2012).  Available at:  http://www.information-management.com/newsletters/data-model-conceptual-big-data-Chisholm-10022303-1.html  

Acknowledgments

The EU-Rent case study was developed by Model Systems, Ltd., along with several other organizations such as the Business Rules Group (businessrulesgroup.org), and has been used by many organizations.  The body of descriptions and examples may be freely used, providing its source is clearly acknowledged.

CmapTools is a trademark of the Institute for Human and Machine Cognition on behalf of the University of West Florida Board of Pensacola, FL 32501, USA.

This article is based on parts of the book Design Thinking Business Analysis:  Business Concept Mapping Applied by Thomas Frisendal, © Springer 2012, ISBN-13:  978-3642328435.

# # #