Modeling Symbolic Representations

March 16, 2010

System modeling is all too often a flight for abstraction, when business analysts should instead look for the proper level of representation, ie the one with the best fit to business concerns.

Modeling is synchronic: contexts must be mapped to representations (Velazquez, “Las Meninas”).

Caminao’s blog (see Topics Guide) will try to set a path to Architecture Driven System Modelling. The guiding principle is to look at systems as sets of symbolic representations and identify the core archetypes defining how they must be coupled to their actual counterparts. That would provide for lean (need-to-know specs) and fit (architecture driven) models, architecture traceability, and built-in consistency checks.

This blog is meant to be a work in progress, with the basic concepts set open to suggestions or even refutation:

All examples are taken from ancient civilizations in order to put the focus on generic problems of symbolic architectures, disregarding technologies.

Symbolic representation: a primer

Original illustrations by Albert (http://www.albertdessinateur.com/) allow for concrete understanding of requirements, avoiding the biases associated with contrived textual descriptions.

Business Agility vs Systems Entropy

November 28, 2016

Synopsis

As already noted, the seamless integration of business processes and IT systems may bring new relevancy to the OOAD (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)

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 IA 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: OOAD & 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.

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.
ccc

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

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)

When positive, operational coupling associates business agility with its architecture counterpart, namely plasticity and versatility; when negative, it suffers from frictions, or what cybernetics calls entropy.

Systems & Entropy

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.
cccc

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.
ccccc

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).

Further Readings

Business Agility & the OODA Loop

November 21, 2016

Preamble

The OOAD (Observation, Orientation, Decision, Action) loop is a real-time decision-making paradigm developed in the sixties by Colonel John Boyd from his experience as fighter pilot and military strategist.

(Moholy Nagy)

How to get inside opponent’s loop (Lazlo Moholy-Nagy)

The relevancy of OODA for today’s operational decision-making comes from the seamless integration of IT systems with business operations and the resulting merits of agile development processes.

Business: End of Discrete Time-Frames

Business governance was used to be phased: analyze the market, select opportunities, build capabilities, launch operations. No more. With the melting of the fences between actual and symbolic realms, periodic transitional events have lost most of their relevancy. Deprived of discrete and robust time-frames, the weaving of observed facts with business plans has to be managed on the fly. Success now comes from continuous readiness, quicker tempo, and the ability to operate inside adversaries’ time-scales, for defense (force competitor out of favorable position) as well as offense (get a competitive edge). Hence the reference to dogfights.

Dogfights & Agile Primacy

John Boyd train of thoughts started with the observation that, despite the apparent superiority of the soviet Mig 15 on US F-86 during the Korea war, US fighters stood their ground. From that factual observation it took Boyd’s comprehensive engineering work to demonstrate that as far as dogfights were concerned fast transients between maneuvers (aka agility) was more important than technical capabilities. Pushed up Pentagon’s reluctant ladders by Boyd’s sturdy determination, that conclusion have had wide-ranging consequences in the design of USAF fighters and pilots formation for the following generations. Its influence also spread to management, even if theories’ turnover is much faster there, and shelf-life much shorter.

Nowadays, with the accelerated integration of business processes with IT systems, agility is making a comeback from the software engineering corner. Reflecting business and IT convergence, principles like iterative development, just-in-time delivery, and lean processes, all epitomized by the agile software development model, are progressively mingling into business practices with strong resemblances to dogfights; and the resemblances are not only symbolic.

IT Systems & Business Competition

While some similarities between dogfights and business competition may seem metaphorical, one critical aspect is all too real, namely the increasing importance of supporting machines, IT systems or fighter jets.

Basically, IT systems, like fighters’ electronics, are tasked to observe environments, analyse changes in relation to position and objectives, and support decision-making. But today’s systems go further with two qualitative leaps:

  • The seamless integration of physical and symbolic flows let systems manage some overlapping between supporting decisions and carrying out actions.
  • Due to their artificial intelligence capabilities, systems can learn on-the-job and improve their performances in real-time feedback loops.

When combined, these two trends have drastic impact on the way machines can support human activities in real-time competitive situations. More to the point, they bring new light on business agility.

Business Agility

As illustrated by the radical transformation of fighter cockpits, the merging of analog and digital flows leaves little room for human mediation: data must be processed into information and presented instantly along two critical dimensions, one for decision-making, the other for information life-cycle:

  • Man/Machine interfaces have to materialize the merging of actual and symbolic realms as to support just-in-time decision-making.
  • The replacement of phased selected updates of environment data by continuous changes in raw and massive data means that the status of information has to be incorporated with the information itself, yet without impairing decision-making.

Beyond obvious differences between dogfights and business competition, that double exigence is to characterize business agility:

  1. Instant understanding of changes in business opportunities (Observation) .
  2. Simultaneous assessment of the reliability and shelf-life of pertaining information with regard to current positions and operations (Orientation).
  3. Weighting of options with regard to enterprise capabilities and broader objectives (Decision).
  4. Carrying out of decisions within the relevant time-span (Action).

That understanding of business agility is to be compared with its development and architecture cousins. Yet it doesn’t seem to add much to data analytics and operational decision-making. That is until the concept of orientation is reassessed.

