Category: Requirements Analysis

Requirements in Digital Environments

Symbolic environment (National Gallery, Canberra, Australia).

Preamble

Beyond varying names, requirements have often been classified into four basic categories:

  1. Process requirements deal with organization and business processes independently of the part played by supporting systems.
  2. Application requirements deal with the part played by supporting systems in the realization of processes requirements..
  3. Quality of Service requirements deal with users experience independently of symbolic contents.
  4. Technical requirements deal with the implementation of systems functions independently of users experience.
A customary requirements taxonomy

Yet, regardless of the soundness of these categories, their effectiveness varies with contexts, and contexts have been drastically disrupted with enterprises immersion in digital environments.

Digital Disruption

With the generalization of digital environments and the ensuing intermingling of business processes and IT two established distinctions are losing their grip, first between processes and applications, and then between users and systems.

Before and after digital disruption

For processes, the blurring is to concern non deterministic operations (heuristics, non modal logic, learning, …) that used to be the prerogative of humans but are now commonly carried out by artificial brains set in applications (a), user interface (d), or elsewhere (b). As a corollary, user interfaces are losing their homogeneity, as single systems with established codes of conduct are being replaced by an undefined number of unidentified agents (c, d).

Lest they drive enterprises into dead ends requirements have to map their systems according to the new digital territories. Not surprisingly, that can be best achieved using the symbolic/non symbolic distinction.

Requirements associated with symbolic contents.. Given that symbolic expressions can be reformulated, the granularity of these requirements can always be adjusted as to fall into single domains and therefore under the authority of clearly identified owners or stakeholders.

Requirements not dealing with symbolic contents. Since they cannot be uniquely tied to symbolic flows between systems and business contexts, nothing can be assumed regarding the identity of stakeholders. Yet, as they target systems features and behaviors, they can still be associated with architecture levels: enterprise, functional, technical.

Functional Requirements

As commonly understood, functional requirements cover business concerns and the part supported by systems; as such they can be aligned with enterprise architecture capabilities, symbolic (roles, business entities, business logic), and non symbolic (physical objects and locations, time-frames, events, processes execution).

In order to deal with the blurring induced by digital flows, requirements should ensure the transparency and traceability of interactions:

  • Transparency: users should be continuously aware of the kind of agent in charge behind the screen.
  • Traceability: users should be able to ask for explanations about every outcome.

As noted above, such requirements cannot be circumscribed to users interfaces or even applications as they involve the whole of the knowledge architecture . To that end functional requirements should be organized in relation to enterprise architecture capabilities, and include the necessary extensions for knowledge architecture:

  • When agents/roles assignments remain open requirements should include communication (natural, symbolic, or digital) and cognitive capabilities.
  • Assuming that requirements are not limited to modeled information, the distinction between data, information, and knowledge should be explicit.
  • Likewise for non deterministic reasoning used in business logic.
Functional requirements and Capabilities

Requirements concerning the digital capabilities of entry-points and time-frames of processes execution are to be added in order to associate functional and quality of service requirements.

Non Functional Requirements

Non functional requirements (NFRs) are meant to encompass whatever remain which cannot be tied to symbolic representations.

As should be expected for leftover categories, non functional requirements are by nature a mixed bag of overlapping items straddling the line between systems and applications depending on whether they directly affect users experience (quality of service), or are of the sole concern of architects and engineers (technical requirements).

The heterogeneity of non functional requirements is compounded by the mirror impact of the digital transformation on functional ones when business requirements (e.g high-frequency trading) combine performances with “intelligent” computing (e.g. machine learning capabilities).

Quality of Service and Capabilities

Yet, that is not to say that the distinction is arbitrary; in fact it conveys an implicit policy regarding architecture capabilities: defining elapse time as functional means that high-frequency traders will be supported by their own communication network and workstations, otherwise they will be dependent upon the company technical architecture, managed by a separate organizational unit, governed by its own concerns and policies.

On that account the digital transformation may help to clarify the issue of non functional requirements because all requirements, functional or otherwise can now be framed uniformly and therefore discriminate more easily.

