Category: MDA

Conceptual Models & Abstraction Scales

Following the recent publication of a new standard for conceptual modeling of automation systems (Object-Process Methodology (ISO/PAS 19450:2015) it may be interesting to explore how it relates to abstraction and meta-models.

oskar-schlemmer-at-bahaus
Meta-models are drawn along lean abstraction scales (Oskar Schlemmer )

Models & Meta Models

Just like models are meant to describe sets of actual instances, meta-models are meant to do the same for sets of modeling artifacts independently of their targets. Along that reasoning, conceptual modeling of automation systems could be achieved either with a single language covering all aspects, or with a meta-language dealing with different sets of models, e.g MDA’s computation independent, platform independent, and platform specific models.

Modeling Languages covering technical, functional, and business concerns.
Two alternative options for the modeling of automation systems: unified language, or a meta language covering technical (e.g PSMs), functional (e.g PIMs), and business (e.g CIMs) scopes.

Given a model based engineering framework (e.g MDA), meta-models are generally used to support downstream models transformation targeting designs and code. But when upstream conceptual models are concerned, the challenge is to tackle the knowledge-to-systems transition. For that purpose some shared modeling roof is required for the definition of the symbolic footprint of the targeted business in the automation system under consideration.

Symbolic Footprint

Given that automation systems are meant to manage symbolic objects (aka surrogates), one should expect the distinction between actual instances and their symbolic representations to be the cornerstone of corresponding modeling languages. Along that reasoning, modeling of automation systems should start with the symbolic representation of actual business footprints, namely: the sets of objects, events, and processes, the roles played by agents (aka active objects), and the description of the associated states and rules. Containers would be added for the management of collections.

Automation systems modeling begins with the symbolic representation of actual instances
Automation systems modeling begins with the symbolic representation by systems of actual instances of business related objects and phenomena.

Next, as illustrated by the Object/Agent hierarchy, business worlds are not flat but built from sundry structures and facets to be represented by multiple levels of descriptions. That’s where abstractions are to be introduced.

Abstraction & Variants

The purpose of abstractions is to manage variants, and as such they can be used in two ways:

  • For partial descriptions of actual instances depending on targeted features. That can be achieved using composition (for structural variants) and partitions (for functional ones).
  • As hierarchies of symbolic descriptions (aka types and sub-types) subsuming variants identified at instances level.

On that basis the challenge is to find the level of detail (targeted actual instances) and abstraction (symbolic footprint) that will best describe supporting systems functionalities. Such level will have to meet two conditions:

  1. A minimal number of comprehensive and exclusive categories covering the structural variants of the sets of instances to be uniformly, consistently, and continuously identified by both enterprise and supporting systems.
  2. A consistent but adjustable set of types and sub-types anchored to the core structural categories and covering the functional variants .

Climbing up and down abstraction ladders looking for right levels is arguably the critical part of conceptual modeling, but the search will greatly benefit from the distinction between models and meta-models. Assuming meta-models are meant to ignore domain specific features altogether, they introduce a qualitative gap on abstraction scales as the respective hierarchies of models and meta-models are targeting different kind of instances. The modeling of agents and roles epitomizes the benefits of that distinction.

Abstraction & Meta Models

Taking customers for example, a naive approach would use Customer as a modeling type inheriting from a super-type, e.g Party. But then, if parties are to be uniformly identified (#), that would preclude any agent for playing multiple roles, e.g customer and supplier.

A separate description of parties and roles would clearly be a better option as it would unify the identification of the former without introducing unwarranted constraints on the latter which would then be defined and identified as the realization of a relationship played by a party.

Not surprisingly, that distinction would also be congruent with the one between models and meta-model:

  • Meta-models will describe generic aspects independently of domain-specific considerations, in particular organizational context (units and roles) and interactions with systems (a).
  • Models will define Staff, Supplier and Customer according to the semantics of the business considered (b).
Composition, partitions and specialization can be used to detail the symbolic footprint
Composition, partitions and specialization can be used along two different abstraction scales.

That distinction between abstraction scales can also be applied to the conceptual modeling of automation systems.

Abstraction Scales & Conceptual Models

To begin with definitions, conceptual representations could be used for all mental constructs, whereas symbolic representations would be used only for the subset earmarked for communication purposes. That would mean that, contrary to conceptual representations that can be detached of business and enterprise practicalities, symbolic representations are necessarily built on design, and should be assessed accordingly. In our case the aim of such representations would be to describe the exchanges between business processes and supporting systems.

That understanding neatly fits the conceptual modeling of automation systems whose purpose would be to consolidate generic and business specific abstraction scales, the former for symbolic representations of the exchanges between business and systems, the latter symbolic representation of business contents.

At this point it must be noted that the scales are not necessarily aligned in continuity (with meta-models’ being higher and models’ being lower) as their respective ontologies may overlap (Organizational Entity and Party) or cross (Function and Role).

Toward an Ontological Framework for Enterprise Architectures Modeling

Along an analytic perspective, ontologies are meant to determine the categories that can comprehensively and consistently denote the instances of a domain under consideration; applied to enterprise concerns that would entail:

  • Thesaurus: for the whole range of terms and concepts.
  • Documents: for documents with regard to topics.
  • Business: for enterprise organization and business objects and activities.
  • Engineering: for systems surrogates associated to enterprise organization and business objects and activities
Ontologies provide a common conceptual framework for  models and meta-models

That would open the door to a seamless integration of business intelligence, systems engineering, knowledge management, and decision-making.

Further Reading

External Links

Enterprise Systems & the OS Kernel Paradigm

Preamble

Given the ubiquity of information and communication technologies on one hand, the falling apart of technical fences between systems, enterprises, and business environments on the other hand, applying the operating system (OS) paradigm to enterprise architectures seems a logical move.

Users and access to services (Queuing at a Post Office in French West Indies)

Borrowing the blueprint of computers operating systems, enterprise operating systems (EOS) would  be organized around a kernel managing shared resources (people, hardware and software) and providing services to business, engineering or operational processes.

Gerrymandering & Layers

When IT was neatly fenced behind computer screens managers could keep a clear view on organization, roles, and responsibilities. But with physical hedges replaced by clouded walls, the risk is that IT may appear as the primary constituent of enterprise architecture. Given the lack of formal arguments against what may be a misguided understanding, enterprise architects have to rely on pragmatic answers. Yet, they could prop their arguments by upending the very principles of IT operating systems and restore the right governance footprint.

To begin with, turfs must be reclaimed, and that can be done if the whole of assets and services are layered according to the nature of problems and solutions: business processes (enterprise), supporting functionalities (systems), and technologies (platforms).

Problems and solutions must be set along architecture layers
EA must separate and federate concerns along architecture layers

Then, reclaiming must also include governance, and for that purpose EOS are to rely on a comprehensive and consistent understanding of assets, people and mechanisms across layers:

  • Physical assets, including hardware.
  • Non physical assets, including software.
  • Agents (identified people with organizational responsibilities) and roles.
  • Events (changes in the state of objects, processes, or expectations) and activities.

Mimicking traditional OS, that could be achieved with a small and compact conceptual kernel of formal concepts bearing out the definitions of primitives and services for the whole of enterprise processes.

EOS’s Kernel: 12 concepts

A wealth of definitions may be the main barrier to enterprise architecture as a discipline because such profusion necessarily comes with overlaps, ambiguities, and inconsistencies. Hence the benefit of relying on a small set of concepts covering the whole of enterprise systems:

  • Six for individuals actual (objects, events, processes) and symbolic (surrogates objects, activities, roles) elements.
  • One for actual (locations) or symbolic (package) containers.
  • One for the partitioning of behaviors (branch) or surrogates (power type).
  • Four for actual (channels and synchronization) and symbolic (references and flows) connectors.
Semantics
Governance calls for comprehensive and consistent semantics

Considering that nowadays business entities (enterprise), services (systems), and software components (technology) share the same distributed world, these concepts have to keep some semantic consistency across layers whatever their lexical avatars. To mention two critical examples, actors (aka roles) and events must be consistently understood by business and system analysts.

Those concepts are used to describe enterprise systems building blocks which can be combined with a small set of well known syntactic operators:

  • Two types of connectors depending on target: instances (associations) or types (inheritance).
  • Three types connections for nondescript, aggregation, and composition.
UMLSharp_syntax
Syntactic operators are meant to be applied independently of targets semantics

Again, Occam’s razor should be the rule: just like semantics are consistently defined across architecture layers, the same syntactic operators are to be uniformly applied to artifacts independently of their semantics.

Kernel’s Functions

Continuing with the kernel analogy, based on a comprehensive and consistent description of resources, the traditional OS functions can be reinterpreted with regard to architecture capabilities implemented across layers:

  • What: memory of business objects and operations (enterprise), data base logical entities (systems), data base physical records (platforms).
  • Who: roles (enterprise), logical interfaces (systems), and physical entry points (platforms).
  • When: business events and processes (enterprise), transaction management (systems), and middleware (platforms).
  • Where: sites (enterprise), logical processing units (systems), network architecture (platforms).
  • How: business processes (enterprise), applications (systems), and programs (platforms).
Traceability of Capabilities across architecture layers

That fits with the raison d’être of a kernel which is to combine core functions in order to support the services called by processes.

Services

Still milking the OS analogy, a primary goal of an enterprise kernel is to support a seamless integration of services:

  1. Business driven: the definition of services must be directly and unambiguously associated to business ends and means across enterprise layers.
  2. Traceability: they must ensure the transparency of the tie-ups between organization and processes on one hand, information systems on the other hand.
  3. Plasticity: they must facilitate the alignment of changes in business objectives, organization and supporting systems.

A reasoned way to achieve these objectives is to classify services with regard to the purpose of calling processes:

  • Business processes deal with the transactions between the enterprise and its environment.
  • Engineering processes deal with the development of enterprise resources independently of their use.
  • Operational processes deal with the management of enterprise resources when directly or indirectly used by business processes.
Enterprise Operating System: Layers & Services
Enterprise Operating System: Layers & Services

That classification can then be crossed with architecture levels:

  • At enterprise level services are bound to assets to be used by business, engineering, or operational processes.
  • At systems level services are bound to functions supporting business, engineering, or operational processes.
  • At platform level services are bound to resources used by business, engineering, or operational processes.

As services will usually rely on different functions across layers, the complexity will be dealt with by kernel primitives and masked behind interfaces.

Services called by processes can combine different functions directly (basic lines) or across layers (dashed lines).

Finally, that organization of services along architecture layers may be aligned with governance levels: strategic for enterprise assets, tactical for systems functionalities, and operational for platforms and resources.

Further Reading

Agile Architectures: Versatility meets Plasticity

Synopsis

At enterprise level agility can be understood as a mix of versatility and plasticity, the former an attribute of function, the latter of form:

  • Versatility: enterprise ability to adapt business processes to changing environments without having to change architectures.
  • Plasticity: enterprise ability to change architectures without affecting business processes.
Plasticity is for form, versatility for function
Agility: Forms & Performances (P. Pénicaud)

Combining versatility and plasticity requires a comprehensive and consistent view of assets (architectures) and modus operandi (processes) organized with regard to change. And that can be achieved with model based systems engineering (MBSE).

MBSE & Change

Agility is all about change, and if enterprise governance is not to be thrown aside decision-making has to be supported by knowledgeable descriptions of enterprise objectives, assets, and organization.

If change management is to be the primary objective, targets must be classified along two main distinctions:

  • Actual (business context and organization) or symbolic (information systems).
  • Objects (business entities or system surrogates) or activities (business processes or logic).
Entropy_muove
Comprehensive and consistent descriptions of actual and symbolic assets (architectures) and modus operandi (processes) with regard to change management.

The two axis determine four settings supporting transparency and traceability:

  • Dependencies between operational and structural elements.
  • Dependencies between actual assets and processes and their symbolic representation as systems surrogates.

Versatility and plasticity will be obtained by managing changes and alignments between settings.

Changes & Alignments

Looking for versatility, changes in users’ requirements must be rapidly taken into account by applications (changes from actual to symbolic).

Looking for plasticity, changes in business objectives are meant to be supported by enterprise capabilities (changes from operational to structural).

The challenge is to ensure that both threads can be weaved together into business functions and realized by services (assuming a service oriented architecture).

With the benefits of MBSE, that could be carried out through a threefold alignment:

  • At users level the objective is to ensure that applications are consistent with business logic and provide the expected quality of service. That is what requirements traceability is meant to achieve.
  • At system level the objective is to ensure that business functions and features can be directly mapped to systems functionalities. That is what services oriented architectures (SOA) are  meant to achieve.
  • At enterprise level the objective is to ensure that the enterprise capabilities are congruent with its business objectives, i.e that they support its business processes through an effective use of assets. That is what maturity and capability models are meant to achieve.
Alignment
Versatility comes from users’ requirements, plasticity from architectures capabilities.

That would make agility a concrete endeavor across enterprise, from business users and applications to business processes and architectures capabilities.

Further Reading

Inducing Functional Patterns from Design ones: a look in rear view mirror

Preamble

Assuming patterns are meant to chart the path from problems to solutions, and given the foundational contribution of the Gang of Four (GoF), it may help to look at functional (aka representation) patterns backward  from the perspective of the now well established solutions framework (aka design patterns).

(M.Kippenberger)
Matching Patterns (M.Kippenberger)

Patterns & Models

Patterns are handrails from stereotyped problems to well known and tested solutions, bringing the benefits of reuse for costs, quality, and traceability. Set within the Model Driven Architecture, patterns can be regrouped depending on their source and target:

  • Functional patterns deal with the representation of business objects and activities by system symbolic surrogates. They stand between computation and platform independent models. Whereas functional patterns are not to be confused with business patterns (used with CIMs), they are also known as analysis patterns when targeting PIMs.
  • Design patterns deal with the implementation of symbolic surrogates as software components.  They stand between platform independent and platform specific models.
MDA layers clearly coincide with reusable assets
Patterns and MDA layers

As it happens, there is a striking contrast between the respective achievements for design and functional (or analysis) patterns, the former, firmly set up by the pivotal work of the GoF, is nowadays widely and consistently applied to software design; the latter, frustrated by the medley of requirements capture, remain fragmented and confined to proprietary applications. Given that discrepancy, it may be worth to look in the rear-view mirror  and consider functional patterns from the perspective of design ones.

Objects, Classes, & Types

Design patterns are part and parcel of the object oriented (OO) approach and built on some of its core tenets, in particular:

  • Favor object composition over class inheritance.
  • Program to an interface, not an implementation.

Whereas the meaning of classes, implementation, and inheritance is specific to OO design, the principles can nonetheless bear upon analysis providing they are made to apply to types and composition, whose semantics have a broader scope. To begin with, if classes describe the software implementation of symbolic objects, and inheritance the relationships between them, types only pertain to their functional capabilities. As a corollary, the semantics of inheritance and composition makes no difference with regard to types, as opposed to classes. The lesson for functional patterns would therefore to favor types whenever possible, i.e when functional capabilities doesn’t depend on identities. Then, “programming to interfaces” would translate (for functional patterns) into describing communications between types. That approach being best represented by aspect oriented analysis. Not by chance, the lessons drawn above appear to be directly supported by the two criteria used by the the GoF to classify design patterns: scope and purpose. With regard to scope, class patterns deal with inheritance relationships between static descriptions fixed at compile-time, while object patterns deal also with relationships between instances which can be changed at run-time. With regard to purpose, creational patterns deal with objects instanciation, structural ones carry on with composition, and behavioral ones with algorithms and responsibilities.

Design Patterns Catalog
Design Patterns Catalog

The corresponding entries can be summarily described as:

  • Class/Creational: for new identified instances.
  • Object/Creational: for new parts of identified instances.
  • Class/Structural: for mixing interfaces using inheritance.
  • Object/Structural: for mixing interfaces using composition.
  • Class/Behavioral: for the definition of algorithms.
  • Object/Behavioral: for the collaboration between instances.

The next step would be to induce a catalog of functional patterns from those entries.

Inducing a Catalog of Functional Patterns

Leveraging the GoF’s design patterns, the objective is to spread the benefits upstream to the whole of the modeling process through a transparent mapping of functional and design patterns. And that could be achieved by inducing a functional catalog from its design equivalent. With regard to scope, the objective would be to factor out the architectural impact of requirements. Hence the distinction between architecture patterns dealing with business entities and processes consistently identified at enterprise and system levels, and aspect patterns dealing with features that can be managed separately. With regard to purpose the same semantics can be applied: creational patterns deal with objects instanciation, structural ones carry on with their composition and features, and behavioral ones with algorithms and responsibilities.

Functional Patterns Catalog: examples
Functional Patterns Catalog: examples
  • Architecture/Creational: for the mapping of business entities to their software surrogates. For instance, customers must be identified as parties (architecture/creational) before being fleshed out with specific features.
  • Aspect/Creational: for the intrinsic components of identified business entities. For instance, once created and identified as a customer, a foreign one is completed with the specific mandatory features of foreigners.
  • Architecture/Structural:  for inherited (i.e intrinsic) features of identified business entities.  For instance, foreign sales inherit specific invoice features.
  • Aspect/Structural:  for associated (intrinsic or otherwise) features of identified business entities. For instance, foreign sales delegate invoicing in foreign currencies.
  • Architecture/Behavioral: for the definition business rules attached to entities and managed by business domains. For instance invoicing rules are specialized for foreign currencies.
  • Aspect/Behavioral: for the definition of collaboration between entities independently of business domains. For instance allocating responsibilities at run-time depending on the invoice.

As can be seen with the MDA diagram above, this catalog is neutral as its entries are congruent with the categories used by the main modeling methodologies : use cases, domains, business rules, services, objects, aspects, etc.

Recommended Reading

Gamma E., Helm R., Johnson R. and Vlissides John M. , “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley (1994).

Further Reading

MDA & EA: Is The Tail Wagging The Dog ?

Making Heads or Tails

OMG’s Model Driven Architecture (MDA) is a systems engineering framework set along three model layers:

  • Computation Independent Models (CIMs) describe business objects and activities independently of supporting systems.
  • Platform Independent Models (PIMs) describe systems functionalities independently of platforms technologies.
  • Platform Specific Models (PSMs) describe systems components as implemented by specific technologies.

Since those layers can be mapped respectively to enterprise, functional, and technical architectures, the question is how to make heads or tails of the driving: should architectures be set along model layers or should models organized according architecture levels.

(judy Kensley McKie)
A Dog Making Head or Tail (Judy Kensley McKie)

In other words, has some typo reversed the original “architecture driven modeling” (ADM) into “model driven architecture” (MDA) ?

Wrong Spelling, Right Concepts

A confusing spelling should not mask the soundness and relevance of the approach: MDA model layers effectively correspond to a clear hierarchy of problems and solutions:

  • Computation Independent Models describe how business processes support enterprise objectives.
  • Platform Independent Models describe how systems functionalities support business processes.
  • Platform Specific Models describe how platforms implement systems functionalities.

MDA layers correspond to a clear hierarchy of problems and solutions
MDA layers correspond to a clear hierarchy of problems and solutions

That should leave no room for ambiguity: regardless of the misleading “MDA” moniker,  the modeling of systems is meant to be driven by enterprise concerns and therefore to follow architecture divides.

Architectures & Assets Reuse

As it happens, the “MDA” term is doubly confusing as it also blurs the distinction between architectures and processes. And that’s unfortunate because the reuse of architectural assets by development processes is at the core of the MDA framework:

  • Business objects and logic (CIM) are defined independently of the functional architectures (PIM) supporting them.
  • Functional architectures (PIM) are defined independently of implementation platforms (PSM).
  • Technical architecture (PSM) are defined independently of deployment configurations.

MDA layers clearly coincide with reusable assets
MDA layers coincide with categories of reusable assets

Under that perspective the benefits of the “architecture driven” understanding (as opposed to the “model driven” one) appear clearly for both aspects of enterprise governance:

  • Systems governance can be explicitly and transparently aligned on enterprise organization and business objectives.
  • Business and development processes can be defined, assessed, and optimized with regard to the reuse of architectural assets.

With the relationship between architectures and processes straightened out and architecture reinstated as the primary factor, it’s possible to reexamine the contents of models used as hinges between them.

Languages & Model Purposes

While engineering is not driven by models but by architectures, models do describe architectures. And since models are built with languages, one should expect different options depending on the nature of artifacts being described. Broadly speaking, three basic options can be considered:

  • Versatile and general modeling languages like UML can be tailored to different contexts and purposes, along development cycle (requirements, analysis, design) as well as across perspectives (objects, activities, etc) and domains (banking, avionics, etc)
  • Non specific business modeling languages like BPM and rules-based languages are meant to be introduced upfront, even if their outcome can be used further down the development cycle.
  • Domain specific languages, possibly built with UML, are also meant to be introduced early as to capture domains complexity. Yet, and contrary to languages like BPM, their purpose is to provide an integrated solution covering the whole development cycle.

Languages: general purpose (blue), process or domain specific (green), or design.
Languages: general purpose (blue), process or domain specific (green), or design (brown).

As seen above for reuse and enterprise architecture, a revised MDA perspective clarifies the purpose of models and consequently the language options. With developments “driven by models”, code generation is the default option and nothing much is said about what should be shared and reused, and why. But with model contents aligned on architecture levels, purposes become explicit and modeling languages have to be selected accordingly, e.g:

  • Domain specific languages for integrated developments (PSM-centered).
  • BPM for business specifications to be implemented by software packages (CIM-centered).
  • UML for projects set across system functional architecture (PIM-centered).

The revised perspective and reasoned association between languages and architectures can then be used to choose development processes: projects that can be neatly fitted into single boxes can be carried out along a continuous course of action,  others will require phased development models.

Enterprise Architecture & Engineering Processes

Systems engineering has to meet different kinds of requirements: business goals, system functionalities, quality of service, and platform implementations. In a perfect (model driven engineering) world there would be one stakeholder, one architecture, and one time-frame. Unfortunately, requirements are usually set by different stakeholders, governed by different rationales, and subject to changes along different time-frames. Hence the importance of setting forth the primary factors governing engineering processes:

  • Planning: architecture levels (business, systems, platforms) are governed by different time-frames and engineering projects must be orchestrated accordingly.
  • Communication: collaboration across organizational units require traceability and transparency.
  • Governance: decisions across architecture levels and business units cannot be made upfront and options and policies must be assessed continuously.

Those objectives are best supported when engineering processes are set along architecture levels:

Enterprise Architecture & Processes
Enterprise Architecture & Processes

  1. Requirements: at enterprise level requirements deal with organization and business processes (CIMs). The enterprise requirements process starts with portfolio management, is carried on with systems functionalities, and completed with platforms operational requirements.
  2. Problems Analysis: at enterprise level analysis deals with symbolic representations of enterprise environment, objectives, and activities (PIMs). The enterprise analysis process starts with the consolidation of symbolic representations for objects (power-types) and activities (scenarii), is carried on with functional architectures, and completed with platforms non-functional features. Contrary to requirements, which are meant to convey changes and bear adaptation (dashed lines), the aim of analysis at enterprise level is to consolidate symbolic representations and guarantee their consistency and continuity. As a corollary, analysis at system level must be aligned with its enterprise counterpart before functional (continuous lines) requirements are taken into account.
  3. Solutions Design: at enterprise level design deals with operational concerns and resources deployment. The enterprise design process starts with locations and resources, is carried on with systems configurations, and completed with platforms deployments. Part of it is to be supported by systems as designed (PSMs) and implemented as platforms. Yet, as figured by dashed arrows, operational solutions designed at enterprise level bear upon the design of systems architectures and the configuration of their implementation as platforms.

When engineering is driven by architectures, processes can be devised depending on enterprise concerns and engineering contexts. While that could come with various terminologies, the partitioning principles will remain unchanged, 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 of and platform implementation (d).

Processes should be devised according enterprise concerns and engineering contexts
Examples of process templates depending on objectives and contexts.

To conclude, when architecture is reinstated as the primary factor, the MDA paradigm becomes a pivotal component of enterprise architecture as it provides a clear understanding of architecture divides and dependencies on one hand, and their relationship with engineering processes on the second hand.

Postscript

MDA illustrates a contrario the straying agenda of the OMG: despite its soundness as a foundation of enterprise architecture as well as its complementarity with the Unified Modeling Language (UML), MDA three-tiers framework has been left unattended, to be replaced by an open-ended (more than two hundred, and counting) hotpotch of amorphous and overlapping meta-models.

Nonetheless, the paradigm is not to be forsaken and can be found behind the Zachman framework and its revamping by Caminao.

https://caminao.blog/wp-content/uploads/2019/01/symbotransfo_pagoda.jpg?w=600

MDA reincarnation as the Pagoda Blueprint

Further Reading

External Links

From Processes to Services

Objective

Even in the thick of perplexing debates, enterprise architects often agree on the meaning of processes and services, the former set from a business perspective, the latter from a system one. Considering the rarity of such a consensus, it could be used to rally the different approaches around a common understanding of some of EA’s objectives.

BOB1951003W00007/ICP912
Process with service (Robert Capa)

A Governing Dilemma

Systems have long been of three different species that communicated but didn’t interbred: information ones were calmly processing business records, industrial ones were tensely controlling physical devices, and embedded ones lived their whole life stowed away within devices. Lastly, and contrary to the natural law of evolution, those three species have started to merge into a versatile and powerful new breed keen to colonize the whole of enterprise ecosystem.

When faced with those pervading systems, enterprises usually waver between two policies, containment or integration, the former struggling to weld and confine all systems within technology boundaries, the latter trying to fragment them and share out the pieces between whichever business units ready to take charge.

While each approach may provide acceptable compromises in some contexts, both suffer critical flaws:

  • Centralized solutions constrict business opportunities and innovation by putting all concerns under a single unwieldy lid of technical constraints.
  • Federated solutions rely on integration mechanisms whose increasing size and complexity put the whole of systems integrity and adaptability on the line.

Service oriented architectures may provide a way out of this dilemma by introducing a functional bridge between enterprise governance  and systems architectures.

Separation of Concerns

Since governance is meant to be driven by concerns, one should first consider the respective rationales behind business processes and system functionalities, the former driven by contexts and opportunities, and the latter by functional requirements and platforms implementation.

While business processes usually involve various degrees of collaboration between enterprises, their primary objective is to fulfill each one’s very specific agenda, namely to beat the others and be the first to take advantage of market opportunities. That put systems at the cross of a dual perspective: from a business point of view they are designed to provide a competitive edge, but from an engineering standpoint they aim at standards and open infrastructures. Clearly, there is no reason to assume that those perspectives should coincide, one  being driven by changes in competitive environments, the other by continuity and interoperability of systems platforms. That’s where Service Oriented Architectures should help: by introducing a level of indirection between business processes and system functionalities, services naturally allow for the mapping of requirements with architecture capabilities.

bp2sa_layers
Services provide a level of indirection between business and system concerns.

Along that reasoning (and the corresponding requirements taxonomy), the design of services would be assessed in terms of optimization under constraints: given enterprise organization and objectives (business requirements), the problem is to maximize the business value of supporting systems (functional requirements) within the limits set by implementation platforms (non functional requirements).

Services & Capabilities

Architectures and processes are orthogonal descriptions respectively for enterprise assets and activities. Looking for the footprint of supporting systems, the first step is to consider how business processes should refer to architecture capabilities :

  • From a business perspective, i.e disregarding supporting systems and platforms, processes can be defined in terms of symbolic objects, business logic, and the roles of agents, devices, and systems.
  • The functional perspective looks at the role of supporting systems; as such, it is governed by business objectives and subject to technical constraints.
  • From a technical perspective, i.e disregarding the symbolic contents of interactions between systems and contexts, operational processes are characterized by the nature of interfaces (human, devices, or other systems), locations (centralized or distributed), and synchronization constraints.

Service oriented architectures typify the functional perspective by factoring out the symbolic contents of system functionalities, introducing services as symbolic hinges between enterprise and system architectures. And when defined in terms of customers, messages, contract, policy, and endpoints, services can be directly mapped to architectures capabilities.

Services are a perfect match for capabilities

Moreover, with services defined in terms of architecture capabilities, the divide between business and operational requirements can be drawn explicitly:

  • Actual (external) entities and their symbolic counterpart: services only deal with symbolic objects (messages).
  • Actual entities and their roles: services know nothing about physical agents, only about symbolic customers.
  • Business logic and processes execution: contracts deal with the processing of symbolic flows, policies deal with operational concerns.
  • External events and system time: service transactions are ACID, i.e from customer standpoint, they appear to be timeless.

Those distinctions are used to factor out the common backbone of enterprise and system architectures, and as such they play a pivotal role in their alignment.

Anchoring Business Requirements to Supporting Systems

Business processes are meant to met enterprise objectives given contexts and resources. But if the alignment of enterprise and system architectures is to be shielded from changes in business opportunities and platforms implementation, system functionalities will have to support a wide range of shifting business goals while securing the continuity and consistency of shared resources and communication mechanisms. In order to conciliate business changes with system continuity, business processes must be anchored to objects and activities whose identity and semantics are set at enterprise level independently of the part played by supporting systems:

  • Persistent units (aka business objects): structured information uniquely associated to identified individuals in business context. Life cycle and integrity of symbolic representations must be managed independently of business processes execution.
  • Functional and execution units: structured activity triggered by an event identified in business context, and whose execution is bound to a set of business objects. State of symbolic representations must be managed in isolation for the duration of process execution.
Services can be defined according persistency and functional units (#)

The coupling between business units (persistent or transient) identified at business level and their system counterpart can be secured through services defined with regard to business processes (customers), business objects (messages), business logic (contract), and business operations (policy).

It must be noted that while services specifications for customers, messages, contracts, and policy are identified at business level and completed at functional level, that’s not the case for endpoints since services locations are set at architecture level independently of business requirements.

Filling out Functional Requirements

Functional requirements are set in two dimensions, symbolic and operational; the former deals with the contents exchanged between business processes and supporting systems with regard to objects, activities and events, or actors; the latter deals with the actual circumstances of the exchanges: locations, interfaces, execution constraints, etc.

Given that services are by nature shared and symbolic, they can only be defined between systems. As a corollary, when functionalities are slated as services, a clear distinction should be maintained between the symbolic contents exchanged between business processes and supporting systems, and the operational circumstances of actual interactions with actors.

Interactions: symbolic and local (a), non symbolic and local (b), symbolic and shared (c).
Interactions: symbolic and local (a), non symbolic and local (b), symbolic and shared (c).

Depending on the preferred approach for requirements capture, symbolic contents can be specified at system boundaries (e.g use cases), or at business level (e.g users’ stories). Regardless, both approaches can be used to flesh out the symbolic descriptions of functional and persistency units.

From a business process standpoint, users (actors in UML parlance) should not be seen as agents but as the roles agents play in enterprise organization, possibly with constraints regarding the quality of service at entry points. That distinction between agents and roles is critical if functional architectures are to dissociate changes in business processes on one hand, platform implementation on the other hand.

Along that understanding actors triggering use cases (aka primary actors) can represent the performance of human agents as well as devices or systems. Yet, as far as symbolic flows are concerned, only human agents and systems are relevant (devices have no symbolic capabilities of their own). On the receiving end of use cases (aka secondary actors), only systems are to be considered for supporting services.

Mapping Processes to Services (through Use Cases)

Hence, when requirements are expressed through use cases, and assuming they are to be realized (fully or partially) through services:

  • Persistency and functional units identified by business process would be mapped to messages and contracts.
  • Business processes would fit service policy.
  • Use case containers (aka systems) would be registered as service customers.

Alternatively, when requirements are set from users’ stories instead of use cases, persistency and functional units have to be elicited through stories, traced back to business processes, and consolidated into features. Those features will be mapped into system functionalities possibly, but not necessarily, implemented as services.

Mapping Processes to Services (through Users’ Stories)

Hence, while the mapping of business objects and logic respectively to messages and contracts will be similar with use cases and users’ stories, paths will differ for customers and policies:

  • Given that use cases deal explicitly with interactions at system boundaries, they represent a primary source of requirements for services’ customers and policy. Yet, as services are not supposed to be directly affected by interactions at systems boundaries, those elements would have to be consolidated across use cases.
  • Users’ stories for their part are told from a business process perspective that may take into account boundaries and actors but are not focused on them. Depending on the standpoint, it should be possible to define customers and policies requirements for services independently of the contingencies of local interactions.

In both cases, it would be necessary to factor out the non symbolic (aka non functional) part of requirements.

Non Functional Requirements: Quality of Service and System Boundaries

Non functional requirements are meant to set apart the constraints on systems’ resources and performances that could be dealt with independently of business contents. While some may target specific business applications, and others encompass a broader range, the aim is to separate business from architecture concerns and allocate the responsibilities (specification, development, and acceptance) accordingly.

Assuming an architecture of services aligned on capabilities, the first step would be to sort operational constraints:

  • Customers: constraints on usability, customization, response time, availability, …
  • Messages: constraints on scale, confidentiality, compliance with regulations, …
  • Contracts: constraints on scale, confidentiality, …
  • Policy: availability, reliability, maintenance, …
  • Endpoints: costs, maintenance, security, interoperability, …
BP2SOA_QoS
Non functional constraints may cut across services and capabilities

Since constraints may cut across services and capabilities, non functional requirements are not a given but the result of explicit decisions about:

  • Architecture level: should the constraint be dealt with locally (interfaces), at functional level (services), or at technical level (resources).
  • Services: when set at functional level, should the constraint be dealt with by business services (e.g domain or activity), or architecture ones (e.g authorization or orchestration).

The alignment of services with architecture capabilities will greatly enhance the traceability and rationality of those decisions.

A Simple Example

This example is based on the Purchase Order case published with the OMG specifications: http://www.omg.org/spec/SoaML/1.0/Beta2/PDF/

A simple purchase order process analyzed in terms of service customers, messages and entities (#), contracts, and policy (aka choreography)
A simple purchase order process analyzed in terms of service customers, messages and entities (#), contracts, and policy (aka choreography)

Further Reading

External References

Modeling Languages: Differences Matter

“Since words are only names for things, it would be more convenient for all men to carry about them such things as were necessary to express a particular business they are to discourse on.”

Jonathan Swift, Gulliver’s Travels

Objective

Modeling languages are meant to support the description of contexts and concerns from specific standpoints. And because those different perspectives have to be mapped against shared references, language must also provide constructs for ironing out variants and factoring out constants.

Digging or Ironing out differences (Erwitt Elliott)
Ironing out differences in features and behaviors (Erwitt Elliott)

Yet, while most languages generally agree on basic definitions of objects and behaviors, many distinctions are ignored or subject to controversial understanding; such shortcomings might be critical when architecture capabilities are concerned:

  • Actual entities and their symbolic counterpart.
  • Actual entities and their roles.
  • Business logic and business operations
  • External events and system time.

Capabs_L1
Architecture Capabilities

As those distinctions set the backbone of functional architectures, languages should be assessed according their ability to express them unambiguously using the least possible set of constructs.

Business objects vs Symbolic Surrogates

As far as symbolic systems are concerned, the primary purpose of models is to distinguish between targets and representations. Hence the first assessment yardstick: modeling languages must support a clear and unambiguous distinction between objects and behaviors of concern on one hand, symbolic system surrogates on the other hand.

cc
A primer on representation: objects of concerns and surrogates

Yet, if objects and behaviors are to be consistently and continuously managed, modeling languages must also provide common constructs mapping identities and structures of actual entities to their symbolic counterpart.

Agents vs Roles

Given that systems are built to support business processes, modeling languages should enable a clear distinction between physical entities able to interact with systems on one hand, roles as defined by enterprise organization on the other hand.

ccc
Agents and Roles

In that case the mapping of actual entities to systems representations is not about identities but functionalities: a level of indirection has to be introduced between enterprise organization and system technology because the same roles can be played,simultaneously or successively, by people, devices, or other systems.

Business logic vs Business operations

Just like actual objects are not to be confused with their symbolic description, modeling languages must make a clear distinction between business logic and processes execution, the former defining how to process symbolic objects and flows, the latter with the coupling between process execution and changes in actual contexts. That distinction is of a particular importance if business and organizational decisions are to be made independently of supporting systems technology.

Pull vs Push Rule Management
Business logic and operational contingencies

Language constructs must also support the consolidation of functional and operational units, the former being defined by integrity constraints on symbolic flows and roles authorizations on objects and operations, the latter taking into account synchronization constraints between the state of actual contexts and the state of their system symbolic counterpart. And for that purpose languages must support the distinction between external and internal events.

External vs Internal Events

Paraphrasing Albert Einstein, time is what happens between events. As a corollary, external time is what happens between context events, and internal time is what happens between system ones. While both can coincide for single systems and locations, no such assumption should be made for distributed systems set in different locations. In that case modeling language should support a clear distinction between external events signalling changes set in actual locations, and internal events signalling changes affecting system surrogates.

Time scales can be design on purpose
Time scales are set by events and concerns

Along that perspective synchronization is to be achieved through the consolidation of time scales. For single locations that can be done using system clocks, across distributed locations the consolidation will entail dedicated time frames and mechanisms set in reference to some initial external event.

Conclusion: How to share differences across perspectives

Somewhat paradoxically, multiple modeling languages erase differences by paring down shared descriptions to some uniform lump that can be understood by all. Conversely, agreeing on a set of distinctions that should be supported by every language could provide an antidote to the Babel syndrome.

That approach can be especially effective for the alignment of enterprise and systems architectures as the four distinctions listed above are equally meaningful in both perspectives.

Further reading

Knowledge Based Model Transformation

Objective

Even when code is directly developed from requirements, software engineering can be seen as a process of transformation from a source model (e.g requirements) to a target one (e.g program). More generally, there will be intermediate artifacts with development combining automated operations with tasks involving some decision-making. Given the importance of knowledge management in decision-making, it should also be considered as a primary factor for model transformation.
ccccc
What has been transformed, added, abstracted ? (Velazquez-Picasso)

Clearing Taxonomy Thickets

Beside purpose, models transformation is often considered with regard to automation or abstraction level. Classifying transformations with regard to automation is at best redundant, inconsistent and confusing otherwise: on one side of the argument, assuming a “manual transformation” entails some “intelligent design”, it ensues that it cannot be automated; but, on the other side of the argument, if manual operations can be automated, the distinction between manual and automated is pointless. And in any case a critical aspect has been ignored, namely what is the added value of a transformation. Classifying transformations with regard to abstraction levels is also problematic because, as famously illustrated above, there are too many understandings of what those levels may be. Considering for instance analysis and design models; they are usually meant to deal respectively with system functionalities and implementation. But it doesn’t ensue that the former is more abstract than the latter because system functionalities may describe low-level physical devices and system designs may include high level abstract constructs.

A Taxonomy of Purposes

Depending on purpose, model transformation can be set in three main categories:
  • Translation: source and target models describe the same contents with different languages.
  • Rephrasing: improvement of the initial descriptions using the same language.
  • Processing: source and target models describe successive steps along the development process. While they may be expressed with different languages, the objective is to transform model contents.
Basicam2_Transfos
Translation, Rephrasing, Processing.
Should those different purposes be achieved using common mechanisms, or should they be supported by specific ones ?

A Taxonomy of Knowledge

As already noted, automated transformation is taken as a working assumption and the whole process is meant to be governed by rules. And if purpose is used as primary determinant, those rules should be classified with regard of the knowledge to be considered:
  • Syntactic knowledge would be needed to rephrase words and constructs without any change in content or language.
  • Thesaurus and semantics would be employed to translate contents into another language.
  • Stereotypes, Patterns, and engineering practices would be used to process source models into target ones.
Basicam2_TransfosKnow
Knowledge with regard to transformation purposes
On that basis, the next step is to consider the functional architecture of transformation, in particular with regard to supporting knowledge.

Procedural vs Declarative KM

Assuming transformation processes devoid of any decision-making, all relevant knowledge can be documented either directly in rules (procedural approach) or indirectly in models (declarative approach). To begin with, all approaches have to manage knowledge about languages principles (ML) and the modeling languages used for source (MLsrc) and target (MLtrg) models. Depending on language, linguistic knowledge can combine syntactic and semantic layers, or distinguish between them.
uml_metas
Meta-models can be structured along linguistic layers or combine syntax and semantics.
Given exponential growth of complexity, procedural approaches are better suited for the processing of unstructured knowledge, while declarative ones are the option of choice when knowledge is organized along layers. When applied to model transformation, procedural solutions use tables (MLT) to document the mappings between language constructs,  and programs to define and combine transformation rules. Such approaches work well enough for detailed rules targeting specific domains, but fall short when some kind of generalization is needed; moreover, in the absence of distinction at language level (see UML and users’ concerns),  any contents differentiation in source models (Msrc) will be blurred in target ones (Mtrg) .
Narratives_PvsD
Transformation Policies: Procedural vs Declarative
And filtering out noise appears to be the main challenge of model processing, especially when even localized taints or ambiguities in source models may contaminate the whole of target ones; hence the benefit of setting apart layers of source models according their nature and reliability. That can be achieved with the modularity of declarative solutions, with transformations carried out separately according the nature of knowledge: syntactic, semantic, or engineering. While declarative solutions also rely on rules, those rules can be managed according to:
  • Purpose: rephrasing, translation, or development.
  • Knowledge level: rules about facts, categories, or reasoning.
  • Confidence level: formal, heuristic, fuzzy, modal.
That makes declarative solutions more easily assessed and therefore improved.

Assessment

Advances in model transformation call for sound assessment, and that can be done with regard to usual knowledge management capabilities:
  • Primitive operations: how to create, read, update, or delete (CRUD) transformations.
  • Transparency: how to reason about transformations.
  • Traceability: how to record the history of performed transformations and chart the effects of hypothetical ones.
  • Reliability: built-in consistency checks, testability.
  • Robustness: how to deal with incomplete, noisy, or inconsistent models.
  • Modularity, reusability: how to customize, combine, or generalize transformations.
In principle declarative approaches are generally seen as superior to procedural ones due to the benefits of a clear-cut separation between the different domains of knowledge on one hand, and the programs performing the transformations on the other hand:
  • The complexity of transformations increases exponentially with the number of rules, independently of the corpus of knowledge.
  • The ensuing spaghetti syndrome rapidly downgrades transparency, traceability, and reliability of rules which, in procedural approaches, are the only gate to knowledge itself.
  • Adding specific rules in order to deal with incomplete or inconsistent models significantly degrades modularity and reusability, with the leveraging impact of new rules having to be added for every variant.
In practice the flaws of procedural approaches can be partially curbed providing that:
  • Rules apply to a closely controlled domain.
  • Models are built with complete, unambiguous and consistent languages.
Both conditions can be met with domain specific languages (DSLs) and document based ones (e.g XML) targeting design and program models within well-defined business domains. Compared with the diversity and specificity of procedural solutions, the extent of declarative ones have been checked by their more theoretically demanding requirements, principally met by relational models. Yet, the Model Driven Architecture (MDA) distinction between computation independent (CIMs), platform independent (PIMs), and platform specific (PSMs) models could provide the basis for a generalization of knowledge-based model transformation.

Further Readings

Kaleidoscope Series

Other Caminao References

External references

Modernization & The Archaeology of Software

The past is not dead. In fact, it’s not even past. –
William Faulkner

Objective

Retrieving legacy code has something to do with archaeology as both try to retrieve undocumented artifacts and understand their initial context and purpose. The fact that legacy code is still well alive and kicking may help to chart their structures and behaviors, but it may also confuse the rationale of initial designs.

ccc
Legacy Artifact: Was the bowl intended for turkeys ? at thanksgiving ? Why the worm ?

Hence the importance of traceability and the benefits of a knowledge based approach to modernization organized along architecture layers (enterprise, systems, platforms), and processes (business, engineering, supporting services).

Model Driven Modernization

Assuming that legacy artifacts under consideration are still operational (otherwise re-engineering would be pointless), modernization will have to:

  • Pinpoint the deployed components under consideration (a).
  • Identify the application context of their execution (b).
  • Chart their footprint in business processes (c).
  • Define the operational objectives of their modernization (d).
  • Sketch the conditions of their (re)engineering (e) and the possible integration in the existing functional architecture (f).
  • Plan the re-engineering project (g).

RefactorModern_Roadmap
Modernization Road Map

Those objectives will usually not be achieved in a big bang, wholly and instantly, but progressively by combining increments from all perspectives. Since the different outcomes will have to be managed across organizational units along multiple engineering processes, modernization would clearly benefit from a model based approach, as illustrated by MDA modeling layers:

  • Platform specific models (PSMs) should be used for collecting legacy artifacts and mapping them to their re-engineered counterparts.
  • Since platform independent models (PIMs) are meant to describe system functionalities independently of implementations,  they should be used to consolidate the functionalities of legacy and re-engineered artifacts.
  • Since computation independent models (CIMs) are meant to describe business processes independently of supporting systems, they should be used to reinstate, document, and validate re-engineered artifacts within their business context.

RefactorModern_Layers
Model Driven Modernization

Corresponding phases can be expressed using the archaeology metaphor: field survey and collection (>PSMs), analysis (PSMs/PIMs), and reconstruction (CIMs/PIMs).

Field Survey

The objective of a field survey is to circumscribe the footprint of the modernization and collect artifacts under consideration:

  • Given targeted business objects or activities, the first step is to collect information about locations, distribution and execution dependencies.
  • Sites can then be searched and executable files translated into source ones whose structure and dependencies can be documented.
  • The role of legacy software can then be defined with regard to the application landscape .

RefactorModern_Field
Analysis (with regard to presentation, control, persistency, and services)

It must be noted that field survey and collection deal with the identification and restoration of legacy objects without analyzing their contents.

Analysis

The aim of analysis is to characterize legacy components, first with regard to their architectural features, then with regard to functionalities. Basic architectural features take into account components’ sharing and life-cycle.

The analysis of functionalities can be achieved locally or at architecture level:

  • Local analysis (a) directly map re-factored applications to specific business requirements, by-passing functional architecture. That’s the case when targeted applications can be isolated, e.g by wrapping legacy code.
  • Global analysis (b) consolidate newly supported applications with existing ones within functional architecture, possibly with new functionalities.

RefactorModern_Analysis
Analysis (with regard to presentation, control, persistency, and services)

It must be noted that the analysis of legacy components, even when carried out at functional architecture level, takes business processes as they are.

Reconstruction

The aim of reconstruction is to set legacy refactoring within the context of enterprise architecture. That should be done from operational and business perspectives:

  • As the primary rationale of modernization is to deal with operational  problems or bottlenecks, its benefits should be fully capitalized at enterprise level.
  • Re-factored applications usually make room for improvements of users’ experience; that may bring about further changes in organization and business processes.

RefactorModern_Reconstruct
Reconstruction

Hence, modernization is not complete until potential benefits of re-factored applications are considered, for business processes as well as for functional architecture.

From Workshops to Workflow

As noted above, modernization can seldom be achieved in a big bang and should be planned as a model based engineering process. Taking a leaf from the MDA book,  such a process would be organized across four workshops:

  • Technical architecture (deployment models): that’s where legacy components are collected, sorted, and documented.
  • Software architecture (platform specific models): where legacy components are put in local context.
  • Functional architecture (platform independent models): where legacy components are put in shared context.
  • Enterprise architecture (computation independent models): where legacy components are put into organizational context.

RefactorModern_Workshops
Modernization & MBSE Workshops

Those workshops would be used to manage the outcomes of the modernization workflow:

  1. Collect and organize legacy code; translate into source files.
  2. Document legacy components.
  3. Build PSMs according basic architecture functional patterns.
  4. Map to PIMs of system functional architecture.
  5. Consolidate enterprise architecture.

RefactorModern_Engineer
Modernization Workflow

With the relevant workflows defined in terms of model-based systems engineering, modernization can be integrated with enterprise architecture.

Further Reading

External Links

Enterprise Governance & Knowledge

Knowledgeable Processes

While turf wars may play a part, the debate about Enterprise and Systems governance is rooted in a more serious argument, namely, how the divide between enterprise and systems architectures may affect decision-making.

antin-art-2007-judgment-of-paris.jpg
Informed Decision_making (Eleanor Antin)

The answer to that question can be boiled down to four guidelines respectively for capabilities, functionalities, visibility, and uncertainty.

Architecture Capabilities

From an architecture perspective, enterprises are made of human agents, devices, and symbolic (aka information) systems. From a business perspective, processes combine three kinds of tasks:

  • Authority: deciding how to perform processes and make commitments in the name of the enterprise. That can only be done by human agents, individually or collectively.
  • Execution: processing physical or symbolic flows between the enterprise and its context. Any of those can be done by human agents, individually or collectively, or devices and software systems subject to compatibility qualifications.
  • Control: recording and checking the actual effects of processes execution. Any of those can be done by human agents, individually or collectively, some by software systems subject to qualifications, and none by devices.

Hence, and whatever the solutions, the divide between enterprise and systems will have to be aligned on those constraints:

  • Platforms and technology affects operational concerns, i.e physical accesses to systems and the where and when of processes execution.
  • Enterprise organization determines the way business is conducted: who is authorized to what (business objects), and how (business logic).
  • System functionalities sets the part played by systems in support of business processes.

Capabs_L1
Enterprise Architecture Capabilities

That gives the first guideline of systems governance:

Guideline #1 (capabilities): Objectives and roles must be set at enterprise level, technical constraints about deployment and access must be defined at platform level, and functional architecture must be designed as to get the maximum of the former subject to the  latter’s constraints.

Informed Decisions: The Will to Know

At its core, enterprise governance is about decision-making and on that basis the purpose of systems is to feed processes with the relevant information so that agents can be put it to use as knowledge.

Those flows can be neatly described by crossing the origin of data (enterprise, systems, platforms) with the processes using the information (business, software engineering, services management):

  • Information processing begins with data, which is no more than registered facts: texts, numbers, sounds, visuals, etc. Those facts are collected by systems through the execution of business, engineering, and servicing processes; they reflect the state of business contexts, enterprise, and platforms.
  • Data becomes information when comprehensively and consistently anchored to identified constituents (objects, activities, events,…) of contexts, organization, and resources.
  • Information becomes knowledge when put to use by agents with regard to their purpose: business, engineering, services.

ccc
Information processing: from data to knowledge and back

Along that perspective, capabilities can be further refined with regard to decision-making.

  • Starting with business logic one should factor out decision points and associated information. That will determine the structure of symbolic representations and functional units.
  • Then, one may derive decision-making roles, together with implicit authorizations and access constraints. That will determine the structure of I/O flows and the logic of interactions.
  • Finally, the functional architecture will have to take into account synchronization and deployment constraints on events notification to and from processes.

Who should know What and When
Who should know What, Where, and When

That can be condensed into the second guideline of system governance:

Guidelines #2 (functionalities): With regard to enterprise governance, the role of systems is to collect data and process it into information organized along enterprise concerns and objectives, enabling decision makers to select and pull relevant information and translate it into knowledge.

Qualified Information: The Veils of Ignorance

Ideally, decision-making should be neatly organized with regard to contexts and concerns:

  • Contexts are set by architecture layers: enterprise organization, system functionalities, platforms technology.
  • Concerns are best identified through processes: business, engineering, or supporting services.

Qualified Information Flows across Architectures and Processes
Qualified Information Flows across Architectures and Processes

Actually, decisions scopes overlap and their outcomes are interwoven.

While distinctions with regard to contexts are supposedly built-in at the source (enterprise, systems, platforms), that’s not the case for concerns whose distinction usually calls for reasoned choices supported by different layers of governance:

  • Assets: shared decisions whose outcome bears upon several business domains and cycles. Those decisions may affect all architecture layers: enterprise (organization), systems (services), or platforms (purchased software packages).
  • Users’ Value: streamlined decisions governed by well identified business units providing for straight dependencies from enterprise (business requirements), to systems (functional requirements) and platforms (users’ entry points).
  • Non functional: shared decisions about scale and performances affecting users’ experience (organization),  engineering (technical requirements), or resources (operational requirements).

Separation of Concerns and Requirements Taxonomy
Qualified Information and Decision Making

As epitomized by non functional requirements, those layers of governance don’t necessarily coincide with the distinction between business, engineering, and servicing concerns. Yet, one should expect the nature of decisions be set prior the actual decision-making, and decision makers be presented with only the relevant information; for instance:

  • Functional requirements should be decided given business requirements and services architecture.
  • Scalability (operational requirements) should be decided with regard to enterprise’s objectives and organization.

Hence the third guideline of system governance:

Guideline #3 (visibility): Systems must feed processes with qualified information according to contexts (business, organization, platforms) and governance level (assets, user’s value, operations) of decision makers.

Risks & Opportunities: Mining Beyond Visibility

Long secure behind organizational and technical fences, enterprises must now navigate through open digitized business environments and markets. For business processes it means a seamless integration with supporting applications; for corporate governance it means keeping track of risks and opportunities in changing business contexts while assessing the capability of organizations and systems to cope, adjust, and improve.

On one hand risks and opportunities take root beyond the horizon and are not supposed to square with established information models; but on the other hand deep learning technologies is revolutionizing data analytics. purpose ontologies could be used to bring architectures and environments modeling into a common paradigm.

Hence the fourth guideline of system governance:

Guideline #4 (uncertainty): assuming that business edge is built on unqualified information about risks or opportunities, explicit and implicit knowledge should be processed within shared conceptual frames; that can be achieved with ontologies.

Further Reading