Preamble
As Aristotle noted some time ago, plots are the backbone of any story as they uphold the causal sequence of events and actions: they provide the “why” of what happens, compared to narratives, which tell “how” what happened is being told.
So, in principle, plots deal with possibilities and narratives with realizations. But in fact plots remain unknown until being narrated; in other words fictions are like Schrödinger’s cat: there is no way to set possibilities and realizations apart.
That literary conundrum may convey some useful clues for business analysis, with stakeholders objectives seen as plots, and users’ stories as narratives.
Stakeholders’ Plots vs Users’ Narratives
With regard to the functionalities of supporting systems, a key issue for business analysts is to accommodate specific and/or short-term opportunities identified by business units with broader and long-standing objectives defined at corporate level.
Using the fictional metaphor, business expectations can be charted in terms of plots and narratives:
- Business objectives (as plots) are meant to apply continuously and consistently to different agents, different concerns, and different contexts. As such they are best defined as rules and constraints (declarative schemes).
- Users’ stories (as narratives) are supposed to translate as soon as possible into business transactions. As such they are best defined as sequences of operations governed by users’ choices (procedural schemes).
Then, just like narratives are meant to carry out the plots, users’ stories are supposed to follow the paths set by business objectives. But if confusion is to be avoided between strategic orientations, regulatory directives, and opportunist moves, the walk of business objectives and the talk of users’ stories should be termed differently.
Business Objectives (Plots): Symbolic & Allochronic
The definition of business objectives has to find its terms between the Charybdis of abstractions and the Scylla of specific business processes, the former to be avoided because they are by nature detached from reality and only make sense with regard to models, the latter because they would be too specific and restrictive. In-between, business objectives would be best defined through:
- Strategic and financial objectives expressed using symbolic categories applied to environments, products, and resources.
- Modal time-frames identified in reference to events and qualified by assumptions with regard to symbolic categories.
- Business functions to be optimized given a set of constraints.
These could be comprehensively and consistently expressed with declarative languages.
Users’ Stories (Narratives): Actual & Contemporaneous
Users’ stories are at their best when tied to specific circumstances and purposes without being led away by modeling concerns. As narratives they should stick to agents, triggering events, and scripted sequences of options, operations, and outcomes:
- Compared to the symbolic categories used for business objectives, users stories should refer to actual subsets of objects and events defined on contexts.
- Contrary to the modal time-frames of business objectives, the scripts of users’ stories must be fully timed with regard to their triggering events.
That can only be expressed as procedures.
From Fiction to Artifacts: Aligning Business Objectives & Enterprise Architectures
Likening business analysis to its distant literary kin goes beyond the metaphor as it points to a practical organization of business objectives and users’ stories.
And the benefits of the distinction between declarative (for business plots) and procedural (for users’ narratives) blueprints is not limited to business analysis but can be extended to systems architecture (as plots) and software design (as narratives). On that basis declarative schemes could be applied to business functions and architectures capabilities, and procedural ones to users’ stories (or use cases) and software design.
On a broader perspective that approach can be used to frame enterprise architectures and business objectives.
Further Reading
- How to Mind a Tree Story
- From Stories to Models
- Agile Business Analysis: From Wonders to Logic
- Use Cases are Agile Tools
- Focus: Users’ Stories & Use Cases
- Agile & Models
- Thinking about Practices
- Conceptual Models & Abstraction Scales
- Models Transformation & Agile Development
- From Processes to Services
- Agile Architectures: Versatility meets Plasticity
I agree with procedure as some kind of algorithm. And there is no need to introduce a new concept for instances: just like one speak of instances for classes, one may do the same for processes.
Not even by me 🙂 I meant business process as a type and procedure as an instance of an algorithm that implements it, possibly as code that might run copies as instances within compute processes. I guess a compute process is a downward abstraction that might run any coded procedure. I think this idea that the computation is a procedure, seperate from the process that provides the context in which it runs, is new to me. I may have looped.
Andy,
Right, but…
Part of he problem comes from terminology: understanding ‘procedure’ as a type and ‘process’ as instance is not commonly accepted.
Then, I’d rather apply the ‘what/why/how/when/where’ template as a whole to declarative scheme like architectures or capabilities (as opposed to processes or realizations).
https://caminao.wordpress.com/2014/10/21/processes-capabilities/
I find this is a fascinating idea. It also seems analogous to the distinction I make between ‘process’, what must be done and ‘procedure’, how we choose to do it. I wonder, therefore, if ‘plot’ is ‘what’ as well as ‘why’ and that sounds like an agile user-story. That would make code (and perhaps architectural models) the narrative.
Thanks for making me think hard. I was already considering the relationship between networks of facts & ideas and narrative as a collection of paths through the network, so your ‘intervention’ has been timely.
Tom,
That’s the point: there should be a clear distinction between users’ stories and hierarchies of business objectives, the stories being equivalent to leaves in trees of objectives.
Hmmm, I think there’s something interesting and important here but I’m struggling to get my head around it. I also think the distinction between objectives and user stories is a little blurred in real life – in reality you have a hierarchy of objectives and a hierarchy of stories, with low level objectives and high level stories overlapping or in effect being the same …