FURTHER READING

Semantic Interoperability: Stories & Cases

Preamble

For all intents and purposes, digital transformation has opened the door to syntactic interoperability… and thus raised the issue of the semantic one.

Cooked Semantics (Urs Fisher)

To put the issue in perspective, languages combine four levels of interpretation:

  • Syntax: how terms can be organized.
  • Lexical: meaning of terms independently of syntactic constructs.
  • Semantic: meaning of terms in syntactic constructs.
  • Pragmatic: semantics in context of use.
Languages levels of interpretation

At first, semantic networks (aka conceptual graphs) appear to provide the answer; but that’s assuming flat ontologies (aka thesaurus) within which all semantics are defined at the same level. That would go against the objective of bringing the semantics of business domains and systems architectures under a single conceptual roof. The problem and a solution can be expounded taking users stories and use cases for examples.

Crossing stories & cases

Beside the difference in perspectives, users stories and use cases stand at a methodological crossroad, the former focused on natural language, the latter on modeling. Using ontologies to ensure semantic interoperability is to enhance both traceability and transparency while making room for their combination if and when called for.

Set at the inception of software engineering processes, users’ stories and use cases mark an inflexion point between business requirements and supporting systems functionalities: where and when are determined (a) the nature of interfaces between business processes and systems components and, (b) how to proceed with development models, iterative or model based.

Users’ stories are part and parcel of Agile development model, their backbone, engine, and fuel. But as far as Agile is concerned, users’ stories introduce a dilemma: once being told stories are meant to be directly and iteratively put down in code; documenting them in words would bring back traditional requirements and phased development. Hence the benefits of sorting out and writing up the intrinsic elements of stories as to ensure the continuity and consistency of engineering processes, whether directly to code, or through the mediation of use cases.

To that end semantic interoperability would have to be achieved for actors, events, and activities.

Actors & Events

Whatever architectures or modeling methodologies, actors and events are sitting on systems’ fences, which calls for semantics common to enterprise organization and business processes on one side of the fence, supporting systems on the other side.

To begin with events, the distinction between external and internal ones is straightforward for use cases, because their purpose is precisely to describe the exchanges between systems and environments. Not so for users stories because at their stage the part to be played by supporting systems is still undecided, and by consequence the distinction between external and internal events.

With regard to actors, and to avoid any ambiguity, a semantic distinction could be maintained between roles, defined by organizations, and actors (UML parlance), for roles as enacted by agents interacting with systems. While roles and actors are meant to converge with analysis, understandings may initially differ across the fence between users stories and use cases, to be reconciled at the end of the day.

Representations should support the semantic distinctions as well as trace their convergence.

That would enable use cases and users stories to share overlapping yet consistent semantics for primary actors and external events:

  • Across stories: actors contributing to different stories affected by the same events.
  • Along processes: use cases set for actors and events defined in stories.
  • Across time-frames: actors and events first introduced by use cases before being refined by “pre-sequel” users stories.

Such ontology-based representations are to support full iterative as well as parallel developments independently of the type of methods, diagrams or documents used by projects.

activities

Users’ stories and use cases are set in different perspectives, business processes for the former, supporting systems for the latter. As already noted, their scopes overlap for events and actors which can be defined upfront providing a double distinction between roles (enterprise view) and actors (systems view), and between external and internal events.

Activities raise more difficulties because they are meant to be defined and refined across the whole of engineering processes:

  • From business operations as described by users to business functions as conceived by stakeholders.
  • From business logic as defined in business processes to their realization as defined in diagram sequences.
  • From functional requirements (e.g users authentication or authorization) to quality of service.
  • From primitives dealing with integrity constraints to business policies managed through rules engines.

To begin with, if activities have to be consistently defined for both users’ stories and use cases, their footprint should tally the description of actors and events stipulated above; taking a leaf from Aristotle rule of the three units, activity units should therefore:

  • Be triggered by a single event initiated by a single primary actor.
  • Be located into a single physical space with all resources at hand.
  • Timed by a single clock controlling accesses to all resources.

On that basis, the refinement of descriptions could go according to the nature of requirements: business (users’ stories), or functional and quality of service (use cases) .

Activities (execution units) should be tally with roles, events, and location.
Use cases wrap computation independent activities into transactions.

As far as ontologies are concerned, the objective is to ensure the continuity and consistency of representations independently of modeling tools and methodologies. For activities appearing in users stories and use cases, that would require:

  • The description of activities in relation with their business background, their execution in processes, and the corresponding functions already supported by systems.
  • The progressive refinement of roles (users, devices, other systems), location, and resources (objects or surrogates).
  • An unified definition of alternatives in stories (branches) and use cases (extension points)

The last point is of particular importance as it will determine how business and functional rules are to be defined and control implemented.

Knitting semantics: symbolic representations

The scope and complexity of semantic interoperability can be illustrated a contrario by a simple activity (checking out) described at different levels with different methods (process, use case, user story), possibly by different people at different time.

The Check-out activity is first introduced at business level (process), next a specific application is developed with agile (user story), and then extended for variants according to channels (use case).

Semantic interoperability between projects, domains, and methods.

Assuming unfettered naming (otherwise semantic interoperability would be a windfall), three parties can be mentioned under various monikers for renters, drivers, and customers.

In a flat semantic context renter could be defined as a subtype of customer, itself a subtype of party. But that option would contradict the neutrality objective as there is no reason to assume a modeling consensus across domains, methods, and time.

  • The ontological kernel defines parties and actors, as roles associated to agents (organization level).
  • Enterprises define customers as parties (business model).
  • Business unit can defines renters in reference to customers (business process) or directly as a subtype of role (user story).
  • The distinction between renters and drivers can be introduced upfront or with use cases’ actors.

That would ensure semantic interoperability across modeling paradigms and business domains, and along time and transformations.

Probing semantics: metonymies and metaphors

Once established in-depth foundations, and assuming built-in basic logic and lexical operators, semantic interoperability is to be carried out with two basic linguistic contraptions: metonymies and metaphors .

Metonymies and metaphors are linguistic constructs used to substitute a word (or a phrase) by another without altering its meaning, respectively through extensions and intensions, the former standing for the actual set of objects and behaviors, the latter for the set of features that characterize these instances.

Metonymy relies on contiguity to substitute target terms for source ones, contiguity being defined with regard to their respective extensions. For instance, given that US Presidents reside at the White House, Washington DC, each term can be used instead.

Metonymy use physical or functional proximity (full line) to match extensions (dashed line)

Metaphor uses similarity to substitute target terms for source ones, similarity being defined with regard to a shared subset of features, with leftovers taken out of the picture.

Metaphor uses similarity to match descriptions

Compared to basic thesaurus operators for synonymy, antonymy, and homonymy, which are set at lexical level, metonymy and metaphor operate at conceptual level, the former using set of instances (extensions) to probe semantics, the latter using descriptions (intensions).

Applied to users stories and use cases:

  • Metonymies: terms would be probed with regard to actual sets of objects, actors, events, and execution paths (data from operations) or mined from digital environments.
  • Metaphors: terms for stories, cases, actors, events, and activities would be probed with regard to the structure and behavior of associated descriptions (intensions).

Compared to the shallow one set at thesaurus level for terms, deep semantic interoperability encompasses all ontological dimensions, from actual instances to categories, aspects, and concepts. As such it can take full advantage of digital transformation and deep learning technologies.

further reading

Squared Outline: Actors


UML Actors (aka Roles) are meant to provide a twofold description of interactions between systems and their environment: organization and business process on one hand, system and applications on the other hand.

That can only be achieved by maintaining a conceptual distinction between actual agents, able to physically interact with systems, and actors (aka roles), which are their symbolic avatars as perceived by applications.

As far as the purpose is to describe interactions, actors should be primary characterized by the nature of language (symbolic or not), and identification coupling (biological or managed):

  1. Symbolic communication, no biological identification (systems)
  2. Analog communication, no biological identification (active devices or equipments)
  3. Symbolic communication, biological identification (people)
  4. Analog communication, biological identification (live organisms)

While there has been some confusion between actors (or roles) and agents, a clear-cut distinction is now a necessity due to the centrality of privacy issues, whether it is from business or regulatory perspective.

FURTHER READING

Squared Outline: States

States are used to describe relevant aspects in contexts and how the changes are to affect systems representations and behaviors.

On that account, events and states are complementary: the former are to notify relevant changes, the latter are to represent the partitions (²) that makes these changes relevant. Transitions are used to map the causes and effects of changes.

  1. State of physical objects.
  2. State of processes’ execution.
  3. State of actors’ expectations.
  4. State of symbolic representations.

Beside alignment with events, defining states consistently across objects, processes, and actors is to significantly enhance the traceability and transparency of architectures designs.

FURTHER READINGS

Squared Outline: Cases vs Stories

Use cases and users’ stories being the two major approaches to requirements, outlining their respective scope and purpose should put projects on a sound basis.

Cases & Stories

To that end requirements should be neatly classified with regard to scope (enterprise or system) and level (architectures or processes).

  • Users stories are set at enterprise level independently of the part played by supporting systems.
  • Use cases cut across users stories and consider only the part played by supporting systems.
  • Business stories put users stories (and therefore processes) into the broader perspective of business models.
  • Business cases put use cases (and therefore applications) into the broader perspective of systems capabilities.

Position on that simple grid should the be used to identify stakeholders and pick between an engineering model, agile or phased.

FURTHER READING

Squared Outline: Activity

As far as modeling is concerned a distinction has to be maintained between the symbolic description of activities and the processes describing their actual execution.

Given that distinction, the objective is to align action semantics with the constraints of their execution:

  1. Action on symbolic representations without coupling with the context (no change).
  2. Action on symbolic representations with coupling with context (change in expectations).
  3. Interaction with actual context without direct coupling (change in process status).
  4. Interaction with actual context with direct coupling  (change in objects).

That taxonomy can then be applied to map use cases semantics to architecture capabilities.

Squared Outline: Time-frames

Time-frames are defined by root events and therefore best defined along the same guideline, namely their scope and the nature of coupling. 

Along that understanding, time-frames can be defined with regard to context (symbolic or actual) and coupling (asynchronous or synchronous):

  1. Symbolic, no coupling: time-frames set by internal events, involving a single actor.
  2. Symbolic, coupling: time-frames set by external events, involving a single actor.
  3. Actual, asynchronous: time-frames set by external events, involving different actors without real-time constraint.
  4. Actual, synchronous: time-frames set by external events, involving different actors with real-time constraint.

That taxonomy could be used to align time-frames with processes‘ execution mode.

Squared Outline: Requirements

Depending on context and purpose requirements can be understood as customary documents, contents, or work in progress.

  1. Given that requirements are the entry point of engineering processes, nothing should be assumed regarding their form (natural, formal, or specific language), or content (business, functional, non-functional, or technical).
  2. Depending on the language used, requirements can be directly analyzed and engineered, or may have to be first formatted (aka captured).
  3. Requirements taxonomy should be set with regard to processes (business or architecture driven) and stakeholders (business units or enterprise architecture).
  4. Depending on content and context, requirements can be engineered as a whole (agile development models), or set apart as to tally with external dependencies (phased development models).

Further Reading

Focus: Users’ Stories & Use Cases

Preamble

Agile and phased development solutions are meant to solve different problems and therefore differ with artifacts and activities; that can be illustrated by requirements, understood as dialogs for the former, etched statements for the latter.

Kara_Walker_mural2
Running Stories (Kara Walker)

Ignoring that distinction is to make stories stutter from hiccupped iterations, or phases sputter along ripped milestones.

Agile & Phased Tell Different Stories Differently

As illustrated by ill-famed waterfall, assuming that requirements can be fully set upfront often put projects at the hazards of premature commitments; conversely, giving free rein to expectations could put requirements on collision courses.

