Follow us...

Usable Representations   

By Julian Sammy, Head of Research and Innovation, IIBA   
  
The Business Analysis Core Concept Model (BACCM) describes a dynamic system of interrelated ideas. The model represents many abstract aspects of business analysis. It is powerful because it is useful to stakeholders: experienced business analysts can use it to think through problems; novice BAs can use it to communicate more effectively.
 
Most business analysis work involves abstraction and representation; we analyse information to determine what is relevant (and to whom), and then create representations of key information for use by those stakeholders.
 
Good Models and Usable Representations
 
In the general case, we call any representation a ‘model’. All models share a few characteristics of particular interest to business analysis:
  • focus: intentionally leave out irrelevant information, and intentionally include relevant information.
  • symbolic: information about the thing being modelled is encoded in some form that is separate from the thing itself (drawing, sound, electricity, etc.).
Focus is key to making a model useful. The trick is to figure out what to leave out and include to ensure relevance to a particular stakeholder - and to understand the stakeholder well enough to know what ‘relevant’ means. This means that ‘good model’ and ‘usable representation’ are synonymous when considered in terms of the BACCM. Requirements, designs, risks, and plans, are among many usable representations that align to the BACCM. The phrase, "All models are wrong; some are useful," is a reminder that models should serve a purpose for someone, but that models are not reality.
 
Good models are abstractions, then: the expression of the idea of a thing, rather than the thing itself. You can’t drive the design for a car even if the design is in the form of a physical structure. (Before you get carried away, a prototype of a car is drivable, but not a design for a car - it’s a design for a mass-production process, and you can’t mass-produce a prototype. The nature of the abstraction changes as the purpose of the model changes.)
 
Modelling for Change
 
Any controlled transformation of organizational systems demands a lot of useful representations. Stakeholders in the change make a lot of decisions, and need good abstractions to support those decisions. Requirements and designs are models of Needs and Solutions. The most abstracted requirements - vision, mission, goals, objectives, and the support decisions made by almost everyone involved in a Change; they provide direction and maintain alignment. More concrete requirements are used by the people who build, test, and use a Solution for many reasons, such as ensuring completeness, or managing value delivery.
 
Plans, work breakdown structures, activity network diagrams, context diagrams, requirements, designs, test cases, strategies, plans, risks, simulations,... the list of models used to make a change is enormous. Sometimes they are even called ‘models’.
 
Modelling for Operations
 
An organization can be thought of as doing two kinds of work.
  1. Operations: All the effort that goes into producing products delivering services, making sales, and sustaining the business capabilities to do these things. The bulk of most organizational effort is usually operational. As noted in the second BACCM article (Nov 2012), "The work of turning raw materials into finished products is also a kind of change-it is the actual operation of the organization-but BAs do not work on the assembly line. BAs don’t operate the organization; they help change the way the organization operates."
  2. Change: All the effort that goes into altering the way that operations are performed. For most people, “projects” are the most familiar form of change (controlled transformation of organizational systems). Change work is often viewed as an obstruction and problem by the people operating the organization.
Just like the people who work to change the operations of an organization, the people who operate and sustain the organization need good information to make good decisions. They need ‘operational models’ to represent relevant factors in the organization. The flow of information must be continuous (in the same sense that the operations of the organization are continuous) and can be categorized into two groups.
 
Interfaces and Reports
 
Information flows through systems. When information is transferred from one actor to another, it is through an interface or a report.
 
Interfaces  Reports
Tend to refer to information flows that are part of a process.  Tend to refer to information flows that are inputs and outputs to a process. 
May pass information among humans, among tools, or between tools and humans.  Always pass information to humans, whether the sources are humans or tools.
Are often part of continuous feedback and control loops (in a car, the steering wheel, a temperature gauge, the smell of burning oil) Are often part of long-term trend analysis and planning for change
 
Interfaces
  • tend to refer to information flows that are part of a process.
  • pass information among humans, among tools, or between tools and humans.
  • are often part of continuous feedback and control loops (in a car, the steering wheel, a temperature gauge, the smell of burning oil)
Reports
  • tend to refer to information flows that are inputs and outputs to a process.
  • always pass information to humans, whether the sources are humans or tools.
  • are often part of long-term trend analysis and planning for change.
Conclusion
 
Usable representations - also known as ‘good models’ - are a critical aspect of business analysis. Abstracting relevant information into a form that is usable by stakeholders is a key challenge all BAs face, especially when several stakeholders need to use the same document to make different decisions.
 
With this background on the idea of usable representations, the definition of a requirement - a usable representation of a need - should be clearer. It should also be clear that usable representations are created and used by everyone in the organization.
 
In many organizations the requirements for interfaces are well defined, but the requirements for reports are woefully lacking. Our analysis shows that interfaces and reports are strongly related, but they are not equally represented in business analysis work. They are not the same any more than a bat is the same as a whale - but bats and whales are both mammals, and are much more stingily related to each other than they are to spiders or beetles.
 
Next month we will explore why reports disable organizations instead of enabling them, and how to create good reporting requirements to make them better.