Agility & Orientation: Task vs Tack

To begin with basics, the concept of Orientation comes with a twofold meaning, actual and symbolic:

  • Actual: a position with regard to external (e.g spacial) coordinates, possibly qualified with abilities to observe, move, or act.
  • Symbolic: a position with regard to internal (e.g beliefs or aims) references, possibly mixed with known or presumed orientation of other agents, opponents or associates.

When business is considered, data analytics is supposed to deal comprehensively and accurately with markets’ actual orientations. But the symbolic facet is left largely unexplored.

Boyd’s contribution is to bring together both aspects and combine them into actual practice, namely how to foretell the tack of your opponents from their actual tracks as well as their surmised plans, while fooling them about your own moves, actual or planned.

Such ambitions once out of reach, can now be fulfilled due to the combination of big data, artificial intelligence, and the exponential growth on computing power.

Further Readings

 

Focus: MDA & UML

November 9, 2016

 Preamble

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.

Eugene de Salignac

Architectures & Models (Eugene de Salignac)

Unfortunately, not much has been made to play on their obvious complementarity and to exploit their synergies.

MDA & the Nature of Models

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 implementation platforms.

Engineering can then be managed along architecture layers (a), or carried out as a whole for each application (b).

mapsterrits_landingschar

Managing changes at architecture (a) or application (b) level.

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.
The logical basis of models

The logical basis of models

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.

MDA is only concerned with architectures, UML describe the structure of architecture components.

MDA is only concerned with architectures, UML describe the structure of architecture components.

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.

Using UML and MDA helps to align descriptive and prescriptive models at architecture level.

Using UML and MDA helps to align descriptive and prescriptive models at architecture level.

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.

Further Reading

Things Behavior & Social Responsibility

October 27, 2016

Contrary to security breaks and information robberies that can be kept from public eyes, crashes of business applications or internet access are painfully plain for whoever is concerned, which means everybody. And as illustrated by the last episode of massive distributed denial of service (DDoS), they often come as confirmation of hazards long calling for attention.

robot_waynemiller

Device & Social Identity (Wayne Miller)

 

Things Don’t Think

To be clear, orchestrated attacks through hijacked (if unaware) computers have been a primary concern for internet security firms for quite some time, bringing about comprehensive and continuous reinforcement of software shields consolidated by systematic updates.

But while the right governing hand was struggling to make a safer net, the other hand thoughtlessly brought in connected objects to a supposedly new brand of internet. As if adding things with software brains cut to the bone could have made networks smarter.

And that’s the catch because the internet of things (IoT) is all about making room for dumb ancillary objects; unfortunately, idiots may have their use for literary puppeteers with canny agendas.

Think Again, or Not …

For anybody with some memory of fingering through library cardboard, googling topics may have looked like dreams: knowledge at fingertips, immediately and comprehensively. But that vision has never been more than a fleeting glimpse in a symbolic world; in actuality, even at it semantic best, the web was to remain a trove of information to be sifted by knowledge workers safely seated in their gated symbolic world. Crooks of course could sneak in as knowledge workers, but only armed with fountain pens, without guns covered by the second amendment.

So, from its inception, the IoT has been a paradoxical endeavor: trying to merge actual and symbolic realms would bypass thinking processes and obliterate any distinction. For sure, that conundrum was supposed to be dealt with by artificial intelligence (AI), with neural networks and deep learning weaving semantic threads between human minds and networks brains.

Not surprisingly, brainy hackers have caught sight of that new wealth of chinks in internet armour and swiftly added brute force to their paraphernalia.

But in addition to the technical aspect of internet security, the recent Dyn DDoS attack puts the light on its social perspective.

Things Behavior & Social Responsibility

As far as it remained intrinsically symbolic, the internet has been able to carry on with its utopian principles despite bumpy business environments. But things have drastically changed the situation, with tectonic frictions between symbolic and real plates wreaking havoc with any kind of smooth transition to internet.X, whatever x may be.

Yet, as the diagnose is clear, so should be the remedy.

To begin with, the internet was never meant to become the central nervous system of human societies. That it has happened in half a generation has defied imagination and, as a corollary, sapped the validity of traditional paradigms.

As things happen, the epicenter of the paradigms collision can be clearly identified: whereas the internet is built from systems, architectures taxonomies are purely technical and ignore what should be the primary factor, namely what kind of social role a system could fulfil. That may have been irrelevant for communication networks, but is obviously critical for social ones.

Further Reading

External Links

Business Problems shouldn’t sleep with IT Solutions

October 8, 2016

Preamble

The often mentioned distinction between problem and solution levels may make sense from an analyst’s particular point of view, whether business or system.  But blending problems and solutions independently of their nature becomes a serious over simplification for enterprise architects considering that one of their prime responsibility is to keep apart business problems from IT solutions.

(Mircea Cantor)

Functional problem with technical solution (Mircea Cantor)

That issue is relevant from engineering as well as business perspective.

Engineering View: Problem Levels & Architecture Layers

As long as computers are used to solve problems the only concern is to find the best solution, and the only architecture of concern is software’s.

