Business Stories: Stakeholders’ Plots & Users’ Narratives

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.

cccc

Only shadows will tell: as far as stories are concerned, possibilities remain unknown until their realization.

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 short-lived opportunities identified by business units with broader and long-standing objectives defined at corporate level.

Assuming a fictional view of business expectations, that issue 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.

XBredModels_PlotsNarrs

On a broader perspective such a fictional approach may help to align enterprise architectures to business objectives.

Further Reading

External Links

Advertisements

Tags:

6 Responses to “Business Stories: Stakeholders’ Plots & Users’ Narratives”

  1. Tom Hussey Says:

    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 …

    Like

  2. caminao Says:

    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.

    Like

  3. andywootton Says:

    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.

    Like

  4. caminao Says:

    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/

    Like

  5. andywootton Says:

    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.

    Like

  6. caminao Says:

    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.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: