Preamble
Digital environments and the ubiquity of software in business processes introduces a new perspective on value chains and the assessment of supporting applications.
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.
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).
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.
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:
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.
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:
- Conceptually, Zachman’s original “Why” column is translated into a line running across column capabilities.
- 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:
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.
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
- Value Chains & Enterprise Architecture
- Feasibility & Capabilities
- Data Mining & Requirements Analysis
- Focus: Rules & Architecture
- Requirements and Architecture Capabilities
- Caminao & the Zachman Framework
- From Processes to Services
- Ontologies & Enterprise Architecture
- Ontologies & Models
- Enterprise Governance & Knowledge
- EA: Work Units & Workflows
External Links