But enterprise architects have to deal with systems, not computers, namely how to best serve business objectives with corporate resources, across business units and along business cycles. For that purpose resources (financial, human, technical) and their use are to be layered according to the nature of problems and solutions: business processes (enterprise), supporting functionalities (systems), and technologies (platforms).

From an engineering perspective, the intended congruence between problems levels and architecture layers can be illustrated with the OMG’s model driven architecture (MDA) framework:

  • Computation independent models (CIMs) deal with business processes solutions, to be translated into functional problems for supporting systems.
  • Platform independent models (PIMs) deal with functional solutions, to be translated into technical problems for supporting platforms.
  • Platform specific models (PSMs) deal with technical solutions, to be implemented as code.
MDA layers correspond to a clear hierarchy of problems and solutions

MDA layers can be mapped to a clear hierarchy of problems and solutions

Along that understanding, architectures can be seen as solutions, and the primary responsibility of enterprise architects is to see that problems/solutions brace remain in their respective swim-lanes.

Business View: Business Value & Enterprise Assets

Whereas the engineering perspective may appear technical or specific to a model based approach, the same issue is all the more significant when expressed with regard to business concerns and corporate governance. In that case the critical distinction is between business value and assets:

  • Business value: Problems are set by business opportunities, and solutions by processes and applications. The critical factor is reactivity and time-to-market.
  • Assets: Problems are set by business objectives and strategy, and solutions are to be supported by organization and systems capabilities. The critical factor is reuse and ROI.
Decision-making must distinguish between business opportunities and enterprise governance

Decision-making must distinguish between business opportunities and enterprise governance

If opportunities are to be seized and operations managed on the fly  yet tally with strategic decisions, respective problems and solutions should be kept apart. Juggling with their dynamic alignment is at the core of enterprise architects’ job description.

Enterprise Architects & Governance

Engineering and business perspectives are not to be seen as the terms of an alternative to be picked by enterprise architects. As a matter of fact they must be crossed and governance policies selected depending on the point of view:

  • Looking at EA from an engineering perspective,  the business one will focus on systems governance and assets management as epitomized by model based systems engineering schemes.
  • Looking at EA from a business perspective, the engineering one will focus on lean and just-in-time solutions, as epitomized by agile development models.

As far as governance of large and complex corporate entities, supposedly EA’s primary target, must deal with tactical, operational, and strategic concerns, the nexus between business and engineering perspectives is where enterprise architects are to stand.

 

 

Zebras cannot be saddled or harnessed

September 23, 2016

As far as standards go, the more they are, the less they’re worth.

nn

Read my code, if you can …

What have we got

Assuming that modeling languages are meant to build abstractions, one would expect their respective ladders converging somewhere up in some conceptual or meta cloud.

Assuming that standards are meant to introduce similarities into diversity, one would expect clear-cut taxonomies to be applied to artifacts designs.

Instead one will find bounty of committees, bloated specifications, and an open-minded if clumsy language confronted to a number of specific ones.

What is missing

Given the constitutive role of mathematical logic in computing systems, its quasi absence in modeling methods of their functional behavior is dumbfounding. Formal logic, set theory, semiotics, name it, every aspect of systems modeling can rely on a well established corpus of concepts and constructs. And yet, these scientific assets may be used in labs for research purposes but they remain overlooked for any practical use; as if the laser technology had been kept out of consumers markets for almost a century.

What should be done

The current state of affairs can be illustrated by a Horse vs Zebra metaphor: the former with a long and proved track record of varied, effective and practical usages, the latter with almost nothing to its credit except its archetypal idiosyncrasy.

Like horses, logic can be harnessed or saddled to serve a wide range of purposes without loosing anything of its universality. By contrast, concurrent standards and modeling languages can be likened to zebras: they may be of some use for their owner, but from an outward perspective, what remains is their distinctive stripes.

So the way out of the conundrum seems obvious: get rid of the stripes and put back the harness of logic on all the modeling horses.

Further Readings

Caminao & EACOE

September 19, 2016

Synopsis

Taking a cue from a recent discussion about the Enterprise Architecture Center Of Excellence (EACOE), the intent of this article is to apply EACOE criteria to the Caminao framework:

(M.Kippenberger)


How to assess EA frameworks and methodologies (M. Kippenberger)

  1. Business Initiatives (Projects): Initiatives should address cross-organizational or individual concerns.
  2. Directed Guidance: Explicit methods, tools, and artifacts.
  3. Consistency and Simplicity: Single frame of symbolic representation and reference.
  4. Structured and Precise Definitions: Frame built from a compact, complete, and consistent set of concepts to be logically extended.
  5. Clarity and Reason in Modeling: Two distinct model sets – Architecture Models and Implementation Models.
  6. Value in Models Transformations: Why develop artifacts that do not lead anywhere?
  7. Skills Acquisition: Enterprise Architecture skills are acquired through practice and experience.
  8. Multiple Architect Roles: Collaboration between the many architect roles in contemporary business.

Business Initiatives: Managing Expectations & Commitments

