As far as enterprise architecture is concerned, the issue of scale is fogged by two confusions: one between processes and structures, the other between space and time. That square is at the core of the discipline.
Scaling Time (Tycho Brahe)
The Matter of Time
Even before the digital unfolding of environments, everybody was to agree that business is all about timing; and yet, that critical dimension remains a side issue of most enterprise architecture frameworks, which consequently fail to deal with enterprises ability to change and adapt in competitive environments.
With regard to time, the business perspective is said to be synchronic because it must continuously tally with environments constraints, opportunities, and risks.
By contrast, the engineering perspective is said to be diachronic because once fastened to requirements, developments are supposed to proceed according their own time-span.
Mixing Timescales
For enterprise architects, pairing up business and engineering momentum may look like a Fourier transform that would decompose enterprise architecture into piecemeal capabilities to be adjusted to the flow of business circumstances. But assets being by nature discrete, changes are not easily ironed out and some mechanism is necessary to align business and engineering time-frames, the former set at enterprise level and used to align enterprise architecture capabilities with business objectives, the latter set at system level and used to manage developments.
Agile methodologies solve the problem by assuming continuous deliveries disconnected from external schedules and by folding projects into detached time warps. Along with debatable scaling attempts, definitively non agile procedures are used to carry on with agile projects at system level.
As it happens, the iterative model can be upgraded to architecture level, enabling the linking of business driven changes to systems based ones without breaking agile principles:
Projects’ scope, objectives, and invariants are set with regard to enterprise architecture capabilities.
Iterations combine requirements analysis, development, and acceptance.
Increments and deliverables are defined dynamically contingent on scope and invariants.
Exit conditions (aka deliveries) are defined with regard to quality of services and technical requirements.
So-called architecture backlogs could thus be added to coordinate self-contained developments, standalone applications as well as system business functions, e.g. (invariants are in grey):
But the coordination issue remains between architecture backlogs, and adding procedures or committees shouldn’t be an option as it would seriously curb enterprise agility. By contrast, model based solutions are to ensure a constant and consistent adaptation of enterprise architectures to their environment.
The Agile development model should not be seen as a panacea or identified with specific methodologies. Instead it should be understood as a default option to be applied whenever phased solutions can be factored out.
Agile (a,b) versus phased (d,b,c,) development processes
Characteristics: Assuming conditions are met, agile software engineering can be fully and neatly defined by a combination of users stories and iterative development.
Alternative: When conditions cannot be met, i.e when phased solutions are required, model-based system engineering frameworks should be used to integrate business-driven projects (agile) with architecture oriented ones (phased).
Variants and extensions: Even when conditions about shared ownership and continuous delivery are met, scaling issues may have to be taken into account; in that case they should be sorted out between broader business objectives on one hand, systems architecture engineering on the other hand
These guidelines are not meant to define how agile projects are to be carried out, only to determine their scope and relevance along other systems engineering processes.
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.
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.
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.)
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.
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.
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.
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.
Digital environments and the ubiquity of software in business processes introduces a new perspective on value chains and the assessment of supporting applications.
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.
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).
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.
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:
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.
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.
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:
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.
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.
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).
Given the digitization of enterprises environments, engineering processes have to be entwined with business ones while kept in sync with enterprise architectures. That calls for new threads of collaboration taking into account the integration of business and engineering processes as well as the extension to business environments.
Collaboration can be personal and direct, or collective and mediated (Wang Qingsong)
Whereas models are meant to support communication, traditional approaches are already straining when used beyond software generation, that is collaboration between humans and CASE tools. Ontologies, which can be seen as a higher form of models, could enable a qualitative leap for systems collaborative engineering at enterprise level.
Systems Engineering: Contexts & Concerns
To begin with contents, collaborations should be defined along three axes:
Requirements: business objectives, enterprise organization, and processes, with regard to systems functionalities.
Feasibility: business requirements with regard to architectures capabilities.
Architectures: supporting functionalities with regard to architecture capabilities.
Engineering Collaborations at Enterprise Level
Since these axes are usually governed by different organizational structures and set along different time-frames, collaborations must be supported by documentation, especially models.
Shared Models
In order to support collaborations across organizational units and time-frames, models have to bring together perspectives which are by nature orthogonal:
Contexts, concerns, and languages: business vs engineering.
Time-frames and life-cycle: business opportunities vs architecture stability.
Harnessing MBSE to EA
That could be achieved if engineering models could be harnessed to enterprise ones for contexts and concerns. That is to be achieved through the integration of processes.
Processes Integration
As already noted, the integration of business and engineering processes is becoming a key success factor.
For that purpose collaborations would have to take into account the different time-frames governing changes in business processes (driven by business value) and engineering ones (governed by assets life-cycles):
Business requirements engineering is synchronic: changes must be kept in line with architectures capabilities (full line).
Software engineering is diachronic: developments can be carried out along their own time-frame (dashed line).
Synchronic (full) vs diachronic (dashed) processes.
Application-driven projects usually focus on users’ value and just-in-time delivery; that can be best achieved with personal collaboration within teams. Architecture-driven projects usually affect assets and non-functional features and therefore collaboration between organizational units.
Collaboration: Direct or Mediated
Collaboration can be achieved directly or through some mediation, the former being a default option for applications, the latter a necessary one for architectures.
Both can be defined according to basic cognitive and organizational mechanisms and supported by a mix of physical and virtual spaces to be dynamically redefined depending on activities, projects, locations, and organisation.
Direct collaborations are carried out between individuals with or without documentation:
Immediate and personal: direct collaboration between 5 to 15 participants with shared objectives and responsibilities. That would correspond to agile project teams (a).
Delayed and personal: direct collaboration across teams with shared knowledge but with different objectives and responsibilities. That would tally with social networks circles (c).
Collaborations
Mediated collaborations are carried out between organizational units through unspecified individual members, hence the need of documentation, models or otherwise:
Direct and Code generation from platform or domain specific models (b).
Model transformation across architecture layers and business domains (d)
Depending on scope and mediation, three basic types of collaboration can be defined for applications, architecture, and business intelligence projects.
Projects & Collaborations
As it happens, collaboration archetypes can be associated with these profiles.
Collaboration Mechanisms
Agile development model (under various guises) is the option of choice whenever shared ownership and continuous delivery are possible. Application projects can so be carried out autonomously, with collaborations circumscribed to team members and relying on the backlog mechanism.
Projects set across enterprise architectures cannot be carried out without taking into account phasing constraints. While ill-fated Waterfall methods have demonstrated the pitfalls of procedural solutions, phasing constraints can be dealt with a roundabout mechanism combining iterative and declarative schemes.
Engineering vs Business Driven Collaborations
With collaborative engineering upgraded at enterprise level, the main challenge is to iron out frictions between application and architecture projects and ensure the continuity, consistency and effectiveness of enterprise activities. That can be achieved with roundabouts used as a collaboration mechanism between projects, whatever their nature:
Shared models are managed at roundabout level.
Phasing dependencies are set in terms of assertions on shared models.
Depending on constraints projects are carried out directly (1,3) or enter roundabouts (2), with exits conditioned by the availability of models.
Engineering driven collaboration: roundabout and backlogs
Moreover, with engineering embedded in business processes, collaborations must also bring together operational analytics, decision-making, and business intelligence. Here again, shared models are to play a critical role:
Enterprise descriptive and prescriptive models for information maps and objectives
Environment predictive models for data and business understanding.
Business driven collaboration: operations and business intelligence
Whereas both engineering and business driven collaborations depend on sharing information and knowledge, the latter have to deal with open and heterogeneous semantics. As a consequence, collaborations must be supported by shared representations and proficient communication languages.
Ontologies & Representations
Ontologies are best understood as models’ backbones, to be fleshed out or detailed according to context and objectives, e.g:
Thesaurus, with a focus on terms and documents.
Systems modeling, with a focus on integration, e.g Zachman Framework.
Classifications, with a focus on range, e.g Dewey Decimal System.
Meta-models, with a focus on model based engineering, e.g models transformation.
Conceptual models, with a focus on understanding, e.g legislation.
Knowledge management, with a focus on reasoning, e.g semantic web.
As such they can provide the pillars supporting the representation of the whole range of enterprise concerns:
Taking a leaf from Zachman’s matrix, ontologies can also be used to differentiate concerns with regard to architecture layers: enterprise, systems, platforms.
Last but not least, ontologies can be profiled with regard to the nature of external contexts, e.g:
Institutional: Regulatory authority, steady, changes subject to established procedures.
Professional: Agreed upon between parties, steady, changes subject to established procedures.
Corporate: Defined by enterprises, changes subject to internal decision-making.
Social: Defined by usage, volatile, continuous and informal changes.
Personal: Customary, defined by named individuals (e.g research paper).
Cross profiles: capabilities, enterprise architectures, and contexts.
Ontologies & Communication
If collaborations have to cover engineering as well as business descriptions, communication channels and interfaces will have to combine the homogeneous and well-defined syntax and semantics of the former with the heterogeneous and ambiguous ones of the latter.
With ontologies represented as RDF (Resource Description Framework) graphs, the first step would be to sort out truth-preserving syntax (applied independently of domains) from domain specific semantics.
RDF graphs (top) support formal (bottom left) and domain specific (bottom right) semantics.
On that basis it would be possible to separate representation syntax from contents semantics, and to design communication channels and interfaces accordingly.
That would greatly facilitate collaborations across externally defined ontologies as well as their mapping to enterprise architecture models.
Conclusion
To summarize, the benefits of ontological frames for collaborative engineering can be articulated around four points:
A clear-cut distinction between representation semantics and truth-preserving syntax.
A common functional architecture for all users interfaces, humans or otherwise.
Modular functionalities for specific semantics on one hand, generic truth-preserving and cognitive operations on the other hand.
Profiled ontologies according to concerns and contexts.
A critical fifth benefit could be added with regard to business intelligence: combined with deep learning capabilities, ontologies would extend the scope of collaboration to explicit as well as implicit knowledge, the former already framed by languages, the latter still open to interpretation and discovery.
P.S.
Knowledge graphs, which have become a key component of knowlege management, are best understood as a reincarnation of ontologies.
Business analysts stand between unbounded and moving business landscapes on one hand, distinctive and steady enterprise organization and culture on the other hand.
How to align enterprise resources and business opportunities (Patrick Zachmann)
Assuming that BAs’ primary concern is to keep ahead of the competition, framing business undertakings into universal guidelines could be counterproductive. By contrast, harnessing together versatile business processes and reliable systems architectures will clearly enhance business agility; hence the benefits of lining up enterprise architects’ and business analysts’ conceptual toolboxes:
Concepts : eight exclusive and unambiguous definitions provide the conceptual building blocks.
Models: how the concepts are used to consolidate business requirements and convey them to enterprise architects and software engineers.
Processes: how to harness organization and business objectives and align applications with business value.
Architectures: how to contrive along time the continuity and consistency of business concepts and objectives, and their congruence with systems capabilities.
Governance: assessment of business value and risks.
On that basis, the objective here is not to detail BAs’ tasks or methods but to focus on core issues to be addressed by business analysts.
Concepts
Whereas systems architecture is not their primary concern, business analysts should nonetheless share the same modeling paradigm:
Analysis models for business environments and objectives.
Design models for the architecture of systems and the specification of components.
Business objects and processes must be consistently identified (#) across business and system realms.
It is worth to remind that the distinction between descriptive (aka analysis) and prescriptive (aka design) models is not arbitrary but based on logic principles: the former are extensional as they classify actual instances of business objects and activities; in contrast, the latter are intensional as they define the features and behaviors of required system artifacts.
The distinction also brings organizational benefits as it tallies with BAs’ responsibility regarding the consistency and continuity of identities and semantics of actual objects and processes (business extensions) and their symbolic counterparts (system intensions):
Relevant categories at architecture level can be neatly and unambiguously defined.
Actual containers represent address spaces or time frames; symbolic ones represent authorities governing symbolic representations. System are actual realizations of symbolic containers managing symbolic artifacts.
Actual objects (passive or active) have physical identities; symbolic objects have social identities; messages are symbolic objects identified within communications. Power-types (²) are used to partition objects.
Roles (aka actors) are parts played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents meant to be identified independently of their behavior.
Events are changes in the state of business objects, processes, or expectations.
Activities are symbolic descriptions of operations and flows (data and control) independently of supporting systems; execution states (aka modes) are operational descriptions of activities with regard to processes’ control and execution. Power-types (²) are used to partition execution paths.
While business analysts should only be tasked with the continuous and consistent mapping of business individuals to their system surrogates, and not with their implementations, that cannot be achieved without a full and unambiguous specification of the variants and abstractions for the business objects and processes to be represented.
Languages & Models
Being in charge of requirements, business analysts can be seen as the gate-keepers of the whole engineering process. To begin with, and depending on the nature of domains, BAs can capture requirements using formal (e.g for scientific domains), specific, or natural languages. Then, requirements analysis can be carried out:
Iteratively in unison with development and in collaboration with software engineers (agile approach). In that case models are not necessary as requirements are expressed in natural language (users’ stories), possibly combined with domain specific languages (DSLs) for development.
As phased undertakings carried out independently, using a dedicated modeling language (e.g BPMN).
As phased undertakings carried out jointly with system analysts using a general purpose modeling language (e.g UML).
Three ways to deal with requirements analysis: business oriented and phased (BPMN), system oriented and phased (use cases), or business driven and iterative (users’ stories).
These schemes are therefore best understood as tools whose employ may overlap or be combined:
BPMN and UML activity diagrams have much in common.
Class diagram can complement BPMN for business objects, and State diagrams for processes control.
Use cases can be seen as describing the part of users’ stories to be supported by systems.
How BAs will employ them is to depend on business processes and projects’ objectives.
Business & Development Processes
The responsibility of BAs is about business processes, the choice of development model being left to project managers; hence the need for business analysts to be familiar with basic options:
Agile: business analysts collaborate with software engineers in project teams and share responsibilities from requirements to delivery.
Phased: roles and responsibilities are defined specifically with regard to development tasks.
With agile schemes BAs share roles and responsibilities all along, with phased ones roles and responsibilities are defined with regard to tasks.
Agile or phased, the contribution of business analysts can be defined around three core issues, corresponding to three typical modus operandi:
Concepts associated to business objects and activities that are to be represented. Assuming that conceptual models are meant to be stable and shared across processes, they should be under the responsibility of business analysts independently of applications.
Actors (users, devices, or systems) and activities. Insofar as the impact on organization and system functional features can be localized (users interfaces) or circumscribed (business rules), business analysts can collaborate and share responsibility with software engineers all along an iterative process. Otherwise (changes in organization or business functions) business analysts will have to consolidate their work with enterprise architects.
Processes execution. Often labelled as non functional capabilities, they essentially deal with the different aspects of user’s experience and the synchronization of changes in business environments and supporting systems. For that purpose business analysts will have to check requirements against systems capabilities.
Business analysts core concerns and MO: conceptual model, activities, and processes.
While these issues are often interwoven, sorting them out can help to match development models with projects objectives and scope: agile for projects facing business users, phased for the ones dealing with architectures; that will also help to characterize the role of BAs depending on focus: business processes (BPM, use cases, users’ stories), functional architecture (services, conceptual models), or quality of services.
Business Analysis & Systems Architectures
When considering business opportunities, business analysts have to define requirements’ footprint with regard to system capabilities:
Confined: applications can be developed in collaboration with software engineers from users’ stories to code, without modeling. Assuming agile conditions about shared ownership and continuous delivery are met, that would be the default option.
Distributed: some modeling is needed for communication and consolidation purposes. But business processes modeling languages like BPMN make no distinction between processes’ details and the shared features of supporting systems. That puts a challenging toll on business analysts (complexity, ambiguity) with limited benefits (no easy mapping to system functions).
A primary concern for business analysts should therefore to frame projects accordingly: self-contained and business driven on one hand, shared and architecture driven on the other hand, with use cases set in between if and when necessary. For that purpose shared concerns will have to be clearly identified; taking BPMN for example:
Separation of concerns: architecture backbone and processes’ details
Containers for physical (locations) and logical (organizations and domains) objects have no BPMN explicit equivalents.
Active objects have no BPMN explicit equivalent.
Swimlanes and pool tally with roles (aka actors)
Data stores tally with entities (persistent representation of business objects).
Tasks, transactions, and sub-processes can be translated as activities description and processes execution.
Given backbones shared with enterprise architects, the next step is to flesh them out with specific details. Depending on methods and tools, that can be done using a domain specific language (DSL) with direct implementation, or through a generic subset of BPMN that could be unambiguously mapped to design constructs, for instance:
Anchors (#): instances (objects or activities) directly and consistently identified across businesses and system.
Collections (*): set of individuals with shared features.
Features: attributes or operations without identity of their own.
Structures (diamond): composition (black) for individual components (objects or activities) whose life-cycle is bound to their owner, i.e they have no identity of their own; aggregation (white) for components identified independently but used in the context of their owner.
Connectors: associate individuals; their semantics is set by context: communication channel, reference, data or control flow, transition. They can bear identification (#).
Power-types (2): define subsets of individuals objects or activities. Depending on context and modeling language, power-types correspond to classifications, extension points, gateways, branch and joins, etc.
Inheritance (triangle): contrary to structure and functional connectors that deal with instances, inheritance connectors are used to describe relationships between descriptors. Strong inheritance (black) is the counterpart of composition (inheritance of structural features), and weak inheritance (white) the counterpart of aggregation (inheritance functional features).
Separation of concerns: architecture backbone and anchors details
Using the same set of well accepted and unambiguous logical constructs for both objects and behaviors can greatly enhance the consistency of analysis models as well as their traceability to designs.
Business Analysis & Knowledge Management
As noted above, while business analysts may have to consolidate functional requirements or check the feasibility of non functional ones with enterprise architects, they should take responsibility for conceptual models, and more generally for enterprise knowledge architecture. Taking a leaf from Davis, Shrobe, and Szolovits, that will cover:
Surrogates: description of symbolic counterparts (aka) of actual objects, events and relationships.
Ontological commitments: statements about the categories of things that may exist in the domain under consideration.
Fragmentary theory of intelligent reasoning: model of what the things can do or can be done with.
Medium for efficient computation: knowledge understandable by computers.
Medium for human expression: communication between specific domain experts on one hand, generic knowledge managers on the other hand.
Putting apart users interfaces (point 5), two typical approaches can be considered:
Domain Driven Design (DDD), which deals with domains representation and computation from a system perspective (point 4).
Ontologies, which put the focus on knowledge oriented languages independently of computation (points 1-3).
Besides their simplex orientation, both fall short of business analysts needs, the former being too technical, the latter too open-ended. Instead, a conceptual framework should combine bounded domains with a compact and unambiguous knowledge oriented language.
As it happens, mapping the symbolic footprint of business domains and knowledge into systems may be dictated by the generalization of networked environments and digital business flows. Along that reasoning, BAs will have to deal with knowledge from domains as well process perspectives.
With regard to domains, a distinction should be maintained between institutional (external, statutory), business specific (external, agreed), and enterprise specific (internal).
A conceptual approach to domain layers: institutional, business specific (e.g HR management) and enterprise specific (e.g supply, sales).
With regard to processes, knowledge must be understood as the dynamic and multi-faceted outcome of data analytics, production systems, and decision-making. Taking a (revised) leaf of Zachman’s framework, business and operational objectives would be reset as to cross architecture layers instead of being aligned. Using a pentagonal representation of enterprise architecture, Zachman’s sixth column (“Why” ) would be rounded as an outer range.
Along that perspective embedding IT systems in business processes is to become a key success factor, which is to bring business intelligence up on the list of business analysts’ concerns.
Business Intelligence
If business intelligence is to take into account the ubiquity of digitized business processes and the integration of enterprises with their environments, a seamless integration of data analytics and decision-making is to be a primary concern for BAs.
Data analytics (sometimes known as data mining) is best understood as a refining activity whose purpose is to process raw data into meaningful information:
Data understanding gives form and semantics to raw material.
Business understanding charts business contexts and concerns in terms of objects and processes descriptions.
Modeling consolidates data and business understanding into descriptive, predictive, or operational models.
Evaluation assesses and improves accuracy and effectiveness with regard to objectives and decision-making.
Observation: understanding of changes in business environments (aka territories).
Orientation: assessment of the reliability and shelf-life of pertaining information (aka maps) 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.
The integration of data analytics and decision-making would be a key benefit of enterprise architecture.
Seamless integration of data analytics and decision-making.
On a broader perspective data analytics and decision-making can be seen as the front-offices of business intelligence, and knowledge management as its back-office. That organization can be reinforced with ontologies set with regard to governance and stability of contexts:
Institutional: Regulatory authority, steady, changes subject to established procedures.
Professional: Agreed upon between parties, steady, changes subject to accords.
Corporate: Defined by enterprises, changes subject to internal decision-making.
Social: Defined by usage, volatile, continuous and informal changes.
Personal: Customary, defined by named individuals (e.g research paper).
As gate-keepers, business analysts have to rank projects with regard to business value, risks, and return on investment. Assuming that business value is set independently of supporting systems, projects’ assessment and ranking should be set according to the nature of problems:
Intrinsic business size and complexity: requirements can be estimated from individuals (objects and activities), features, relationships, and partitions.
Supporting systems functionalities: intrinsic business metrics are to be combined with what is expected from supporting systems: processes and transactions, triggering events, users and devices interfaces, etc.
Business and functional measurements can then be weighted by non-functional (aka Quality of Service) requirements.
Assessment should be aligned with problems: business, supporting systems, operations.
If returns on investment (ROI) and risks are to be assessed consistently and decision-making carried out accordingly, value, costs, quality, and hazards have to be set within the same framework, in particular for quality and risks management:
Business environment: risks are external and quality is to check for timely and relevant analysis models.
Engineering: risks are internal and quality is to focus on processes maturity.
Technologies: risks are external and quality is to address versatility, plasticity, and effectiveness of solutions.
To conclude, whereas business risks remain the primary concern of business analysts, the fusion of business and systems processes means that they can no longer ignore engineering pitfalls and the importance of quality for risks management.
All too often Enterprise Architecture (EA) is planned as a big bang project to be carried out step by step until completion. That understanding is misguided as it confuses EA with IT systems and implies that enterprises could change their architectures as if they were apparel.
EA is a never-ending endeavor (Robert Doisneau)
But enterprise architectures are part and parcel of enterprises, a combination of culture, organization, and systems; whatever the changes, they must keep the continuity, integrity, and consistency of the whole.
Capabilities
Compared to usual projects, architectural ones are not meant to address specific business needs but architecture capabilities that may or may not be specific to business functions. Taking a leaf from the Zachman Framework, those capabilities can be organized around five pillars supporting enterprise, systems, and platform architectures:
Who: enterprise roles, system users, platform entry points.
What: business objects, symbolic representations, objects implementation.
How: business logic, system applications, software components.
When: processes synchronization, communication architecture, communication mechanisms.
Where: business sites, systems locations, platform resources.
These capabilities are set across architecture layers and support business, engineering, and operational processes.
Enterprise architecture capabilities
Enterprise architects are to continuously assess and improve these capabilities with regard to current weaknesses (organizational bottlenecks, technical debt) or future developments (new business, M&A, new technologies).
Work Units
Given the increased dependencies between business, engineering, and operations, defining EA workflows in terms of work units defined bottom-up from capabilities is to provide clear benefits with regard to EA versatility and plasticity.
Contrary to top-down (aka activity based) ones, bottom-up schemes don’t rely on one-fits-all procedures; as a consequence work units can be directly defined by capabilities and therefore mapped to engineering workshops:
Iterative development of architecture capabilities across workshops
Moreover, dependency constraints can be directly defined as declarative assertions attached to capabilities and managed dynamically instead of having to be hard-wired into phased processes.
That approach is to ensure two agile conditions critical for the development of architectural features:
Shared ownership: lest the whole enterprise be paralyzed by decision-making procedures, work units must be carried out under the sole responsibility of project teams.
Continuous delivery: architecture driven developments are by nature transverse but the delivery of building blocs cannot be put off by the decision of all parties concerned; instead it should be decoupled from integration.
Enterprise architecture projects could then be organized as a merry-go-round of capabilities-based work units to be set up, developed, and delivered according to needs and time-frames.
Time Frames
Enterprise architecture is about governance more than engineering. As such it has to ensure continuity and consistency between business objectives and strategies on one side, engineering resources and projects on the other side.
Assuming that capability-based work units will do the job for internal dependencies (application contents and engineering), the problem is to deal with external ones (business objectives and enterprise organization) without introducing phased processes. Beyond differences in monikers, such dependencies can generally be classified along three reasoned categories:
Operational: whatever can be observed and acted upon within a given envelope of assets and capabilities.
Tactical: whatever can be observed and acted upon by adjusting assets, resources and organization without altering the business plans and anticipations.
Strategic: decisions regarding assets, resources and organization contingent on anticipations regarding business environments.
The role of enterprise architects will then to manage the deployment of updated architecture capabilities according to their respective time-frames.
Portfolio Management
As noted before, EA workflows by nature can seldom be carried out in isolation as they are meant to deal with functional features across business domains. Instead, a portfolio of architecture (as opposed to development) work units should be managed according to their time-frame, the nature of their objective, and the kind of models to be used:
EA portfolio
Strategic features affect the concepts defining business objectives and processes. The corresponding business objects and processes are primarily defined with descriptive models; changes will have cascading effects for engineering and operations.
Tactical features affect the definition of artifacts, logical or physical. The corresponding engineering processes are primarily defined with prescriptive models; changes are to affect operational features but not the strategic ones.
Operational features affect the deployment of resources, logical or physical. The corresponding processes are primarily defined with predictive models derived from descriptive ones; changes are not meant to affect strategic or tactical features.
Architectural projects could then be managed as a dynamic backlog of self-contained work units continuously added (a) or delivered (b).
Views can take different meanings, from windows opening on specific data contexts (e.g DB relational theory), to assortments of diagrams dedicated to particular concerns (e.g UML).
Deconstructing the Universe along Contexts and Concerns (Depero Fortunato)
Models for their part have also been understood as views, on DB contents as well as systems’ architecture and components, the difference being on the focus put on engineering. Due to their association with phased processes, models has been relegated to a back-burner by agile approaches; yet it may resurface in terms of granularity with model-based engineering frameworks.
Yet, whatever the terminology (layers vs levels), what is at stake is the alignment of two basic scales:
Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
Process view: captures the concurrency and synchronization aspects.
Physical view: describes the mapping(s) of software artifacts onto hardware.
Development view: describes the static organization of software artifacts in development environments.
A fifth is added for use cases describing the interactions between systems and business environments.
Whereas these views have been originally defined with regard to UML diagrams, they may stand on their own meanings and merits, and be assessed or amended as such.
Apart from labeling differences, there isn’t much to argue about use cases (for requirements), process (for operations), and physical (for deployment) views; each can be directly associated to well identified parts of systems engineering that are to be carried out independently of organizations, architectures or methods.
Logical and development views raise more questions because they imply a distinction between design and implementation. That implicit assumption induces two kinds of limitations:
They introduce a strong bias toward phased approaches, in contrast to agile development models that combine requirements, development and acceptance into iterations.
They classify development processes with regard to predefined activities, overlooking a more critical taxonomy based on objectives, architectures and life-cycles: user driven and short-term (applications ) vs data-based and long-term (business functions).
These flaws can be corrected if logical and development views are redefined respectively as functional and application views, the former targeting business objects and functions, the latter business logic and users’ interfaces.
Architecture based views
That make views congruent with architecture levels and consequently with engineering workshops. More importantly, since workshops make possible the alignment of products with work units, they are a much better fit to model-based engineering and a shift from procedural to declarative paradigm.
Model-based Systems Engineering & Granularity
At least in theory, model-based systems engineering (MBSE) should free developers from one-fits-all procedural schemes and support iterative as well as declarative approaches. In practice that would require matching tasks with outcomes, which could be done if responsibilities on the former can be aligned with models granularity of the latter.
With coarse-grained phased schemes like MDA’s CIM/PIM/PSM (a), dependencies between tasks would have to be managed with regard to a significantly finer artifacts’ granularity.
Managing changes at architecture (a) or application (b) level.
For agile schemes, assuming conditions on shared ownership and continuous deliveries are met, projects would put locks on “models” at both ends (users’ stories and deliveries) of development cycles (b), with backlogs items defining engineering granularity.
Backlogs mechanism can be used to manage customized granularity and hierarchical dependencies across model layers
From the enterprise perspective it would be possible to unify the management of changes in architectures across layers and responsibilities: business concepts and organization, functional architecture, and systems capabilities:
Functional architecture as symbolic bridge between business needs and system capabilities.
From the engineering perspective it would be possible to unify the management of changes in artifacts at the appropriate level of granularity: static and explicit using milestones (phased), dynamic and implicit using backlogs (agile).
Fine grained model based frameworks could support phased as well as agile development solutions
Such a declarative repository would greatly enhance exchanges and integration across projects and help to align heterogeneous processes independently of the methodologies used.
As already noted, the seamless integration of business processes and IT systems may bring new relevancy to the OODA (Observation, Orientation, Decision, Action) loop, a real-time decision-making paradigm originally developed by Colonel John Boyd for USAF fighter jets.
Agility & Orientation (Lazlo Moholo-Nagy)
Of particular interest for today’s business operational decision-making is the orientation step, i.e the actual positioning of actors and the associated cognitive representations; the point being to use AI deep learning capabilities to surmise opponents plans and misdirect their anticipations. That new dimension and its focus on information brings back cybernetics as a tool for enterprise governance.
In the Loop: OODA & Information Processing
Whatever the topic (engineering, business, or architecture), the concept of agility cannot be understood without defining some supporting context. For OODA that would include: territories (markets) for observations (data); maps for orientation (analytics); business objectives for decisions; and supporting systems for action.
OODA loop and its actual (red) and symbolic (blue) contexts.
One step further, contexts may be readily matched with systems description:
Business contexts (territories) for observations.
Models of business objects (maps) for orientation.
Business logic (objectives) for decisions.
Business processes (supporting systems) for action.
The OODA loop and System Perspectives
That provides a unified description of the different aspects of business agility, from the OODA loop and operations to architectures and engineering.
Architectures & Business Agility
Once the contexts are identified, agility in the OODA loop will depend on architecture consistency, plasticity, and versatility.
Architecture consistency (left) is supposed to be achieved by systems engineering out of the OODA loop:
Technical architecture: alignment of actual systems and territories (red) so that actions and observations can be kept congruent.
Software architecture: alignment of symbolic maps and objectives (blue) so that orientation and decisions can be continuously adjusted.
Functional architecture (right) is to bridge the gap between technical and software architectures and provides for operational coupling.
Business Agility: systems architectures and business operations
Operational coupling depends on functional architecture and is carried on within the OODA loop. The challenge is to change tack on-the-fly with minimum frictions between actual and symbolic contexts, i.e:
Discrepancies between business objects (maps and orientation) and business contexts (territories and observation).
Departure between business logic (objectives and decisions) and business processes (systems and actions)
Taking a leaf from thermodynamics, cybernetics defines entropy as a measure of the (supposedly negative) variation in the value of the information supporting the control of viable systems.
With regard to corporate governance and operational decision-making, entropy arises from faults between environments and symbolic surrogates, either for objects (misleading orientations from actual observations) or activities (unforeseen consequences of decisions when carried out as actions).
So long as architectures and operations were set along different time-frames (e.g strategic and tactical), cybernetics were of limited relevancy. But the seamless integration of data analytics, operational decision-making, and IT supporting systems puts a new light on the role of entropy, as illustrated by Boyd’s OODA and its orientation component.
Orientation & Agility
While much has been written about how data analytics and operational decision-making can be neatly and easily fitted in the OODA paradigm, a particular attention is to be paid to orientation.
As noted before, the concept of Orientation comes with a twofold meaning, actual and symbolic:
Actual: the positioning of an agent with regard to external (e.g spacial) coordinates, possibly qualified with the agent’s abilities to observe, move, or act.
Symbolic: the positioning of an agent with regard to his own internal (e.g beliefs or aims) references, possibly mixed with the known or presumed orientation of other agents, opponents or associates.
That dual understanding underlines the importance of symbolic representations in getting competitive edges, either directly through accurate and up-to-date orientation, or indirectly by inducing opponents’ disorientation.
Agility vs Entropy
Competition in networked digital markets is carried out at enterprise gates, which puts the OODA loop at the nexus of information flows. As a corollary, what is at stake is not limited to immediate business gains but extends to corporate knowledge and enterprise governance; translated into cybernetics parlance, a competitive edge would depend on enterprise ability to export entropy, that is to decrease confusion and disorder inside, and increase it outside.
Working on that assumption, one should first characterize the flows of information to be considered:
Territories and observations: identification of business objects and events, collection and analysis of associated data.
Maps and orientations: structured and consistent description of business domains.
Objectives and decisions: structured and consistent description of business activities and rules.
Systems and actions: business processes and capabilities of supporting systems.
Static assessment of technical and software architectures for respectively observation and decision
Then, a static assessment of information flows would start with the standing of technical and software architecture with regard to competition:
Technical architecture: how the alignment of operations and resources facilitate actions and observations.
Software architecture: how the combined descriptions of business objects and logic facilitate orientation and decision.
A dynamic assessment would be carried out within the OODA loop and deal with the role of functional architecture in support of operational coupling:
How the mapping of territories’ identities and features help observation and orientation.
How decision-making and the realization of business objectives are supported by processes’ designs.
Dynamic assessment of decision-making and the realization of business objectives’ as supported by processes’ designs.
Assuming a corporate cousin of Maxwell’s demon with deep learning capabilities standing at the gates in its OODA loop, his job would be to analyze the flows and discover ways to decrease internal complexity (i.e enterprise representations) and increase external one (i.e competitors’ representations).
That is to be achieved with the integration of operational analytics, business intelligence, and decision-making.
Seamless integration of operational analytics, business intelligence, and decision-making.