That apparent dilemma can generally be worked out by setting apart business outlines from users’ stories, the latter to be scripted and coded on the fly (agile), the former analysed and documented as a basis for further developments (phased). To that end project managers must avoid a double slip:

  • Mission creep: happens when users’ stories are mixed with business models.
  • Jump to conclusions: happens when enterprise business cases prevail over the specifics of users’ concerns.

Interestingly, the distinction between purposes (users concerns vs business functions) can be set along one between language semantics (natural vs modeling).

Semantics: Capture vs Analysis

Beyond methodological contexts (agile or phased), a clear distinction should be made between requirements capture (c) and modeling (m): contrary to the former which translates sequential specifications from natural to programming (p) languages without breaking syntactic and semantic continuity, the latter carries out a double translation for dimension (sequence vs layout) and language (natural vs modeling.)

Scratch_lang
Semantic continuity (c>p) and discontinuity (c>m>p)

The continuity between natural and programming languages is at the root of the agile development model, enabling users’ stories to be iteratively captured and developed into code without intermediate translations.

That’s not the case with modeling languages, because abstractions introduce a discontinuity. As a corollary, requirements analysis is to require some intermediate models in order to document translations.

The importance of discontinuity can be neatly demonstrated by the use of specialization and generalization in models: the former taking into account new features to characterize occurrences (semantic continuity), the latter consolidating the meaning of features already defined (semantic discontinuity).

Confusion may arise when users’ stories are understood as a documented basis for further developments; and that confusion between outcomes (coding vs modeling) is often compounded by one between intents (users concerns vs business cases).

Concerns: Users’ Stories vs Business Cases

As noted above, users’ stories can be continuously developed into code because a semantic continuity can be built between natural and programming languages statements. That necessary condition is not a sufficient one because users’ stories have also to stand as complete and exclusive basis for applications.

Such a complete and exclusive mapping to application is de-facto guaranteed by continuous and incremental development, independently of the business value of stories. Not so with intermediate models which, given the semantic discontinuity, may create back-doors for broader concerns, e.g when some features are redefined through generalization. Hence the benefits of a clarity of purpose:

  • Users’ stories stand for specific requirements meant to be captured and coded by increments. Documentation should be limited to application maintenance and not confused with analysis models.
  • Use cases should be introduced when stories are to be consolidated or broader concerns factored out , e.g the consolidation of features or business cases.

Sorting out the specifics of users concerns while keeping them in line with business models is at the core of business analysts job description. Since that distinction is seldom directly given in requirements, it could be made easier if aligned on modeling options: stories and specialization for users concerns, models and generalization for business features.

From Stories to Cases

The generalization of digital environments entails structural and operational adjustments within enterprise architectures.

At enterprise level the integration of homogeneous digital flows and heterogeneous symbolic representations can be achieved through enterprise architectures and profiled ontologies. But that undertaking is contingent on the way requirements are first dealt with, namely how the specifics of users’ needs are intertwined with business designs.

As suggested above, modeling schemes could help to distinguish as well as consolidate users narratives and business outlooks, capturing the former with users’ stories and the latter with use cases models.

Scratch_USC1
Use cases describe the part played by systems taking into account all supported stories.

That would neatly align means (part played by supporting systems) with ends (users’ stories vs business cases):

  • Users’ stories describe specific objectives independently of the part played by supporting systems.
  • Use cases describe the part played by systems taking into account all supported stories.

It must be stressed that this correspondence is not a coincidence: the consolidation of users’ stories into broader business objectives becomes a necessity when supporting systems are taken into account, which is best done with use cases.

Aligning Stories with Cases