Enterprise architecture is meant to serve business purposes set across organizational units. If intents and values of corresponding initiatives are to be properly measured and prioritized, portfolios management must tackle two inherent difficulties:

  • How to rank a motley of expectations and commitments possibly subject to cross-dependencies.
  • How to plan and schedule projects whose outcomes are set within changing environments governed along different time-frames.
Qualified Information Flows across Architectures and Processes

Enterprise Architecture & Separation of Concerns

That can be made easier if initiatives are classified and documented according to scope (enterprise, systems, platforms) and purpose (business processes, systems engineering, operations).

Frame of Reference: A Comprehensive and Consistent Modeling Paradigm

Enterprise architecture as a corporate discipline is upheld by the needs of large and complex organizations, which implies a wide range of units carrying out their projects according to their own concerns, organization, and methods.

Targets and Modeling Languages

All-inclusive Modeling Paradigm: Scope and Languages

As it’s safe to assume that different modeling languages are also involved, a frame of reference must be supported by a modeling paradigm covering the shared semantics of the basic domains of concern, namely: business processes, enterprise organization, systems functional architectures, and software engineering. That can be done with the conceptual backbone of the Caminao framework.

Directed Guidance: Model Driven Architecture

To be of any use, methods and tools should not become a constraint, introduce cumbersome procedures, or induce unjustified overheads. Hence the benefit of model based blueprints that could be adjusted according to the nature of problems (business value, assets, operations) and contexts (enterprise, systems, technologies), e.g:

  • Agile processes will combine requirements with development and bypass analysis phases (a).
  • Projects meant to be implemented by Commercial-Off-The-Shelf Software (COTS) will start with business requirements, possibly using BPM, then carry on directly to platform implementation, bypassing system analysis and design phases (b).
  • Changes in enterprise architecture capabilities will be rooted in analysis of enterprise objectives, possibly but not necessarily with inputs from business and operational requirements, continue with analysis and design of systems functionalities, and implement the corresponding resources at platform level (c).
  • Projects dealing with operational concerns will be conducted directly through systems design and platform implementation (d).
Processes should be devised according enterprise concerns and engineering contexts

Blueprints set according to layers and purpose

That scheme illustrates the benefits of  combining EA with model based engineering schemes.

Consistency and Simplicity: Seven Concepts & Three layers

As far as architectures are concerned, consistency and simplicity are best achieved through a clear understanding of architecture capabilities as defined by the Zachman framework: who, what, how, where, and when.

ccc

Well established concepts are used to describe architecture capabilities

The semantics are to be defined in relation to architecture level: business, systems, and platforms. The role of enterprise architects is then to see how assets can best realize capabilities, and to align processes to supporting capabilities.

Structured and Precise Definitions: Formal Operators uniformly applied across Modeling Lanes

As illustrated a-contrario by the plenty of “universal” standards, combining simplicity, consistency, and all-inclusive relevancy is not easily achieved.

A way out of the conundrum is to delineate a small set of formal constructs and operators to be uniformly, comprehensively and consistently applied across models to connect, structure, and specialize conceptual nodes independently of their semantics:

vvv

Conceptual nodes are connected, structured, and specialized using a single set of formal constructs.

On one hand such constructs provide a syntactic glue between the building blocs defined from basic concepts. On the other hand the semantics of these blocs can be extended and refined along the four standard modeling lanes (aka perspectives): objects, symbolic representations, activities, and execution states.

Clarity and Reason: Descriptive (extensional) vs Prescriptive (intensional) Models

Clarity for enterprise architects should begin with a distinction between environments and enterprise, the former given as realms of changing opportunities subordinate to external factors, the latter supposedly governed according to purposes and plans. Reason is needed to manage the relationship between environments and enterprise architectures, and that endeavor  fully depends on architects’ ability to build serviceable symbolic representations (aka models).

That makes for two distinct model sets:

  • Business environments are represented by extensional models, i.e ones describing actual objects and activities with regard to the categories set by enterprise business model.
  • Enterprise architectures are described by intensional models, i.e ones prescribing how organization and systems are to be built.
vvv

Two distinct model sets: descriptive for business environments, prescriptive for systems architectures and artifacts.

Depending on size, complexity of organizations and systems, a level of indirection can be managed in between, as illustrated by MDA distinction between computation independent (CIM), platform independent PIM), and platform specific (PSM) models. PIMs and PSMs would correspond respectively to EACOE architecture and implementation.

Value in Models Transformation: Lean, Users Driven, & Knowledge Based

EA being a management discipline, it is bound to induce a motley of models to be shared and distributed across business and supporting units. In order to avoid a glut of redundant models, cumbersome procedures, and poor return on investment, processes have to remain lean and cut to the bone.

That can be achieved if models are justified by clearly identified purpose (governance or engineering), and set with clear semantics (descriptive, prescriptive, or mixed):

  • Descriptive (extensional) ones are supposed to be computation independent models (CIMs) and used to support transformations into other descriptive models, e.g analytical or conceptual ones.
  • Prescriptive (intensional) ones target platform specific models (PSMs), their purpose is to support crossed transformations or code generation targeting different platforms.
  • Mixed ones (PIMs) stand in-between and describe platform independent (aka functional) architectures meant to support business processes and be supported by systems platforms.

