To hear the buzz around business capabilities one would expect some consensus about basic principles as well as an established track record. Since there is little to be found on either account, should the notion be seen as a modern philosophers’ stone ?
Clear evidence can be found by asking two questions: what should be looked for, and why it can’t be found.
What is looked for
Business capabilities can be understood as a modern avatar of the medieval philosophers’ stone, a alchemical substance capable of turning base metals into gold.
In the context of corporate governance, that would mean a combination of assets blueprints and managing principles paving the way to success.
But such a quest is to err between the sands of businesses specificities and the clouds of accounting generalities.
At ground level enterprises have to mark their territory and keep it safe from competitors. Whatever the means they use (niche segments, effective organization, monopolistic situations, …,) success comes from making a difference.
With hindsight, revealing singularities may be discovered among the idiosyncrasies of business successes, but that can only be done from accounting heights, where capabilities are clouded by numbers.
why it can’t be found
The fallacy of a notion can also be established a contrario if, assuming the existence of a philosophers’ stone, the same logic would also demonstrate the futility of the quest.
Such a reasoning appears more like a truism when applied to business capabilities: insofar as business competition is concerned success is exclusive and cutting edges are not shared. It ensues that assuming business capabilities could be found, they would by the same move become obsolete and be instantly dissolved.
What should be looked for
As far as business environments are concerned, success is by nature singular and transient, and it consequently depends on sustaining a balancing act between assets and opportunities. To that end business capabilities should be understood as a hub between value chains and enterprise architectures.
As demonstrated by a simple Google search, the MBSE acronym seems to be widely and consistently understood. Yet, the consensus about ‘M’ standing for models comes with different meanings for ‘S’ standing either for software or different kinds of systems.
In practice, the scope of model-based engineering has been mostly limited to design-to-code (‘S’ for software) and manufacturing (‘S’ for physical systems); leaving the engineering of symbolic systems like organizations largely overlooked.
Models, Software, & Systems
Models are symbolic representations of actual (descriptive models) or contrived (prescriptive models) domains. Applied to systems engineering, models are meant to serve specific purposes: requirements analysis, simulation, software design, etc. With software as the end-product of system engineering, design models can be seen as a special case of models characterized by target (computer code) and language (executable instructions). Hence the letter ‘S’ in the MBSE acronym, which can stand for ‘system’ as well as ‘software’,
As far as practicalities are considered, the latter is the usual understanding, specifically for the use of design models to generate code, either for software applications, or as part of devices combining software and hardware.
When enterprise systems are taken into consideration, such a limited perspective comes with consequences:
It puts the focus on domain specific implementations, ignoring the benefits for enterprise architecture.
It gives up on the conceptual debt between models of business and organization on one side, models of systems on the other side.
These stand in the path of the necessary integration of enterprises architectures immersed into digital environments.
Organizations as Symbolic Systems
As social entities enterprises are set in symbolic realms: organizational, legal, and monetary. Now, due the digital transformation, even their operations are taking a symbolic turn. So, assuming models could be reinstated as abstractions at enterprise level, MBSE would become the option of choice, providing a holistic view across organizations and systems (conceptual and logical models) while encapsulating projects and applications (design models).
That distinction between symbolic and actual alignments, the former with conceptual and logical models set between organization and systems, the latter with design models set between projects and applications, is the cornerstone of enterprise architecture. Hence the benefits of implementing it through model based system engineering.
While MBSE frameworks supporting the final cycle of engineering (from design downstream) come with a proven track record, there is nothing equivalent upstream linking business and organization to systems, except for engineering silos using domain specific languages. Redefined in terms of enterprise architecture abstractions, MBSE could bring leveraged benefits all along the development process independently of activity, skills, organization or methods, for enterprises as well as services and solutions providers.
As a modeling framework, it would enhance the traceability and transparency for products (quality) as well as processes (delays and budgets) along and across supply chains.
‘S’ For Service
Implemented as a service, MBSE could compound the benefits of cloud-based environments (accessibility, convenience, security, etc.), and could also be customized without undermining interoperability.
To that end, MBSE as a service could be reframed in terms of:
Customers (projects): services should address cross-organizational and architecture concerns, from business intelligence to code optimization, and from portfolio management to components release.
Policy (processes): services should support full neutrality with regard to organizations and methods, which implies that tasks and work units should be defined only with regard to the status of artifacts.
Contracts (work units and outcomes): services are to support the definition of work units and the assessment of outcomes:
Work units are to be defined bottom-up from artefacts.
Outcomes are to be assessed with regard to work units
Value in Models Transformations:
Transparency and Traceability: Two distinct model sets – Architecture Models and Implementation Models.
Endpoints (collaboration): if services are to be neutral with regard to the way they are provided, the collaboration between the wide range of is to be managed accordingly; that can only be achieved through a collaboration framework built on layered and profiled ontologies.
As a concluding remark, cross-breeding MBSE with Software as a Service (SaaS) could help to integrate systems and knowledge architectures, paving the way to a comprehensive deployment of machine learning technologies.
As the world turns digital,traditional fences between social, businesses, and systems realms are progressively crumbling. That brings new challenges for enterprises governance, in particular when manifold business stakes and IT systems are concerned.
Supposedly, enterprise architecture would deal with the framing of enterprises and systems concerns into a single paradigm. Yet spirited controversies persist between bottom up and top down approaches, the former trying to upgrade the footprint of IT systems to enterprise level, the latter ready to downgrade these systems to equipment level. But dissent in that case means unfinished business: like diggers tunneling from opposite directions, both groups are to succeed together or fail together. For that to be achieved common sense dictates that both teams agree on target, with each one getting its specific orientation right.
What to look for
Issue (information systems) and circumstances (digitization of business environment) put the focus on the relationship between business processes and enterprises organization and how to capture, manage, and use information.
On that account, and not surprisingly, understandings differ between EA proponents:
Bottom-up approaches are focused on the distinction between processes, applications, and data, overlooking key enterprise architecture concerns (a).
Top-down approaches come with a better understanding of EA stakes but fall short of the conceptual bridge between organization and business environments (b) .
These shortcomings can be mended and approaches made to converge.
How to get there
As already noted, EA can only succeed as a discipline if systems and enterprise perspectives can be crossed, i.e if bottom-up and top-down approaches can be joined. That cannot be achieved along the outdated Process/Application/Data layers:
To begin with, the distinction between application and data, inherited from traditional programming, goes against both object-oriented design and service oriented architectures; then, processes don’t describe architectures but the way they are used.
On a broader perspective, if the impact of digitized business environments on EA is to be taken into account, data and information are to be redefined in a new paradigm, the former associated with a raw input, to be mined from the business environment and processed into the latter. It ensues that (1) data becomes irrelevant for architecture concerns and, (2) information becomes a key asset for enterprise architecture.
Merging applications and data into a logical/functional layer between business and engineering processes also critically redefines the perspective: instead of a being a collection of applications, business processes become the nexus of the architecture.
With a bottom-up EA perspective focused on business and engineering processes, a top-down counterpart has to be set from enterprise perspective that would ensure a meeting of minds around business processes.
That can be readily achieved by keeping processes as pivot between business environments and objectives on one side, enterprise organization on the other side:
Enterprise architects could then focus on the mapping of business functions to services, the alignment of quality of services with architecture capabilities, and the flows of information across the organization.
Why It Matters
A proper understanding of architecture layers is not an academic concern to be overlooked. As a matter of fact, what is at stake is the very practical purpose of EA: display of boxes and arrows or effective handling of the spindle between business processes and architectural assets. Whereas anything will do for the former, the latter cannot be achieved without a principled and effective coupling between enterprise models and systems engineering.
Enterprise governance has to face combined changes in the way business times and spaces are to be taken into account. On one hand social networks put well-thought-out market segments and well planned campaigns at the mercy of consumers’ weekly whims. On the other hand traditional fences between environments and IT systems are crumbling under combined markets and technological waves.
So, despite (or because of) the exponential ability of intelligent systems to learn from circumstances, enterprise governance is not to cope with such dynamic complexities without a reliable compass set with regard to key primary factors: time-frames of concerns; control of processes; administration of artifacts.
Concerns & Time-frames
Confronted to massive and continuous waves of stochastic data flows, the priority is to position external events and decision-making with regard to business and assets time-frames:
Business value is to be driven by market opportunities which cannot be coerced into predefined fixed time-frames.
Assets management is governed by continuity and consistency constraints on enterprise identity, objectives, and investments along time.
Enterprises, once understood as standalone entities, must now be redefined as living organisms in continuous adaptation with their environment. Governance schemes must therefore be broadened to business environments and layered as to take into account the duality of time-frames: operational for business value, strategic for assets.
Control of processes and administration of artifacts can then be defined accordingly.
Time & Control: Processes
Architectures being by nature shared and persistent, their layers are meant to reflect different time-frames, from operational cycles to long-term assets:
At enterprise level the role of architectures is to integrate shared assets and align various objectives set along different time-frames. At this level it’s safe to assume some cross dependencies between processes, which would call for phased governance.
By contrast, business units are meant to be defined as self-governing entities pursuing specific objectives within their own time-frame. From a competitive perspective markets opportunities and competitors moves are best assumed unpredictable, and processes best governed by circumstances.
Processes can then be defined vertically (business or Systems) as well as horizontally (enterprise architecture or application development), and governance set accordingly:
At enterprise level processes are phased: stakeholders and architects plan and manage the development and deployment of assets (organization and systems).
At business units level processes are lean and just-in-time: business analysts and software engineers design and develop applications supporting users needs as defined by users stories or use cases.
Models are then to be introduced to describe shared assets (organization and systems) across the enterprise. They may also support business analysis and software engineering.
Carrying on with the four corners of governance square:
Business analysts are to set users’ narratives (concrete) in line with the business plots (blueprints) set by stakeholders.
Software engineers designing applications (concrete) in line with systems functional architectures (blueprints).
As for the overlapping of business and development time-frames, the direct mapping between concrete business and system corners (e.g though agile development) is to facilitate the governance of integrated actual and numeric flows across business and systems.
Conclusion: A Compass for Enterprise Architects
Behind turfs perimeters and jobs descriptions, roles and responsibilities involved in enterprise architecture can be summarized by four drives:
Business analysts (bottom left): define business processes with regard to broader objectives and engineering efficiency.
Software engineers (bottom right): maximize the value for users and the quality of applications.
Systems architects (top right): dynamically align systems with regard to business models and engineering processes.
Whereas roles and responsibilities will generally differ depending on enterprise environment, business, and culture, such a compass would ensure that the governance of enterprise architectures hinges on reliable pillars and is driven by clear principles.
UML (Unified Modeling Language) and MDA (Model Driven Architecture) epitomize the lack of focus and consistency of the OMG’s strategy. As it’s safe to assume that there can be no architectures without models, MDA and UML arguably bring sensible (if not perfect) schemes without significant competition.
Unfortunately, not much has been made to play on their obvious complementarity and to exploit their synergies.
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 implementation platforms.
Engineering can then be managed along architecture layers (a), or carried out as a whole for each application (b).
It’s important to note that the MDA framework is completely neutral with regard to methods: engineering processes can be organized as phased activities (procedural), iterations (agile), or artifacts transformation (declarative).
Logic & The Matter of Models
Whatever the idiosyncrasies and fuzziness of business concerns and contexts, at the end of the day requirements will have to be coerced into the strict logic of computer systems. That may be a challenging task to be carried out directly, but less so if upheld by models.
As it happens, a fact all too often ignored, models come with sound logical foundations that can be used to formalize the mapping of requirements into specifications; schematically, models are to be set in two formal categories:
Descriptive (aka extensional) ones try to classify actual objects, events, and processes into categories.
Prescriptive (aka intensional) ones specify what is expected of systems components and how to develop them.
Interestingly, that distinction provides a formal justification to the one between analysis and design models, the former for the consolidation of requirements across business domains and enterprise organization, the latter for systems and software designs. Such logical foundations could help to manage the mapping of business processes and systems architectures.
UML & the Anatomy of Models
Except scientific computation, there is no reason to assume a-priori congruence between the description of business objects and processes and the specification of the software components. As a corollary, their respective structures and features are better to be dealt with separately.
But that’s not the case at architecture level, where domains and identities have to be managed continuously and consistency on the two sides of the business/system divide. At this level (aka enterprise architecture), responsibilities and identification and communication mechanisms must be defined uniformly.
Compared to MDA set at architecture level, UML describes the corresponding artifacts for business, systems, and platform layers. Regardless of the confusing terminology (layers or levels), that puts MDA and UML along orthogonal dimensions: the former (layers) deals with the nature of contents, the latter (levels) with their structures and features.
Using the same unified modeling language across business, systems, and platform layers is to clearly and directly enhance transparency and traceability; but the full extent of MDA/UML cross-benefits is to appear when models logic is taken into account.
Models & Systems Evolution
As illustrated by the increasing number of systemic crashes, systems obsolescence is no longer a matter of long-term planning but of operational continuity: change has become the rule and as far as complex and perennial systems are concerned, architectures are to evolve while supporting their functional duties seamlessly. If that is to be achieved, modularity and a degree of consistency are necessary between the nature of changes and their engineering. That’s where MDA is to help.
As pointed to above, modularity is best achieved with regard to level (architecture, element) and models contents (business, systems, platforms).
At architecture level, changes in domains, identification, and categories must be aligned between descriptive (enterprise) and prescriptive (systems) models. That will be best achieved with UML models across all MDA layers.
The constraints of continuity and consistency can be somewhat eased at element level: if descriptive (business) and prescriptive (systems) models of structures and features are to be consistent, they are not necessarily congruent. On component (prescriptive/design) side, UML and object-oriented design (OOD) are to keep them encapsulated. As for the business (descriptive/analysis) side, since structures and features can be modeled separately (and OOD not necessarily the best option), any language (UML, BPMN, DSL,etc.) can be used. In between, the structure (aka signature) of messages passed at architecture level is to be specified depending on communication framework.
Considering the new challenges brought about by the comprehensive interoperability of heterogeneous systems, the OMG should reassess the full range of latent possibilities to be found in its engineering portfolio.
At enterprise level agility can be understood as a mix of versatility and plasticity, the former an attribute of function, the latter of form:
Versatility: enterprise ability to adapt business processes to changing environments without having to change architectures.
Plasticity: enterprise ability to change architectures without affecting business processes.
Combining versatility and plasticity requires a comprehensive and consistent view of assets (architectures) and modus operandi (processes) organized with regard to change. And that can be achieved with model based systems engineering (MBSE).
MBSE & Change
Agility is all about change, and if enterprise governance is not to be thrown aside decision-making has to be supported by knowledgeable descriptions of enterprise objectives, assets, and organization.
If change management is to be the primary objective, targets must be classified along two main distinctions:
Actual (business context and organization) or symbolic (information systems).
Objects (business entities or system surrogates) or activities (business processes or logic).
The two axis determine four settings supporting transparency and traceability:
Dependencies between operational and structural elements.
Dependencies between actual assets and processes and their symbolic representation as systems surrogates.
Versatility and plasticity will be obtained by managing changes and alignments between settings.
Changes & Alignments
Looking for versatility, changes in users’ requirements must be rapidly taken into account by applications (changes from actual to symbolic).
Looking for plasticity, changes in business objectives are meant to be supported by enterprise capabilities (changes from operational to structural).
The challenge is to ensure that both threads can be weaved together into business functions and realized by services (assuming a service oriented architecture).
With the benefits of MBSE, that could be carried out through a threefold 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 would make agility a concrete endeavor across enterprise, from business users and applications to business processes and architectures capabilities.
As far as systems engineering is concerned, the aim of a feasibility study is to verify that a business solution can be supported by a system architecture (requirements feasibility) subject to some agreed technical and budgetary constraints (engineering feasibility).
Where to Begin
A feasibility study is based on the implicit assumption of slack architecture capabilities. But since capabilities are set with regard to several dimensions, architectures boundaries cannot be taken for granted and decisions may even entail some arbitrage between business requirements and engineering constraints.
Using the well-known distinction between roles (who), activities (how), locations (where), control (when), and contents (what), feasibility should be considered for supporting functionalities (between business processes and systems) and implementation (between functionalities and platforms):
Depending on priorities, feasibility considerations could look from three perspectives:
Focusing on system functionalities (e.g with use cases) implies that system boundaries are already identified and that the business logic will be defined along with users’ interfaces.
Starting with business requirements puts business domains and logic on the driving seat, making room for variations in system functionalities and boundaries .
Operational requirements (physical environments, events, and processes execution) put the emphasis on a mix of business processes and quality of service, thus making software functionalities a dependent variable.
In any case a distinction should be made between requirements and engineering feasibility, the former set with regard to architecture capabilities, the latter with regard to development resources and budget constraints.
Functional capabilities are defined at system boundaries and if all feasibility options are to be properly explored, architectures capabilities must be understood as a trade-off between the five intrinsic factors e.g:
Security (entry points) and confidentiality (domains).
Compliance with regulatory constraints (domains) and flexibility (activities).
Reliability (processes) and interoperability (locations).
Feasible options could then be figured out by points set within the capabilities pentagon. Given metrics on functional requirements, their feasibility under the non functional constraints could be assessed with regard to cross capabilities. And since the same five core capabilities can be consistently defined across enterprise, systems, and platforms layers, requirements feasibility could be assessed without prejudging architecture decisions.
Business Requirements & Architecture Capabilities
One step further, the feasibility of business and operational objectives (the “Why” of the Zachman framework) can be more easily assessed if set on the outer range and mapped to architecture capabilities.
Engineering Feasibility & ROI
Finally, the feasibility of business and functional requirements under the constraints set by non functional requirements has to be translated in terms of ROI, and for that purpose the business value has to be compared to the cost of engineering the solution given the resources (people and tools), technical requirements, and budgetary constraints.
That where the transparency and traceability of capabilities across layers may be especially useful when alternatives and priorities are to be considered mixing functionalities, engineering outlays, and operational costs.