Use cases are meant to describe dialogues between users and systems, yet they usually don’t stand in isolation. On one hand they stem from business processes, on the other hand they must be realized by system functionalities, some already supported, others to be newly developed. As bringing the three facets within a shared modeling paradigm may seem a long shot, some practical options may be at hand.
Use cases should leave no room for interpretations (Jonathan Monk)
To begin with, a typical option would be to use the OMG’s Meta-Object Facility (MOF) to translate the relevant subset of BPM models into UML ones. But then if, as previously suggested, use cases can be matched with such a subset, a more limited and pragmatic approach would be to introduce some modeling primitives targeting UML artifacts.
From BPM to UML: Meta-model vs Use cases.
For that purpose it will be necessary to clarify the action semantics associated with the communication between processes and systems.
Meta-models drawbacks
Contrary to models, which deal with instances of business objects and activities, meta-models are supposedly blind to business contents as they are meant to describe modeling artifacts independently of what they stand for in business contexts. To take an example, Customer is a modeling type, UML Actor is a meta-modeling one.
To stress the point, meta-languages have nothing to say about the semantics of targeted domains: they only know the language constructs used to describe domains contents and the mapping rules between those constructs.
As a consequence, whereas meta-languages are at their best when applied to clear and compact modeling languages, they scale poorly because of the exponential complexity of rules and the need to deal with all and every language idiosyncrasies. Moreover, performances degrade critically with ambiguities because even limited semantics uncertainties often pollute the meaning of trustworthy neighbors generating cascades of doubtful translations (see Knowledge-based model transformation).
Factoring a core with trustworthy semantics (b) will prevent questionable ones from tainting the whole translation (a).
Yet, scalability and ambiguity problems can be overcame by applying a core of unambiguous modeling constructs to a specific subset, and that can be achieved with use cases.
Use Cases & UML diagrams
As it happened, the Use Case can be seen as the native UML construct, the original backbone around which preexisting modeling artifacts have been consolidated, becoming a central and versatile hub of UML-based development processes:
Sequence diagrams describe collaborations between system components but can also describe interactions between actors and systems (i.e use cases).
Activity diagrams describe the business logic to be applied by use cases.
Class diagrams can be used for the design of software components but also for the analysis of business objects referenced by use cases.
State diagrams can be used for the behavior of software components but also for the states of business objects or processes along execution paths of use cases.
Use case as Root Sequence
Apart of being a cornerstone of UML modeling, use cases are also its doorway as they can be represented by a simple sequence diagram describing interactions between users and systems, i.e between business processes and applications. So the next step should be to boil down the semantics of those interactions.
Use Cases & Action Semantics
When use cases are understood as gateways between business users and supporting systems, it should be possible to characterize the basic action semantics of messages in terms of expectations with regard to changes and activity:
Change: what process expects from system with regard to the representation of business context.
Activity: what process expects from system with regard to its supporting role.
Basic action semantics for interactions between users (BPM) and systems (UML)
Crossing the two criteria gives four basic situations for users-to-system action semantics:
Reading: no relevant change in the environment has to be registered, and no activity has to be supported.
Monitoring: no relevant change in the environment has to be registered, but the system is supposed to keep track on some activity.
Achievement: the system is supposed to keep track on some specific change in the environment without carrying out any specific activity.
Accomplishment: the system is supposed to keep track on some specific change in the environment and support associated activity.
These action primitives have to be wrapped into interaction ones relating to changing expectations of users and systems.
State machine can fully support action semantics
When use cases are positioned at the center of UML diagrams, those situations can be neatly modeled with state machines for actors’ expectations, business objects, and execution.
UC specified with State machine.
Use Cases & Modeling Patterns
If use cases describe what business processes expect from supporting systems, they can be used to map action semantics to UML diagrams:
Reading: class diagrams with relevant queries.
Monitoring: activity diagrams with reference to class diagrams.
Achievement: class diagrams with associated state diagrams.
Accomplishment: activity diagrams with associated state diagrams and reference to class diagrams.
From use cases action semantics to UML diagrams
While that catalog cannot pretend to fully support requirements, the part it does support comes with two critical benefits:
It fully and consistently describes the interactions at architecture level.
It can be unambiguously translated from BPM to UML.
On that basis, use cases provide a compact and unambiguous kernel of modeling constructs bridging the gap between BPM and UML.
Uses cases are meant to describe how users interact with systems, classes are meant to describe software components, including those executing use cases. It ensues that classes are introduced with the realization of use cases but are not supposed to appear as such in their definition.
Users are not supposed to know about surrogates
The Case for Use Cases
Use cases (UCs) are the brain child of Ivar Jacobson and often considered as the main innovation introduced by UML. Their success, which largely outdoes UML’s footprint, can be explained by their focus and simplicity:
Focus: UCs are meant to describe what happens between users and systems. As such they are neatly bounded with regard to their purpose (UCs are the detailed parts of business processes supported by systems) and realization (UCs are implemented by software applications).
Simplicity: while UCs may eventually include formal (e.g pre- and post-conditions) and graphical (e.g activity diagrams) specifications, they can be fully defined and neatly circumscribed using stick actors (for the roles played by users or any other system) and ellipses (for system behaviors).
Use Cases & UML diagrams
As it often happens to successful innovations, use cases have been widely interpreted and extended; nonetheless, the original concepts introduced by Ivar Jacobson remain basically unaltered.
The Point of Use Cases
Whereas focus and simplicity are clearly helpful, the primary success factor is that UCs have a point, namely they provide a conceptual bridge between business and system perspectives. That appears clearly when UCs are compared to main alternatives like users’ stories or functional requirements:
Users’ stories are set from business perspective and lack explicit constructs for the parts supported by systems. As a consequence they may flounder to identify and describe business functions meant to be shared across business processes.
Conversely, functional requirements are set from system perspective and have no built-in constructs linking business contexts and concerns to their system counterparts. As a consequence they may fall short if business requirements cannot be set upfront or are meant to change with business opportunities.
Along that understanding, nothing should be done to UCs that could compromise their mediating role between business value and system capabilities, the former driven by changes in business environment and enterprise ability to seize opportunities, the latter by the continuity of operations and the effective use of technical or informational assets.
Business Objects vs Software Components
Users’ requirements are driven by concrete, partial, and specific business expectations, and it’s up to architects to weld those diverse and changing views into the consistent and stable functional abstractions that will be implemented by software components.
Users’ requirements are driven by concrete, partial, changing and specific concerns, but supported by stable and fully designed software abstractions.
Given that double discrepancy of objectives and time-scales, business analysts should not try to align their requirements with software designs, and system analysts should not try to second-guess their business counterparts with regard to future business objects. As a consequence, respective outcomes would be best achieved through a clear separation of concerns:
Use cases deal with the business value of applications, mapping views on business objects to aspects of classes.
Functional architectures deal with assets, in particular the continuous and consistent representation of business objects by software components as described by classes.
How to get best value from assets
As it happens, that double classification with regard to scope and purpose should also be used to choose a development model: agile when scope and purpose can be united, phased approach otherwise.
Depending on devotees or dissenters, the Agile development model is all too often presented as dead-end or end-of-story. Some of that unfortunate situation can be explained, and hopefully pacified, by comparing users’ stories to plants, with their roots, trunks, and branches. Assuming that agility calls for sound footings and good springboards, it may be argued that many problems arise with stories barking at the wrong tree (application level) or getting lost in the woods (architecture level).
How to Mind/Mend a True/Tree Story
Application level: Trees, Bushes and Hedges
As Aristotle first stated, good stories have to follow the three unities: one course of action, located in a single space, run along continuous time.
That rule is clearly satisfied by stories that can be developed like plants growing from clearly identified roots.
Yet, stories like bushes may grow too many offshoots to be accounted for by a single action narrative; in that case it may be possible to single out a primary trunk and a set of forking branches along which different scenarii could be developed.
More serious difficulties may appear with thickets mixing offshoots from different bushes sharing the same space. That situation will first require some ground work in order to single out individual roots, and then use them to extricate each bush separately. When, like offshoots that actually mingle, story-lines cross and share actions, the description of such actions (aka features) is to be factored out and separated from the contexts of their enactment in the different story-lines.
Finally, like bushes in hedges, stories may chronicle repeated activities serving some collective purpose. That configuration is both easy to recognize and dealt with effectively by introducing a stereotyped story feature for collections and loops management.
Architecture level: Groves, Woods and Plantations
Contrary to hedges which are built on the similarity of their constituents, groves are based on their functional differences, and that can also be seen as a critical distinction between containers and architectures.
In agile parlance, that is best compared to the difference between stories and epics, the former telling what happens between users and applications, the latter taking a bird’s view of the relationships between business processes and systems.
In most of the cases the question will arise for sizable stories deemed too large for development purposes. When dealing with that situation the first step should be to look for thickets and bushes, respectively to be set apart as individual bushes or refined as scenarii. When still confronted with multiple roots, the question would be to decide between hedges and groves, that is between repeated activities and collaboration. And that decision would be critical because collaborations call for a different kind of story (aka epics or themes) set at a higher level, namely architecture.
Scaling Ups and Downs
Assuming the three-units rule cannot be met, two alternative approaches are possible, depending on whether the story has to be broken down or upgraded to an epic, and the undoing of the rule can be used to make a decision:
When the course of actions, once started, is to be contingent on subsequent business (aka external) events the story should be upgraded to an epic, as it will often refer to a part or whole of a business process.
Otherwise: when activities are set along different periods of time (i.e contingent on time-events) the story can be broken down depending on size, functional architecture, or development constraints.
Otherwise: when activities are distributed across locations it may be necessary to factor out architecture-dependent features dealing with shared address spaces and synchronization mechanisms
Applying those guidelines to stories will put the whole development processes on rails and help to align requirements with their architectural footprint: business logic, system functionalities, or platform technologies.
Empathy is commonly defined as the ability to directly share another person’s state of mind: feelings, emotions, understandings, etc. Such concrete aptitude would clearly help business analysts trying to capture users’ requirements; and on a broader perspective it could even contribute to enterprise capability to foretell trends from actual changes in business environment.
Perceptions and Abstractions (Picasso)
Analysis goes in the opposite direction as it extracts abstract descriptions from concrete requirements, singling out a subset of features to be shared while foregoing the rest. The same process of abstraction being carried out for enterprise business and organisation on one hand, systems and software architectures on the other hand.
That dual perspective can be used to define alignment with regard to the level under consideration: users, systems, or enterprise.
Requirements & Architectures
Requirements capture can be seen as a transition from spoken to written language, its objective being to write down what users tell about what they are doing or what they want to do. For that purpose analysts are presented with two basic policies: they can anchor requirements around already known business objects or processes, or they can stick to users’ stories, identify new structuring entities, and organize requirements alongside. In any case, and except for standalone applications, the engineering process is to be carried out along two paths:
One concrete for the development of applications, the objective being to meet users’ requirements with regard to business logic and quality of service.
The other abstract for requirements analysis, the objective being to identify new business functions and features and consolidate them with those already supporting current business processes.
Those paths are set in orthogonal dimensions as concrete paths connect users’ activities to applications, and abstractions can only be defined between requirements levels.
Concrete (brown) and Abstract (blue) paths of requirements engineering
As business analysts stand at the crossroad, they have to combine empathy when listening to users concerns and expectations, and abstraction when mapping users requirements to systems functionalities and enterprise business processes.
Architectures & Alignments
As it happens, the same reasoning can be extended to the whole of engineering process, with analysis carried out to navigate between abstraction levels of architectures and requirements, and design used for the realization of each requirements level into its corresponding architecture level:
Users’ stories (or more precisely corresponding uses cases) are realized by applications.
Business functions and features are realized by services (assuming a service oriented architecture), which are meant to be an abstraction of applications.
Business processes are realized by enterprise capabilities, which can be seen as an abstraction of services.
How requirements are realized by design at each architecture level
That matrix can be used to define three types of alignment:
At users level the objective is to ensure that applications are consistent with business logic and provide the expected quality of service. That is what requirements traceability is meant to achieve.
At system level the objective is to ensure that business functions and features can be directly mapped to systems functionalities. That is what services oriented architectures (SOA) are meant to achieve.
At enterprise level the objective is to ensure that the enterprise capabilities are congruent with its business objectives, i.e that they support its business processes through an effective use of assets. That is what maturity and capability models are meant to achieve.
That makes alignment a concrete endeavor whatever the architecture layer, i.e not only for users and applications, but also for functions and capabilities.
Enterprise Fourth Dimension
Enterprise Architectures can be fully described as a cross between layers (platforms, systems, organization) and processes (business, engineering, operations). But the validity and usefulness of such outlook is contingent on homogeneous and stable semantics:
Homogeneous: some conceptual consensus can be sustained across business units.
Stable: some continuity and consistency can be achieved for the mapping between business objectives and targeted environments.
Meeting those conditions may become problematic with the growing part played by services and the crumbling of fences between enterprises and their business environment. In that case alignment will have to rely on a fourth conceptual dimension.
Between Internet-of-Things and ubiquitous social networks, enterprises’ environments are turning into unified open spaces, transforming the divide between operational and decision-making systems into a pitfall for corporate governance. That jeopardy can be better understood when one consider how the processing of events affect decision-making.
Making sense of event (J.W. Waterhouse)
Events & Information Processing
Enterprises’ success critically depends on their ability to track, understand, and exploit changes in their environment; hence the importance of a fast, accurate, and purpose-driven reading of events.
That is to be achieved by picking the relevant facts to be tracked, capturing the associated data, processing the data into meaningful information, and finally putting that information into use as knowledge.
From Facts to Knowledge and Back
Those tasks have to be carried out iteratively, dealing with both external and internal events:
External events are triggered by changes in the state of actual objects, activities, and expectations.
Internal events are triggered by the ensuing changes in the symbolic representations of objects and processes as managed by systems.
With events set at the root of the decision-making process, they will also define the time frames.
Events & Decisions Time Frames
In principle, decision-making can be defined as real-time knowledge management:
To begin with, a real-time scale is created by new facts (t1) registered through the capture of events and associated data (t2).
A symbolic intermezzo is then introduced during which data is analyzed, information updated (t3), knowledge extracted, and decisions taken (t4);
The real-time scale completes with decision enactment and corresponding change in facts (t5).
Time scale of decision making (real time events are in red, symbolic ones in blue)
But that phased approach is now becoming obsolete as it cannot cope with digitized environments and the ensuing collapse of fences between enterprises and their environment.
Once carried out separately and periodically, decision-making is to be carried out iteratively at operational, tactical, and strategic level; while each level is to be set along its own time-frames, all are to rely on data-mining, with cycles following the same pattern:
Observation: understanding of changes in business opportunities.
Orientation: assessment of the reliability and shelf-life of pertaining information with regard to current positions and operations.
Decision: weighting of options with regard to enterprise capabilities and broader objectives.
Action: carrying out of decisions within the relevant time-frame.
Given digitized environments, decision-making processes have to weave together material and digitized flows, actual contexts (aka territories) and symbolic descriptions (maps), and overlapping time-frames (operational tactical, strategic). That operational loop could then be coupled with the broader one of business intelligence:
The next step is to bring together events and knowledge.
Events & Changes in Knowns & Unknowns
As Donald Rumsfeld once suggested, decision-making is all about the distinction between things we know that we know, things that we know we don’t know, and things we don’t know we don’t know. And that classification can be mapped to the nature of events and the processing of associated data:
Known knowns (KK) are traced through changes in already defined features of identified objects, activities or expectations. Corresponding external events are expected and the associated data can be immediately translated into information.
Known unknowns (KU) are traced through changes in still undefined features of identified objects, activities or expectations. Corresponding external events are unexpected and the associated data cannot be directly translated into information.
Unknown unknowns (UU) are traced through changes in still undefined objects, activities or expectations. Since the corresponding symbolic representations are still to be defined, both external and interval events are unexpected.
Knowledge lifespan is governed by external events
Given that decisions are by nature set in time-frames, they should be mapped to changes in environments, or more precisely to the information carried out by the events taken into consideration.
Knowledge & Decision Making
Events bisect time-scales between before and after, past and future; as a corollary, the associated information (or lack thereof) about changes can be neatly allocated to the known and unknown of current and prospective states of affairs.
Changes in the current states of affairs are carried out by external events:
Known knowns (KK): when events are about already defined features of objects, activities or expectations, the associated data can be immediately used to update the states of their symbolic representation.
Known unknowns (KU): when events entail new features of already defined objects, activities or expectations, the associated data must be analyzed in order to adjust existing symbolic representations.
Unknown unknowns (UU): when events entail new objects, activities or expectations, the associated data must be analyzed in order to build new symbolic representations.
As changes in current states of affairs are shadowed by changes in their symbolic representation, they generate internal events which in turn may trigger changes in prospective states of affairs:
Known knowns (KK): updating the states of well-defined objects, activities or expectations may change the course of action but should not affect the set of possibilities.
Known unknowns (KU): changes in the set of features used to describe objects, activities or expectations may affect the set of tactical options, i.e ones that are can be set for individual production life-cycles.
Unknown unknowns (UU): introducing new types of objects, activities or expectations is bound to affect the set of strategic options, i.e ones that are encompass multiple production life-cycles.
Interestingly, those levels of knowledge appear to be congruent with usual horizons in decision-making: operational , tactical, and strategic:
The scope of decision-making is set by knowledge level
Operational: full information on actual states allows for immediate appraisal of prospective states.
Tactical: partially defined actual states allow for periodic appraisal of prospective states in synch with production cycles.
Strategic: undefined actual states don’t allow for periodic appraisal of prospective states in synch with production cycles; their definition may also be affected through feedback.
Given that those levels of appraisal are based on conjectural information (internal events) built from fragmentary or fuzzy data (external events), they have to be weighted by risks.
Weighting the Risks
Perfect information would guarantee risk-free future and would render decision-making pointless. As a corollary, decisions based on unreliable information entail risks that must be traced back accordingly:
Operational: full and reliable information allows for risk-free decisions.
Tactical: when bounded by well-defined contexts with known likelihoods, partial or uncertain information allows for weighted costs/benefits analysis.
Strategic: set against undefined contexts or unknown likelihoods decision-making cannot fully rely on weighted costs/benefits analysis and must encompass policy commitments, possibly with some transfer of risks, e.g through insurance contracts.
That provides some kind of built-in traceability between the nature and likelihood of events, the reliability of information, and the risks associated to decisions.
Decision Timing
Considering decision-making as real-time knowledge management driven by external (aka actual) events and governed by internal (aka symbolic) ones, how would that help to define decisions time frames ?
To begin with, such time frames would ensure that:
All the relevant data is captured as soon as possible (t1>t2).
All available data is analyzed as soon as possible (t2>t3).
Once a decision has been made, nothing can change during the interval between commitment and action (respectively t4 and t5).
Given those constraints, the focus of timing is to be on the interval between change in prospective states (t3) and decision (t4): once all information regarding prospective states is available, how long to wait before committing to a decision ?
Assuming that decisions are to be taken at the “last responsible moment”, i.e until not taking side could change the possible options, that interval will depend on the nature of decisions:
Operational decisions can be put to effect immediately. Since external changes can also be taken into account immediately, the timing is to be set by events occurring within production life-cycles.
Tactical decisions can only be enacted at the start of production cycles using inputs consolidated at completion. When analysis can be done in no time (t3=t4) and decisions enacted immediately (t4=t5), commitments can be taken from on cycle to the next. Otherwise some lag will have to be introduced. The last responsible moment for committing a decision will therefore be defined by the beginning of the next production cycle minus the time needed for enactment.
Strategic decisions are meant to be enacted according to predefined plans. The timing of commitments should therefore combine planning (when a decision is meant to be taken) and events (when relevant and reliable information is at hand).
The scope of decision-making should be aligned with architecture layers
Not surprisingly, when the scope of decision-making is set by knowledge level, it appears to coincide with architecture layers: strategic for enterprise assets, tactical for systems functionalities, and operational for platforms and resources. While that clearly calls for more verification and refinements, such congruence put events processing, knowledge management, and decision-making within a common perspective.
When seen through cybernetics glasses, enterprises are social entities whose sustainability and capabilities hang on their ability to track changes in their environment and exploit opportunities before their competitors. As a corollary, corporate governance is to be contingent on fast, accurate and purpose-driven reading of environments on one hand, effective use of assets on the other hand.
Entropy grows from confusion (Lazlo Moholo-Nagy)
And that will depend on enterprises’ capacity to capture data, process it into information, and translate information into knowledge supporting decision-making. Since that capacity is itself determined by architectures, a changing and competitive environment will require continuous adaptation of enterprises’ organization. That’s when disorder and confusion may increase: lest a robust and flexible organization can absorb and consolidate changes, variety will progressively clog the systems with specific information associated with local adjustments.
Governance & Information
Whatever its type, effective corporate governance depends on timely and accurate information about the actual state of assets and environments. Hence the need to assess such capabilities independently of the type of governance structure that has to be supported, and of any specific business context.
Effective governance is contingent on the distance between actual state of assets and environment on one hand, relevant information on the other hand.
That put the focus on the processing of information flows supporting the governance of interactions between enterprises and their environment:
How to identify the relevant facts and monitor them as accurately and timely as required.
How to process external data from environment into information, and to consolidate the outcome with information related to enterprise objectives and internal states.
How to put the consolidated information to use as knowledge supporting decision-making.
How to monitor processes execution and deal with relevant feedback data.
What is behind enterprise ability to track changes in environment and exploit opportunities.
Enterprises being complex social constructs, those tasks can only be carried on through structured organization and communication mechanisms supporting the processing of information flows.
Architectures & Changes
Assuming that enterprise governance relies on accurate and timely information with regard to internal states and external environments, the first step would be to distinguish between the descriptions of actual contexts on one hand, of symbolic representation on the other hand.
Enterprise architectures can be described along two dimensions: nature (actual or symbolic), and target (objects or activities).
Even for that simplified architecture, assessing variety and information processing capabilities in absolute terms would clearly be a challenge. But assessing variations should be both easier and more directly useful.
Change being by nature relative to time, the first thing is to classified changes with regard to time-frames:
Operational changes are occurring, and can be dealt with, within the time-frame of processes execution.
Structural changes affect contexts and assets and cannot be dealt with at process level as they.
On that basis the next step will be to examine the tie-ups between actual changes and symbolic representations:
From actual to symbolic: how changes in environments are taken into account; how processes execution and state of assets are monitored.
From symbolic to actual: how changes in business models and processes design are implemented.
What moves first: actual contexts and processes or enterprise abstractions
The effects of those changes on overall governance capability will depend on their source (internal or external) and modality (planned or not).
Changes & Information Processing
As far as enterprise governance is considered, changes can be classified with regard to their source and modality.
With regard to source:
Changes within the enterprise are directly meaningful (data>information), purpose-driven (information>knowledge), and supposedly manageable.
Changes in environment are not under control, they may need interpretation (data<?>information), and their consequences or use are to be explored (information<?>knowledge).
With regard to modality:
Data associated with planned changes are directly meaningful (data>information) whatever their source (internal or external); internal changes can also be directly associated with purpose (information>knowledge);
Data associated with unplanned internal changes can be directly interpreted (data>information) but their consequences have to be analyzed (information<?>knowledge); data associated with unplanned external changes must be interpreted (data<?>information).
Changes can be classified with regard to their source (enterprise or environment) and modality (planned or not).
Assuming with Stafford Beer that viable systems must continuously adapt their capabilities to their environment, this taxonomy has direct consequences for their governance:
Changes occurring within planned configurations are meant to be dealt with, directly (when stemming from within enterprise), or through enterprise adjustments (when set in its environment).
That assumption cannot be made for changes occurring outside planned configurations because the associated data will have to be interpreted and consequences identified prior to any decision.
Enterprise governance will therefore depend on the way those changes are taken into account, and in particular on the capability of enterprise architectures to process the flows of associated data into information, and to use it to deal with variety.
EA & Models
Originally defined by thermodynamic as a measure of heat dissipation, the concept of entropy has been taken over by cybernetics as a measure of the (supposedly negative) variation in the value of information supporting corporate governance.
As noted above, the key challenge is to manage the relevancy and timely interpretation and use of the data, in particular when new data cannot be mapped into predefined semantic frame, as may happen with unplanned changes in contexts. How that can be achieved will depend on the processing of data and its consolidation into information as carried on at enterprise level or by business and technical units.
Given that data is captured at the periphery of systems, one may assume that the monitoring of operations performed by business and technical units are not to be significantly affected by architectures. The same assumption can be made for market research meant to be carried on at enterprise level.
Architecture Layers and Information Processing
Within that working assumption, the focus is to be put on enterprise architecture capability to “read” environments (from data to information), as well as to “update” itself (putting information to use as knowledge).
With regard to “reading” capabilities the primary factor will be traceability:
At technical level traceability between components and applications is required if changes in business operations are to be mapped to IT architecture.
At organizational level, the critical factor for governance will be the ability to adapt the functionalities of supporting systems to changes in business processes. And that will be significantly enhanced if both can be mapped to shared functional concepts.
Once the “readings” of external changes are properly interpreted with regard to internal assets and objectives, enterprise governance will have to decide if changes can be dealt with by the current architecture or if it has to be modified. Assuming that change management is an intrinsic part of enterprise governance, “updating” capabilities will rely on a continuous, comprehensive and consistent management of information, best achieved through models, as epitomized by the Model Driven Architecture (MDA) framework.
Models as bridges between data and knowledge
Based on requirements capture and analysis, respective business, functional, and technical information is consolidated into models:
At technical level platform specific models (PSMs) provide for applications and components traceability. They support maintenance and configuration management and can be combined with design patterns to build modular software architecture from reusable components.
At organizational level, platform independent models (PIMs) are used to align business processes with systems functionalities. Combined with functional patterns the objective is to use service oriented architectures as a level of indirection between organization and information technology.
At enterprise level, computation independent models (CIMs) are meant to bring together corporate tangible and intangible assets. That’s where corporate culture will drive architectural changes from systems legacy, environment challenges, and planned designs.
EA & Entropy
Faced with continuous changes in their business environment and competition, enterprises have to navigate between rocks of rigidity and whirlpools of variety, the former policies trying to carry on with existing architectures, the latter adding as many variants as seems to appear to business objects, processes, or channels. Meeting environments challenges while warding off growing complexity will depend on the plasticity and versatility of architectures, more precisely on their ability to “digest” the variety of data and transform it into corporate knowledge. Along that perspective enterprise architecture can be seen as a natural antidote to entropy, like a corporate cousin of Maxwell’s demon, standing at enterprise gates and allowing changes in a way that would decrease internal complexity relative to the external one.
Given the clear-cut and unambiguous nature of software, how to explain the plethora of “standard” definitions pertaining to systems, not to mention enterprises, architectures ?
Documents and Systems: which ones nurture the others (Gilles Barbier).
Tentative answers can be found with reference to the core functions documents are meant to support: instrument of governance, medium of exchange, and content storage.
Instrument of Governance: the letter of the law
The primary role of documents is to support the continuity of corporate identity and activities with regard to their regulatory and business environments. Along that perspective documents are to receive legal tender for the definitions of parties (collective or individuals), roles, and contracts. Such documents are meant to support the letter of the law, whether set at government, industry, or corporate level. When set at corporate level that letter may be used to assess the capability and maturity of architectures, organizations, and processes. Whatever the level, and given their role for legal tender or assessment, those documents have to rely on formal textual definitions, possibly supplemented with models.
Medium of Exchange: the spirit of the law
Independently of their formal role, documents are used as medium of exchange, across corporate entities as well as internally between their organizational units. When freed from legal or governance duties, such documents don’t have to carry authorized or frozen interpretations and assorted meanings can be discussed and consolidated in line with the spirit of the law. That makes room for model-based documents standing on their own, with textual definitions possibly set in the background. Given the importance of direct discussions in the interpretation of their contents, documents used as medium of (immediate) exchange should not be confused with those used as means of storage (exchange along time).
Means of Storage: letter only
Whatever their customary functions, documents can be used to store contents to be reinstated at a later stage. In that case, and contrary to direct (aka immediate) exchange, interpretations cannot be consolidated through discussion but have to stand on the letter of the documents themselves. When set by regulatory or organizational processes, canonical interpretations can be retrieved from primary contexts, concerns, or pragmatics. But things can be more problematic when storage is performed for its own purpose, without formal reference context. That can be illustrated by legacy applications with binary code can be accompanied by self-documented source code, source with documentation, source with requirements, generated source with models, etc.
Documentation and Enterprise Architecture
Assuming that the governance of structured social organizations must be supported by comprehensive documentation, documents must be seen as a necessary and intrinsic component of enterprise architectures and their design should be aligned on concerns and capabilities.
As noted above, each of the basic functionalities comes with specific constraints; as a consequence a sound documentation policy should not mix functionalities. On that basis, documents should be defined by mapping purposes with users across enterprise architecture layers:
With regard to corporate environment, documentation requirements are set by legal constraints, directly (regulations and contracts) or indirectly (customary framework for transactions, traceability and audit).
With regard to organization, documents have to met two different objectives. As a medium of exchange they are meant to support the collaboration between organizational units, both at business level (processes) and across architecture levels. As an instrument of governance they are used to assess architecture capabilities and processes performances. Documents supporting those objectives are best kept separate if negative side effects are to be avoided.
With regard to systems functionalities, documents can be introduced for procurements (governance), development (exchange), and change (storage).
Within systems, the objective is to support operational deployment and maintenance of software components.
Documents’ purposes and users
The next step will be to integrate documents pertaining to actual environments and organization (brown background) with those targeting symbolic artifacts (blue background).
Models are used to describe actual or symbolic objects and behaviors
Rules can be seen as the glue holding together business, organization, and systems, and that may be a challenge for enterprise architects when changes are to be managed according to different concerns and different time-scales. Hence the importance of untangling rules upfront when requirements are captured and analysed.
How to outline the architectural footprint of rules (John Devlin)
Primary Taxonomy
As far as enterprise architecture is concerned, rules can be about:
Business and regulatory environments.
Enterprise objectives and organization.
Business processes and supporting systems.
That classification can be mapped to a logical one:
Rules set in business or regulatory environments are said to be deontic as they are to be met independently of enterprise governance. They must be enforced by symbolic representations if enterprise systems are to be aligned with environments.
Rules associated with objectives, organization, processes or systems are said to be alethic (aka modal) as they refer to possible, necessary or contingent conditions as defined by enterprise governance. They are to be directly applied to symbolic representations.
Whereas both are to be supported by systems, the loci will differ: system boundaries for deontic rules (coupling between environment and systems), system components for alethic ones (continuity and consistency of symbolic representations). Given the architectural consequences, rules should be organized depending on triggering (actual or symbolic) and scope (environment or enterprise):
Actual deontic rules are triggered by actual external events that must be processed synchronously.
Symbolic deontic rules are triggered by external events that may be processed asynchronously.
Actual alethic rules are triggered by business processes and must be processed synchronously.
Symbolic alethic rules are triggered by business processes and can be processed asynchronously.
Rules should be classified upfront with regard to triggering (actual or symbolic) and scope (environment or enterprise)
Footprint
The footprint of a rule is made of the categories of facts to be considered (aka rule domain), and categories of facts possibly affected (aka rule co-domain).
As far as systems are concerned, the first thing to do is to distinguish between actual contexts and symbolic representations. A naive understanding would assume rules to belong to either actual or symbolic realms. Given that the objective of modeling is to decide how the former should be represented by the latter, some grey imprints to be expected and dealt with using three categories of rules, one for each realm and the third set across the divide:
Rules targeting actual contexts. They can be checked through sensors or applied by actuators. Since rules enforcement cannot be guaranteed on non symbolic artifacts, some rules will have to monitor infringements and proscribed configurations. Example: “Cars should be checked on return from each rental, and on transfer between branches.”
Rules targeting symbolic representations. Their enforcement is supposedly under the full control of system components. Example: “A car with accumulated mileage greater than 5000 since its last service must be scheduled for service.”
Rules defining how changes in actual contexts should impact symbolic representations: what is to be considered, where it should be observed, when it should be recorded, how it should be processed, who is to be authorized. Example: ” Customers’ requests at branches for cars of particular models should be consolidated every day.”
Rules & Capabilities
That analysis should be carried out as soon as possible because rules set on the divide will determine the impact of requirements on architecture capabilities.
Semantics and Syntax
Rules footprints are charted by domains (what is to be considered) and co-domains (what is to be affected). Since footprints are defined by requirements semantics the outcome shouldn’t be contingent on formats.
From an architecture perspective the critical distinction is between homogeneous and heterogeneous rules, the former with footprint on the same side of the actual/symbolic divide, the latter with a footprint set across.
Homogeneous vs Heterogeneous footprints
Contrary to footprints, the shape given to rules (aka format, aka syntax,) is to affect their execution. Assuming homogeneous footprints, four basic blueprints are available depending on the way domains (categories of instances to be valued) and co-domains (categories of instances possibly affected) are combined:
Partitions are expressions used to classify facts of a given category.
Constraints (backward rules) are conditions to be checked on facts: [domain].
Pull rules (static forward) are expressions used to modify facts: co-domain = [domain].
Push rules (dynamic forward) are expressions used to trigger the modification of facts: [domain] > co-domain.
Pull vs Push Rule Management
Anchors & Granularity
In principle, rules targeting different categories of facts are nothing more than well-formed expressions combining homogeneous ones. In practice, because they mix different kinds of artifacts, the way they are built is bound to significantly bear on architecture capabilities.
Systems are tied to environments by anchors, i.e objects and processes whose identity and consistency must be maintained during their life-cycle. Rules should therefore be attached to anchors’ facets as to obtain as fine-grained footprints as possible:
Anchors’ facets
Features: domain and co-domain are limited to attributes or operations.
Object footprint: domain and co-domain are set within the limit of a uniquely identified instance (#), including composites and aggregates.
Connections: domain and co-domain are set by the connections between instances identified independently.
Collections: domain and co-domain are set between sets of instances and individuals ones, including subsets defined by partitions.
Containers: domain and co-domain are set for whole systems.
While minimizing the scope of simple (homogeneous) rules is arguably a straightforward routine, alternative options may have to be considered for the transformation of joint (heterogeneous) statements, e.g when rules about functional dependencies may be attached either to (1) persistent representation of objects and associations or, (2) business applications.
Heterogeneous (joint) Footprints
Footprints set across different categories will usually leave room for alternative modeling options affecting the way rules will be executed, and therefore bearing differently on architecture capabilities.
Business requirements: rules set at enterprise level that can be managed independently of the architecture.
System functionalities: rules set at system level whose support depends on architecture capabilities.
Quality of service: rules set at system level whose support depends on functional and technical architectures.
Operational constraints: rules set at platform level whose support depends on technical capabilities.
Rules do not necessarily fit into clear requirements taxonomy
While that classification may work fine for homogeneous rules (a), it may fall short for mixed ones, functional (b) or not (c). For instance:
“Gold Customers with requests for cars of particular models should be given an immediate answer.”
“Technical problems affecting security on checked cars must be notified immediately.”
As requirements go, rules interweaving business, functional, and non functional requirements are routine and their transformation should reflect how priorities are to be sorted out.
Moreover, if rule refactoring is to be carried out, there will be more than syntax and semantics to consider because almost every requirement can be expressed as a rule, often with alternative options. As a corollary, the modeling policies governing the making of rules should be set explicitly.
Sorting Out Mixed Rules
Taking into account that functional requirements describe how systems are meant to support business processes, some rules are bound to mix functional and business concerns. When that’s the case, preferences will have to be set with regard to:
Events vs Data: should system behavior be driven by changes in business context (as signaled by events from users, devices, or other systems), or by changes in symbolic representations.
Activities vs Data: should system behavior be governed by planned activities, or by the states of business objects.
Activities vs Events: should system behavior be governed by planned activities, or driven by changes in business context.
Taking the Gold Customer example, a logical rule (right) is not meant to affect the architecture, but expressed at control level (left) it points to communication capabilities.
How to express Gold customers’ rule may or may not point to communication capabilities.
The same questions arise for rules mixing functional requirements, quality of service, and operational constraints, e.g:
How to apportion response time constraints between endpoints, communication architecture, and applications.
How to apportion reliability constraints between application software and resources at location .
How to apportion confidentiality constraints between entry points, communication architecture, and locations.
Those questions often arise with non functional requirements and entail broader architectural issues and the divide between enterprise wide and domain specific capabilities.
While turf wars may play a part, the debate about Enterprise and Systems governance is rooted in a more serious argument, namely, how the divide between enterprise and systems architectures may affect decision-making.
Informed Decision_making (Eleanor Antin)
The answer to that question can be boiled down to four guidelines respectively for capabilities, functionalities, visibility, and uncertainty.
Architecture Capabilities
From an architecture perspective, enterprises are made of human agents, devices, and symbolic (aka information) systems. From a business perspective, processes combine three kinds of tasks:
Authority: deciding how to perform processes and make commitments in the name of the enterprise. That can only be done by human agents, individually or collectively.
Execution: processing physical or symbolic flows between the enterprise and its context. Any of those can be done by human agents, individually or collectively, or devices and software systems subject to compatibility qualifications.
Control: recording and checking the actual effects of processes execution. Any of those can be done by human agents, individually or collectively, some by software systems subject to qualifications, and none by devices.
Hence, and whatever the solutions, the divide between enterprise and systems will have to be aligned on those constraints:
Platforms and technology affects operational concerns, i.e physical accesses to systems and the where and when of processes execution.
Enterprise organization determines the way business is conducted: who is authorized to what (business objects), and how (business logic).
System functionalities sets the part played by systems in support of business processes.
Enterprise Architecture Capabilities
That gives the first guideline of systems governance:
Guideline #1 (capabilities): Objectives and roles must be set at enterprise level, technical constraints about deployment and access must be defined at platform level, and functional architecture must be designed as to get the maximum of the former subject to the latter’s constraints.
Informed Decisions: The Will to Know
At its core, enterprise governance is about decision-making and on that basis the purpose of systems is to feed processes with the relevant information so that agents can be put it to use as knowledge.
Those flows can be neatly described by crossing the origin of data (enterprise, systems, platforms) with the processes using the information (business, software engineering, services management):
Information processing begins with data, which is no more than registered facts: texts, numbers, sounds, visuals, etc. Those facts are collected by systems through the execution of business, engineering, and servicing processes; they reflect the state of business contexts, enterprise, and platforms.
Data becomes information when comprehensively and consistently anchored to identified constituents (objects, activities, events,…) of contexts, organization, and resources.
Information becomes knowledge when put to use by agents with regard to their purpose: business, engineering, services.
Information processing: from data to knowledge and back
Along that perspective, capabilities can be further refined with regard to decision-making.
Starting with business logic one should factor out decision points and associated information. That will determine the structure of symbolic representations and functional units.
Then, one may derive decision-making roles, together with implicit authorizations and access constraints. That will determine the structure of I/O flows and the logic of interactions.
Finally, the functional architecture will have to take into account synchronization and deployment constraints on events notification to and from processes.
Who should know What, Where, and When
That can be condensed into the second guideline of system governance:
Guidelines #2 (functionalities): With regard to enterprise governance, the role of systems is to collect data and process it into information organized along enterprise concerns and objectives, enabling decision makers to select and pull relevant information and translate it into knowledge.
Qualified Information: The Veils of Ignorance
Ideally, decision-making should be neatly organized with regard to contexts and concerns:
Contexts are set by architecture layers: enterprise organization, system functionalities, platforms technology.
Concerns are best identified through processes: business, engineering, or supporting services.
Qualified Information Flows across Architectures and Processes
Actually, decisions scopes overlap and their outcomes are interwoven.
While distinctions with regard to contexts are supposedly built-in at the source (enterprise, systems, platforms), that’s not the case for concerns whose distinction usually calls for reasoned choices supported by different layers of governance:
Assets: shared decisions whose outcome bears upon several business domains and cycles. Those decisions may affect all architecture layers: enterprise (organization), systems (services), or platforms (purchased software packages).
Users’ Value: streamlined decisions governed by well identified business units providing for straight dependencies from enterprise (business requirements), to systems (functional requirements) and platforms (users’ entry points).
Non functional: shared decisions about scale and performances affecting users’ experience (organization), engineering (technical requirements), or resources (operational requirements).
Qualified Information and Decision Making
As epitomized by non functional requirements, those layers of governance don’t necessarily coincide with the distinction between business, engineering, and servicing concerns. Yet, one should expect the nature of decisions be set prior the actual decision-making, and decision makers be presented with only the relevant information; for instance:
Functional requirements should be decided given business requirements and services architecture.
Scalability (operational requirements) should be decided with regard to enterprise’s objectives and organization.
Hence the third guideline of system governance:
Guideline #3 (visibility): Systems must feed processes with qualified information according to contexts (business, organization, platforms) and governance level (assets, user’s value, operations) of decision makers.
Risks & Opportunities: Mining Beyond Visibility
Long secure behind organizational and technical fences, enterprises must now navigate through open digitized business environments and markets. For business processes it means a seamless integration with supporting applications; for corporate governance it means keeping track of risks and opportunities in changing business contexts while assessing the capability of organizations and systems to cope, adjust, and improve.
On one hand risks and opportunities take root beyond the horizon and are not supposed to square with established information models; but on the other hand deep learning technologies is revolutionizing data analytics. purpose ontologies could be used to bring architectures and environments modeling into a common paradigm.
Hence the fourth guideline of system governance:
Guideline #4 (uncertainty): assuming that business edge is built on unqualified information about risks or opportunities, explicit and implicit knowledge should be processed within shared conceptual frames; that can be achieved with ontologies.
Development processes start with requirements and wind up in code; in between there isn’t much of a consensus among the software engineering community about how to define the scope (spaces), how to sequence the tasks (paths), and how to time deliveries (paces). On one side of the debate phased approaches hope for fixed spaces and ordered paths but often get entangled in moving lines. On the other side of the debate agile teams try to find their space by increments but risk losing the path while still on their way.
Maze revisited: finding a path while building the space (Ibrahim El-Salahi)
This lack of agreed upon concepts and principles entrusts personal skills and best practices as primary success factors. Conversely, that could explain the rate of failures for software projects, significantly higher than for “hard” engineering ones; given the quasi absence of physical constraints, the opposite would have been expected, which would suggest some critical intrinsic flaw.
With the “benefits” of hindsight and agile assessment of waterfall flaws, the focus has been put on fixed scope and schedule, in particular with regard to requirements and quality management:
Fixed requirements set upfront: since there is an inverse relationship between the level of details and the reliability and stability of requirements, staking the whole project on requirements fully defined at such an early time is arguably a very hazardous policy.
Quality as an afterthought: given that finding defects is not very gratifying when undertaken in isolation, delegating the task will offer few guarantees if not associated with rewards commensurate to findings; moreover, quality as a detached concern may easily turn into a collateral damage when set along mounting costs and scheduling constraints. Alternatively, quality checks may change into a more positive endeavor when conducted as an intrinsic part of development.
Agile answer to those failings has been to conduct specifications, development, and quality assurance into integrated iterations. As a consequence, the definition of scope becomes a byproduct of development cycles, with requirements itemized as features in order to be developed progressively. Moreover, with specifications and schedules managed dynamically, timetables become impracticable and deliveries can only be carried out by shuttles.
The agile “reformation” has open new perspectives and beget many fruitful practices, and the objective here is to see how those approaches of scope and schedule can be reformulated within the perspective of architecture layers. This part examines the congruence between the alternate flows of use cases and the backlog of users’ stories, and considers their complementarity as path-finders. The second part will focus on the role of time-boxes as pace-makers and the benefits for quality assurance.
Architectures and Projects Scope
Whatever the compass, agile or phased, projects footprint can be set across three architecture layers:
Enterprise architectures describe business environments and objectives, resources and regulatory constraints.
System architectures describe enterprises in terms of functional entities of human agents and physical and software assets.
Technical architectures describe the platforms supporting functional entities.
Architecture layers vs Processes
Projects are meant to carry out changes within architectures initiated by business, engineering, or services management processes:
Business processes are defined by business environment and objectives. Changes may have to deal with domains and activities, organization and supported operations, and quality of service as experienced by users.
Engineering processes focus on the development of software systems supporting business processes: business domains and applications, system functionalities, platform implementations.
Services management stand between engineering deliveries and operational concerns: location of assets, access to services, releases deployment, and systems configuration.
While development projects may (and will usually) cross architecture layers, their roots and stakes should nonetheless be clearly positioned if projects are to be planned within the respective time-spans, governed by the relevant authority, and their products accepted by the right stakeholders.
Development Project, from Requirements to Deployments
That put projects governance at crossroads between (a) business objectives set by market opportunities, (b) the deployment of features into functional architectures, and (c) the deployment of releases according to changes in technical architecture. With phased developments, scope and schedules are fixed upfront, which means that the business layer forces its time-frame over the ones of system and technical layers, which may introduce frictions regarding scope as well as quality:
With regard to scope, frictions stem from features and schedules set fully and definitively at enterprise level, independently of any feedback from functional and technical layers.
With regard to quality, frictions stem from tests performed at technical layer when scope and schedules can no longer be revised in case of negative outcomes.
The consequences are all too easy to observe, with business needs partially satisfied and software quality sacrificed. Hence the need of a balanced approach that would consolidate the different maps and time-frames in order to minimize frictions between layers.
Mapping Project Scope
Projects scope can be described along two dimensions, one set by business logic, the other by system functionalities:
First, one have to circumscribe the business variants to be taken into consideration. For that purpose the project footprint, first introduced as users’ stories, will have to be documented by activity or business process diagrams.
Then, the project scope will have to mark out the subset of business requirements to be supported by system functionalities. That will usually be done with use cases describing interactions between system and users.
Complementary descriptions of projects footprints: use cases (interactions between users and system) and activity diagrams (business logic).
That makes those descriptions both orthogonal and complementary: orthogonal because use cases cut across activity diagrams, complementary because use cases are meaningless without targeted activities.
More importantly, they are associated with different architecture layers and governed by different concerns:
At business level (business processes or activities), the perimeter and granularity of requirements must be congruent with the continuity and consistency constraints of business objects and operations.
At functional level (use cases), the span and granularity of interactions between system and users must coincide with execution paths. But the rationale governing users interactions is not the same as the one governing the integrity of business processes. As a consequence, the paths considered for development may pick sequences of operations defined by business processes but should not define them anew based upon interaction constraints.
Finally, assuming that use cases see systems as black-boxes, their footprint should not depend on decisions taken at technical level.
Those concerns can be dealt with separately if projects scope is explored iteratively, e.g using activity diagrams for business logic and use case diagrams for users interactions.
Iterative Mapping of Project Footprint
Iterative development is not just about increments but, first and foremost, about exploring development spaces. That is especially useful when projects overlap architecture layers and cannot rely on fully fledged requirements.
Such projects have to deal with two challenges:
They must identify and manage work units according to the state of requirements and the nature of dependencies (business, organization, or technology, …).
They must carry on with developments based on incomplete specifications while exploring alternatives and deferring decisions until the “last responsible moment” when further delay would limit the options at hand.
Taking a leaf out of the agile book, projects should be driven by users’ value, with requirements first introduced as users’ stories. From that springboard, as informal and incomplete as could be, stories must be fleshed out and organized in order to support the reasoned exploration of project scope.
At inception stories are no more than a user, an objective, and an activity, all set at business level independently of the part played by systems. Scope exploration must therefore begin with activities backbone and be furthered with variants, aka scenarii.
Adding execution paths to project scope
Given a set of business scenarii, the candidates for system support must be ordered and mapped to system features, actual or planned. That should provide a blueprint for development paths. Unfortunately, as variants are added to plots, narratives can easily turn messy, mixing features and capabilities across architecture layers. And that’s where the benefits of use cases are to be found.
Development Paths: From Users’ Stories to Use Cases
Whatever the context, iterations are formal constructs defined by invariants, increments, and exit conditions. When applied to development spaces, iterations are defined by:
Invariants: conditions on architectural assets supporting the scenario under consideration.
Increments: features or variants added to scenarii.
Exit condition: no more features or variants (empty backlog) or time-out.
Applied to architecture layers, invariants provide for reasoned iterations and backlogs:
Enterprise layer are the first to be considered: cycles are set for persistency and execution units and bound by domains (identification mechanisms, integrity constraints, and semantics); within cycles, increments target attributes, operations and variants.
Functional layer come second: cycles are set for interaction units (aka use cases), and bound by the continuity and consistency business objects and activities; increments target transient attributes and operations.
Technical layer come last: cycles are set for platforms and bound by functional units.
But there is a catch: while users’ stories and activity (or business process) diagrams are set at enterprise level, development projects are considered at system level; because systems functionalities are not supposed to appear in users’ stories or activity diagrams, there could be a gap between business and functional requirements. As it happens, use cases provide a bridge: on one hand they focus on the interactions between users and systems, on the other hand their basic and alternate flows can be directly mapped to the paths in activity diagrams.
From alternative flows to Development Paths
That provides a clear and sound basis for the definition of development paths: on one hand alternate flows can be ranked according users’ priorities; on the other hand they determine the sequence of use cases that will have to be developed.
Backlogs and Pathfinders
While the objective of users’ stories is to tie up projects in business value, the objective of use cases is to anchor them in the context of system functionalities. That perspective, and the role of models, may be ignored for standalone projects, but it is necessary when project development paths are to be governed both by business and functional dependencies, described respectively by users’ stories and use cases.
In that case the exploration of development paths should be guided by invariants set along MDA model layers: computation independent (business processes), platform independent (systems functionalities), and platform specific (technology platforms).
Projects are rooted in use cases but development paths are governed by users’ stories.
When projects are rooted in business activities (a), e.g the possibility of upgrading a customer, stories describe execution paths and are ranked according business priorities. Iterations will proceed with development and new cycles added for alternative paths to the basic one.
Depending on context dependencies, development projects can be directly initiated from given sequences of activities (b) or conducted in parallel with users’ stories. Use cases remain the option of choice when the features supporting users’ stories are meant to be shared (e.g checkout). In that case the development paths are governed both by users’ value and functional dependencies. When features are deemed specific (e.g upgrade), use cases can be bypassed and development paths explored simultaneously according users’ and development concerns.
Backlog organization is more complex when development paths cross the divide between functional and technical concerns. Ideally, one would expect a clear separation of concerns, with use cases defined independently of technical options, just like business logic doesn’t depend on system functionalities. But alternatives may be blurred due to the dependencies between interactions design and platform capabilities, the risk being to associate technical options with functional variants, e.g specialized use cases.
Entangled development paths: self check out depends on technical platform.
That’s the case when features can only be implemented on specific platforms. If those features are also specific the corresponding development cycle can be managed as a whole. Otherwise the relevant decisions should be factored out. The same principle applies for features supporting different business processes.
Squaring the Circles: From Epics to Releases
Iterations run within boundaries set by invariants, and with regard to projects scope, those invariants are set by architecture capabilities: enterprise on one hand, systems on the other hand.
From the enterprise perspective, development projects (b) are meant to support business objectives (a), not to define them. As a consequence, users’ stories must remain within borders set upfront. That can be achieved by introducing business projects (aka strategies, aka epics) and portfolios of development ones.
Development Paths: Portfolio of business objectives (a), associated backlogs of users’ stories (b), targeted features (c), architectural capabilities (d), and releases (e).
From the system perspective, a clear distinction should be maintained between projects supported by platforms capabilities (b), and projects targeting platforms capabilities (d). Eventually, those different levels of explorations will have to be consolidated as releases (e), and that is where one may find the agile answer to waterfall.
A Time for Every Purpose: Time-boxes as Pace-Makers
As Einstein famously said, “The only reason for time is so that everything doesn’t happen at once.” In other words time is what happens between events, and the use of a single time-frame will put all events under the same rationale.
But architectures are best understood as shearing layers whose events are governed by different rationales, respectively: business opportunities, engineering constraints, or operational needs.
That is arguably the critical flaw of waterfall solutions as they force business, development, and operations under the same set of strictures. And that’s why agile’s solution to components release may be its pivotal innovation as it establishes the autonomy of those three layers and introduces time-boxes as their pace-makers.