Models can then be understood as intermediate products to be processed “just-in-time” depending on users’ drive and artifacts’ status.

cccc

Just-in-time processes & Knowledge Based Models: Computation independent (blue), Platform independent (yellow), Platform specific (grey).

With artifacts “inventories” organized along layers, the traceability and transparency of inputs would be set with regard to embedded knowledge: business, organization and supporting systems, and platform technologies. The value of transformations could then be assessed on that basis.

Skills Acquisition: Modular & Smooth Learning Curve

The range of enterprise architecture skills is by nature multi-faceted and volatile:

  • Multi-faceted: Enterprise architects have to deal with the variety of business domains, the singularity of human organizations, and the technicality of systems architectures.
  • Volatile: enterprise architecture is essentially a work in progress whose purpose is to combine changing environments, emerging structures and behaviors, and planned organization.

If they are to tally with such disparate needs, skills are best defined with regard to a limited number of stable characteristics:

  • Target: Enterprise and business oriented, or systems and technology oriented.
  • Purpose: Architectures or business value.
cc

Skills should be primary defined with regard to purpose and target

Given the diversity and transformations of challenges, the relevant skills have to be adjusted, expanded, and deepened continuously; that can only be achieved through a cross-reinforcement of practical and theoretical abilities combined with a modular and smooth learning curve.

Frameworks built from meticulously detailed processes, or sketched from broadly defined principles are ill-fitted to such pedagogy. By contrast, Caminao is built from a small and robust backbone of formally defined concepts that can be fleshed out with enterprise concrete semantics and decorated with customized terminology. That is to enable a step-by-step and open approach to EA.

Multiple Architect Roles: Responsibilities & Decision-making

As already mentioned, the raison d’être of enterprise architecture is to bring under a single roof business processes, enterprise organization, and IT systems. After dealing with criteria related to artifacts and communication, the last to consider is the way EA frameworks should support the integrity and consistency of decision-making.

The Caminao framework define responsibilities of enterprise architects along two dimensions: models and change management.

Regarding models, the dual perspective (actual vs symbolic) remains at the core of EA decision-making: business environments and processes should never be confused with their symbolic representations as systems surrogates. As a matter of fact managing that relationship is at the core of enterprise architecture, and these models are critical for the definition of responsibilities as well as for the support of collaboration. Bluntly speaking, without that distinction enterprise architects would find nothing to manage.

What moves first: actual contexts and processes or enterprise abstractions

EA Decision-making

Regarding change and decision-making, differentiated models will help enterprise architects with the evolution of structures (objectives and assets) and the conduct of operations (processes and configurations), the former shared across business processes and time-frames, the latter set for specific processes and time cycles.

Concluding Remark: EA as Entropy Antidote

The emergence of EA as a discipline is not happening by chance but as a consequence of the crumbling of the traditional boundaries between enterprises and their environment. Faced with the new challenges of competition in seamless digital environments, enterprises success is conditioned by the plasticity and versatility of their architectures, more precisely on their ability to “digest” the variety of data, process it into serviceable information, to be distributed as knowledge towards the different units depending on purposes and time-scales : assets and organization, business value, systems capabilities.

KEA: Knowledge is the Key to EA

KEA: Knowledge as the Key to EA

Along that reasoning EA can be seen as a natural antidote to entropy: like corporate cousins of  Maxwell’s demon, enterprise architects are to stand at enterprise data gates, looking for changes that could decrease internal complexity relative to the external one.

Further Reading

External Links

Focus: Bounded Contexts & Open Concepts

September 13, 2016

Preamble

Domain Driven Design (DDD), the brainchild of Eric Evans, aims to map out system representations of business entities directly from business concepts and semantics.

Balazs

How to conciliate bounded contexts and open minds (Balazs Szabo)

Four basic tenets are often put ahead to characterize DDD:

  • Layered architectures.
  • Aggregates and threads of continuity and identity.
  • Bounded contexts.
  • Ubiquitous language supporting the communication between business domains and software representations.

If the meaning and benefits of layers and aggregates are widely understood, there is less of a consensus about practical implementation of bounded contexts and ubiquitous languages.

Architecture Layers

All too often, modelers overlook the difference between descriptive and prescriptive models, the former depicting business environments and objectives, the latter their symbolic representations in systems. Unfortunately, this seemingly benign neglect seems to imply that descriptive models have no other purpose than supporting the development of systems, which can subsequently stand on their own. But what may once have been a safe assumption is now a very hazardous one considering that today’s IT systems must be weaved with enterprise environment and accommodate continuously to its changes.

cc

Feeding development processes is not the only purpose of descriptive models.

On that regard Domain Driven Design seems inconclusive: on one hand it insists upon the tie between concepts and implementations, on the other hand it makes a clear distinction between concepts (roots and aggregates), and their use (contexts). Setting DDD layers with regard to enterprise architecture could help to clarify the point.

With regard to software (as opposed to enterprise) architecture, DDD identifies four layers: users interfaces (or presentation), applications, domains (or models), and infrastructures. Of these, the domain layer seems to be the only one unambiguously set apart, definitions of the others leaving room for overlaps; but potential qualms can be easily remedied by introducing formal criteria:

  • Presentation: non shared processing of I/O.
  • Application: shared processing of transient representations
  • Domain: shared access to persistent representations
  • Infrastructure: shared access to services.