Stories and models are orthogonal descriptions, the former being sequenced, the latter laid out; it ensues that correspondences can only be carried out for individuals uniformly identified (#) at enterprise and systems level, specifically: roles (aka actors), events, business objects, and execution units.

Scratch_US2C
Crossing cases with stories: events, roles, business objects, and execution units must be uniformly and consistently identified (#) .

It must be noted that this principle is supposed to apply independently of the architectures or methodologies considered.

With continuity and consistency of identities achieved at architecture level, the semantic discontinuity between users’ stories and models (classes or use cases) can be managed providing a clear distinction is maintained between:

  • Modeling abstractions, introduced by requirements analysis and applied to artifacts identified at architecture level.
  • The semantics of attributes and operations, defined by users’ stories and directly mapped to classes or use cases features.
Scratch_USC3
From Capture to Analysis: Abstractions introduce a semantic discontinuity

Finally, stories and cases need to be anchored to epics and enterprise architecture.

Business Cases & Enterprise Stories

Likening epics to enterprise stories would neatly frame the panoply of solutions:

  • At process level users’ stories and use cases would be focused respectively on specific business concerns and supporting applications.
  • At architecture level business stories (aka epics) and business cases (aka plots) would deal respectively with business models and objectives,  and supporting systems capabilities.
Cases & Stories

That would provide a simple yet principled basis for enterprise architectures governance.

Further Reading

External Links

Squaring Software To Value Chains

Preamble

Digital environments and the ubiquity of software in business processes introduces a new perspective on value chains and the assessment of supporting applications.

Michel Blazy plante
Business & Supporting Processes (Michel Blazy)

At the same time, as software designs cannot be detached of architectures capabilities, the central question remains of allocating costs and benefits between primary and support activities .

Value Chains & Activities

The concept of value chain introduced by Porter in 1985 is meant to encompass the set of activities contributing to the delivery of a valuable product or service for the market.

porter1.png
Porter’s generic model

Taking from Porter’s generic model, various value chains have been refined according to business specific categories for primary and support activities.

Whatever their merits, these approaches are essentially static and fall short when the objective is to trace changes induced by business developments; and that flaw may become critical with the generalization of digital business environments:

  • Given the role and ubiquity of software components (not to mention smart ones), predefined categories are of little use for impact analysis.
  • When changes in value chains are considered, the shift of corporate governance towards enterprise architecture puts the focus on assets contribution, cutting down the relevance of activities.

Hence the need of taking into account changes, software development, and enterprise architectures capabilities.

Value Added & Software Development

While the growing interest for value chains in software engineering is bound to agile approaches and business driven developments, the issue can be put in the broader perspective of project planning.

With regard to assessment, stakeholders, start with business opportunities and look at supporting systems from a black box perspective; in return, software providers are to analyze requirements from a white box perspective, and estimate corresponding development effort and time delivery.

Assuming transparency and good faith, both parties are meant to eventually align expectations and commitments with regard to features, prices, and delivery.

With regard to policies, stakeholders put the focus on returns on investment (ROI), obtained from total cost of ownership, quality of service, and timely delivery. Providers for their part try to minimize development costs while taking into account effective use of resources and costs of opportunities. As it happens, those objectives may be carried on as non-zero sum games:

  • Business stakeholders foretell the actualized returns (a) to be expected from the functionalities under consideration (b).
  • Providers consider the solutions (b’) and estimate actualized costs (a’).
  • Stakeholders and providers agree on functionalities, prices and deliveries (c).

ReksRings_NZSG
Developing the value chain

Assuming that business and engineering environments are set within different time-frames, there should be room for non-zero-sum games winding up to win-win adjustments on features, delivery, and prices.

Continuous vs Phased Alignments

Notwithstanding the constraints of strategic planning, business processes are by nature opportunistic, and their ability to be adjusted to circumstances is becoming all the more critical with the generalization of digital business environments.

Broadly speaking, the squaring of supporting applications to business value can be done continuously or by phases:

  • Phased alignments start with some written agreements with regard to features, delivery, and prices before proceeding with development phases.
  • Continuous alignment relies on direct collaboration and iterative development to shape applications according to business needs.

ReksRings_PhasCont
Phased vs Continuous Adjustments

Beyond sectarian controversies, each approach has its use:

  • Continuous schemes are clearly better at harnessing value chains, providing that project teams be allowed full project ownership, with decision-making freed of external dependencies or delivery constraints.
  • Phased schemes are necessary when value chains cannot be uniquely sourced as they take roots in different organizational units, or if deliveries are contingent on technical constraints.

In any case, it’s not a black-and-white alternative as work units and projects’ granularity can be aligned with differentiated expectations and commitments.

Work Units & Architecture Capabilities

While continuous and phased approaches are often opposed under the guises of Agile vs Waterfall, that understanding is misguided as it extends the former to a motley of self-appointed agile schemes and reduces the latter to an ill-famed archetype.

Instead, a reasoned selection of a development models should be contingent on the problems at hand, and that can be best achieved by defining work-units bottom-up with regard to the capabilities targeted by requirements:

ReksRings_Capabs.jpg
Work units should be defined with regard to the capabilities targeted by requirements

Development patterns could then be defined with regard to architecture layers (organization and business, systems functionalities, platforms implementations) and capabilities footprint:

  • Phased: work units are aligned with architecture capabilities, e.g : business objects (a), business logic (b), business processes (c), users interfaces (d).
  • Iterative: work units are set across capabilities and defined dynamically according to development problems.

EARdmap_VChain
A common development framework for phased and iterative projects

That would provide a development framework supporting the assessment of iterative as well as phased projects, paving the way for comprehensive and integrated impact analysis.

Value Chains & Architecture Capabilities

As far as software engineering is concerned, the issue is less the value chain itself than its change, namely how value is to be added along the chain.

Given the generalization of digitized and networked business environments, that can be best achieved by harnessing value chains to enterprise architecture capabilities, as can be demonstrated using the Caminao layout of the Zachman framework.

To summarize, the transition to this layout is carried out in two steps:

  1. Conceptually, Zachman’s original “Why” column is translated into a line running across column capabilities.
  2. Graphically, the five remaining columns are replaced by embedded pentagons, one for each architecture layer, with the new “Why” line set as an outer layer linking business value to architectures capabilities:

Mapping value chains to enterprise architectures capabilities

That apparently humdrum transformation entails a significant shift in focus and practicality:

  • The focus is put on organizational and business objectives, masking the ones associated to systems and platforms layers.
  • It makes room for differentiated granularity in the analysis of value, some items being anchored to specific capabilities, others involving cross dependencies.

Value chains can then be charted from business processes to supporting architectures, with software applications in between.

Impact Analysis

As pointed above, the crumbling of traditional fences and the integration of enterprise architectures into digital environments undermine the traditional distinction between primary and support activities.

To be sure, business drive is more than ever the defining factor for primary activities; and computing more than ever the archetype of supporting ones. But in between the once clear-cut distinctions are being blurred by a maze of digital exchanges.

In order to avoid a spaghetti heap of undistinguished connections, value chains are to be “colored” according to the nature of links:

  • Between architectures capabilities: business and organization (enterprise), systems functionalities, or platforms and technologies.
  • Between architecture layers: engineering processes.

Pentaheds-Traces
Tracing value chains across architectures layers

When set within that framework, value chains could be navigated in both directions:

  • For the assessment of applications developed iteratively: business value could be compared to development costs and architecture assets’ depreciation.
  • For the assessment of features (functional or non functional) to be shared across business applications: value chains will provide a principled basis for standard accounting schemes.

Combined with model based system engineering that could significantly enhance the integration of enterprise architecture into corporate governance.

Model Driven Architecture & Value Chains

Model driven architecture (MDA) can be seen as the main (only ?) documented example of model based systems engineering. Its taxonomy organizes models within three layers:

  • Computation independent models (CIMs) describe organization and business processes independently of the role played by supporting systems.
  • Platform independent models (PIMs) describe the functionalities supported by systems independently of their implementation.
  • Platform specific models (PSMs) describe systems components depending on platforms and technologies.

Engineering processes can then be phased along architecture layers (a), or carried out iteratively for each application (b).

When set across activities value chains could be engraved in CIMs and refined with PIMs and PSMs(a). Otherwise, i.e with business value neatly rooted in single business units, value chains could remain implicit along software development (b).

Further Reading

 External Links