Architecture Functional layers understood as PIM artifacts.

Architecture Functional layers understood as PIM artifacts.

Furthermore, these layers are best understood when associated with the platform independent models (PIMs) of the model driven architecture (MDA) framework.

Aggregates & Roots

The distinction between the identity and structure of objects on one hand, features semantics and use on the other hand, is arguably a core tenet of DDD as it brings together objects designs and systems architectures.

With regard to objects design, aggregates to be accessed through a single root (#) guarantee the continuity and integrity of the threads anchoring business entities to their symbolic counterparts.

With regard to systems architectures, features of business entities surrogates can be shared across domains, each according to their own semantics, as epitomized by persons in the example below.

vvvv

Roots anchor identified (#) persons to their symbolic surrogates

Yet, the fact is that approach combines object with aspect oriented designs and its implementation at architecture level could come with serious drawbacks when functional facets are to be shared across domains. That’s where bounded contexts intervene.

Bounded Contexts

Contexts are introduced to conciliate continuity and integrity, managed through aggregates, and semantics and functional accesses, managed through contexts; bounded contexts (BCs) are ones with shared business entities. Adding to the example above, person usually appears in different functional contexts subject to specific responsibilities, with one and only one with explicit responsibility on aggregates (#).

Bounded contexts are used to distinguish between identification and integrity, managed through aggregates, and semantics and use, managed through contexts.

Bounded contexts are used to distinguish between identification and integrity, managed through aggregates, and semantics and use, managed through contexts.

But as sound and useful as bounded contexts may be conceptually, their implementation is mostly entrusted to maps and best practices. Since the way shared business domains are managed by systems is arguably a key success factor of enterprise architectures, the lack of principled implementation schemes leaves the conceptual gap between business domains and software designs unaccounted for. That would be the purpose of ubiquitous languages (UL).

Ubiquitous or Domain Specific Languages.

The explicit objective of ubiquitous languages is to bring under a common semantic roof domain analysis and software design, and so to tie concepts and implementations. But that very endeavor may also be seen as controversial, shallow, and confusing:

  • Controversial: bringing together concepts and implementations appears to contradict OO principles as well as layered architectures.
  • Shallow: the so-called languages (as many as domains ?) are in fact just lists of entities and operations, without grammar or unifying semantics.
  • Confusing: they are supposedly derived from models, which would suggest specificity instead of ubiquity; that understanding would also belie the customary assumption that models are built with modeling languages.

One way out of the conundrum could be to see ubiquitous languages as variants of domain specific ones whose explicit objective is precisely to tie concepts with implementations. But that option would bypass the issue of principled BC design, and more generally the relationship between business domains, systems architectures, and software designs.

The other way would be to forsake ubiquitous (or specific) languages and use instead open concepts and functional patterns.

Bounded Contexts & Open Concepts

Open concepts are modeling artifacts whose semantics can be shared by business domains and systems functional architectures. For that purpose they have to meet standard OO principles:

  • Open-Closed Principle (OPC): open concepts should have no reason to change, they can only be refined. In other words open concepts are meant to be specialized, but not generalized. That ensures that the semantics of sub-types defined by different projects cannot be modified.
  • Substitution Principle (LSP): sets of instances denoted by specialized concepts are subsets of the sets denoted by more general ones. That ensures that individuals are consistently identified across projects.
  • Dependency-Inversion principle (DIP): higher levels semantics are defined independently of lower levels. That ensures that the semantics of sub-types are consistently, but not necessarily uniformly, defined across projects.
  • Interface-Segregation Principle (ISP): semantics and features are congruent, i.e all features are meaningful for whoever is using the concept. That ensures that there is no overlapping of semantics even when subsets of individuals overlap.

Assuming these criteria can be fulfilled, open concepts can be used as a modeling glue between bounded contexts overlaps.

Open concepts for entities (aka roots):

  • Structural inheritance means that the targeted entities (i.e shared between contexts) inherit both structures and aspects: parties are a subset of social agents.
  • Functional inheritance means that the targeted entities inherit all the aspects whatever the identified structure: an organization has all the features of a collective agent but is not necessarily identified as such.
vvv

How to consolidate contexts overlaps using open concepts

Open concepts for aspects (aka features):

  • Structural inheritance is equivalent to composition, i.e inherited aspects are bound to domain individuals whatever their structure: symbolic references are an intrinsic component of products but can be used in any kind of domain.
  • Functional inheritance is equivalent to aggregation, i.e inherited aspects are not bound to domain individuals: business roles can combine different ones.

On a broader perspective, using open concepts to consolidate the overlaps between bounded contexts enables the formal verification of models, not only for internal consistency but also with regard to best practices. And best practices can be translated into functional (aka representation) patterns formally defined in terms of open concepts.

Further Readings

External Links

Models as Parachutes

August 31, 2016

Preamble

The recent crash of Delta Airlines’ reservation system, following a number of similar incidents, have raised new concerns about the reliability of a whole generation of large and critical IT systems.

László Moholy-Nagy-para

Models as Parachutes (László Moholy-Nagy)

Particularly at risk are airlines or banking systems, whose seasoned infrastructures, at the cutting edge when introduced half a century ago, have been strained to their limit by waves of extensive networked new functionalities. Confronted to the magnitude and complexity of overall modernization, most enterprises have preferred piecemeal updates to architectural leaps. Such policies may bring some respite, but they may also turn into aggravating factors, increasing stakes and urgency as well as shortening odds.

Assuming some consensus about stakes, hazards, and options, the priority should be to overcome jumping fears by charting a reassuring perspective in continuity with current situation. For that purpose models may provide heartening parachutes.

Models: Intents & Doubts

Models can serve two kinds of purposes:

  • Describe business contexts according to enterprise objectives, foretell evolution, and simulate policies.
  • Prescribe the architecture of supporting systems and the design of software components.
Business analyst figure maps from territories, software architects create territories from maps

Models Purposes: Describe contexts & concerns, Design supporting systems

Frameworks were supposed to combine the two perspectives, providing a comprehensive and robust basis to systems governance. But if prescriptive models do play a significant role in engineering processes, in particular for code generation, they are seldom fed by their descriptive counterpart.

Broadly speaking, the noncommittal attitudes toward descriptive models comes from a rooted mistrust in non executable models: as far as business analysts and software engineers are concerned, such models can only serve as documentary evidence. And since prescriptive models are by nature grounded to systems’ inner making, there is no secure conceptual apparatus linking systemic changes with their technical consequences. Hence the jumping frights.

Overcoming those frights could be achieved by showing the benefits of secure and soft landings.

Models for Secure Landings

As any tools, models must be assessed with regard to their purpose: prescriptive ones with regard to feasibility and reliability of architectures and design, descriptive ones with regard to correctness and consistency. As already noted, compared to what has been achieved for the former, nothing much has been done about the validity of the latter.

Yet, and contrary to customary beliefs, the rigorous verification of descriptive (aka extensional) models is not a dead-end. Of course these models can never be proven true because there is no finite scope against which they could be checked; but it doesn’t mean that nothing can be done to improve their reliability:

Models must be assessed with regard to their purpose

How to Check for secure landings

  • Correctness: How to verify that all the relevant individuals and features are taken into account. That can only be achieved empirically by building models open to falsification.
  • Consistency: How to verify that the symbolic descriptions (categories and connectors) are complete, coherent and non redundant across models and abstraction levels. That can be formally verified.
  • Alignment: How to verify that current and required business processes are to be seamlessly and effectively supported by systems architectures. That can be managed by introducing a level of indirection, as illustrated by MDA with platform independent models (PIMs) set between computation independent (CIMs) and platform specific (PSMs) ones.

Once established on secure grounds, models can be used to ensure soft landings.

Models for Soft Landings

Set within model based system engineering frameworks, models will help to replace piecemeal applications updates by seamless architectures modernization:

  • Systems: using models shift the focus of change from hardware to software.
  • Enterprise: models help to factor out the role of organization and regulations.
  • Project management: models provide the necessary hinge between agile and phased projects, the former for business driven applications, the latter for architecture oriented ones. Combining both approaches will ensure than lean and just-in-time processes will not be sacrificed to system modernization.
Seamless architectures modernization (a) vs Piecemeal applications updates (b).

Seamless architectures modernization (a) vs Piecemeal applications updates (b).

More generally, and more importantly, models are the option of choice (if not the only one) for enterprise knowledge management:

  • Business: Computation independent models (CIMs), employed to trace, justify and rationalize business strategies and processes portfolios.
  • Systems: Platform specific models (PSMs), employed to trace, justify and rationalize technical alternatives and decisions.
  • Decision-making and learning: Platform independent models (PIMs), employed to align business and systems and support enterprise architecture governance.

And knowledge management is arguably the primary factor for successful comprehensive modernization.

Strategic Decision-making: Cash or Crash

Governance is all about risks and decision-making, but investing on truly fail-safe systems for airlines or air traffic control can be likened to a short bet on the Armageddon, and that cannot be easily framed in a neat cost-benefit analysis. But that may be the very nature of strategic decision-making: not amenable to ROI but aiming at risks assessment and the development of the policies apt to contain and manage them. That would be impossible without models.

Further Reading

Focus: Business Processes & Abstraction

July 16, 2016

Preamble

Abstractions, and corollary inheritance, are primarily understood with objects. Yet, since business processes are meant to focus on activities, semantics may have to be refined when abstraction and inheritance are directly used for behaviors.

(Antony Gormley)

Abstract objects cannot be directly mapped to abstract behaviors (Antony Gormley).

Considering that the primary purpose of abstractions is to tackle business variants with regard to supporting systems, their representation with use cases provides a good starting point.

Business Variants: Use case’s <extend> & <include>

Taking use cases as a modeling nexus between business and systems realms, <extend> and <include> appear as the default candidates for the initial description of behaviors’ specialization and generalization.

  • <include>: to be compared to composition semantics, with the included behaviors performed  by instances identified (#) by the owner UC (a).
  • <extend>: to be compared to aggregation semantics, with the extending behaviors performed  by separate instances with reference to the owner ones (b).
Included UCs are meant to be triggered by owners (a); that cannot be clearly established for abstract use cases and generalization (c).

Included UCs are meant to be triggered by owners (a); that cannot be clearly established for abstract use cases and generalization (c).

Abstract use cases and generalization have also been mentioned by UML before being curiously overlooked in following versions. Since none has been explicitly discarded, some confusion remains about hypothetical semantics. Notionally, abstract UCs would represent behaviors never to be performed on their own (c). Compared to inclusion, used for variants of operations along execution paths, abstract use cases would describe the generic mechanisms to be applied to triggering events at UC inception independently of actual business operations carried out along execution paths.

Nonetheless, and more importantly, the mix-up surrounding the generalization of use cases points to a critical fault-line running under UML concepts: since both use cases and classes are defined as qualifiers, they are supposed to be similarly subject to generalization and specialization. That is misguided because use cases describe the business behaviors to be supported by systems, not to be confused with the software components that will do the job. The mapping between the former and the latter is to be set by design, and there is no reason to assume a full and direct correspondence between functional requirements and functional architecture.

Use Cases Distilled

As far as use cases are considered, mapping business behaviors to supporting systems functionalities can be carried out at two levels:

  • Objects: UCs being identified by triggering agents, events, and goals, they are to be matched with corresponding users interfaces and controllers, the former for the description of I/O flows, the latter for the continuity and integrity of interactions.
  • Methods: As it’s safe to assume that use cases are underpinned by shared business functions and system features, a significant part of their operations are to be realized by methods of shared business entities or services.
vv

Setting apart UIs and controllers, no direct mapping should be assumed between use cases and functional qualifiers.

The business variants distilled into objects’ or services’ methods can be generalized and specialized according to OOD principles; and the same principles can be applied to specific users’ interfaces. But since purely behavioral aspects of UCs can neither be distilled into objects’ methods, nor directly translated into controller objects, their abstraction semantics have to be reconsidered.

Inheritance Semantics: Structural vs Functional

As far as software artifacts are concerned, abstraction semantics are set by programming languages, and while they may differ, the object-oriented (OO) paradigm provides some good enough consolidation. Along that perspective, inheritance emerges as a critical issue due to its direct impact on the validity of programs.

Generally speaking, inheritance describes how structural or behavioral traits are passed from ancestors to descendants, either at individual or type level. OO design is more specific and puts the focus on the intrinsic features (attributes and operations) supported by types or classes, which ensues that behaviors are not considered as such but through the objects’ methods that realize them:

  • Structural inheritance deals with attributes and operations set for the whole life-cycle of instances. As a consequence corresponding inheritance is bound to identities (#) and multiple ascendants (i.e identities) are ruled out.
  • Functional inheritance deal with objects behaviors which may or may not be frozen to whole life-cycles. Features can therefore be inherited from multiple ascendants.

That structural vs functional distinction matches the one between composition and aggregation used to characterize the links between objects and parts which, as noted above, can also be applied to uses cases.

Use Cases & Abstraction

Assuming that the structural/functional distinction defined for objects can also be applied to behaviors, use cases provide a modeling path from variants in business processes to OOD of controllers:

  • Behaviors included by UCs (a) are to be set along the execution paths triggered by UC primary events (#). Inheritance is structural, from UCs base controllers to corresponding (local) ones, and covers features (e.g views on business objects) and associated states (e.g authorizations) defined by use case triggering circumstances.
  • Behaviors extending UCs (b) are triggered by secondary events generated along execution paths. Inheritance is functional, from extending UCs (e.g text messaging) to UCs primary controllers.

Yet this dual scheme may not be fully satisfactory as it suffers from two limitations:

  • It only considers the relationships between UCs, not with the characteristics of the use cases themselves.
  • It ignores the critical difference between the variants of business logic and the variants of triggering conditions.

Both flaws can be patched up if abstract use cases are specifically introduced to factor out triggering circumstances (c):

Use cases provide a principled modeling path from variants in business processes to the OOD of corresponding controllers.

Use cases provide a principled modeling path from variants in business processes to the OOD of corresponding controllers.

  • Undefined triggering circumstances is the only way to characterize abstraction independently of what happens along execution paths.
  • Abstract use cases can then be used to specify inception mechanisms to be inherited by concrete use cases.

That understanding of abstract use cases comes with clear benefits with regard to security and confidentiality.

What is at Stake

Factoring out authentication and authorization epitomizes the benefits of abstract UCs:

  • Concrete schemes with included UC will give access to all registered users with the particulars of managers or customers checked later (a).
  • Alternatively, abstract schemes will use inheritance of inception mechanisms in order to explicitly prevent separate access (c).
  • Applying <include> with abstract UC should be ruled out because it would make room for the execution of operations with undefined triggering circumstances.
Interactions can only be triggered by concrete actors.

Interactions can only be triggered by concrete actors.

As a conclusion, by enabling a clear distinction between business logic and operational circumstances, abstraction can reinforce the security of functional architectures.

Further Reading