Archive for the ‘Frameworks’ Category

Focus: MDA & UML

November 9, 2016


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


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

Caminao & EACOE

September 19, 2016


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:


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.


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:


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.

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.


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.

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

Models as Parachutes

August 31, 2016


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

Conceptual Models & Abstraction Scales

March 22, 2016

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.


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 StaffSupplier 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 a System Modeling Ontology

Along an analytic perspective, ontologies are meant to determine the categories that can comprehensively and consistently denote the instances of a domain under consideration. With regard to the modeling of automation systems, a relevant ontology would map a subset of semantic categories (for conceptual representations) to functional ones (for systems symbolic representations).

Further Reading

External Links

Enterprise Systems & the OS Kernel Paradigm

September 1, 2015


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.

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.

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), interfaces (systems), and devices (platforms).
  • When: business events (enterprise), logical events (systems), and transaction managers (platforms).
  • Where: sites (enterprise), logical processing units (systems), network architecture (platforms).
  • How: business processes (enterprise), applications (systems), and CPU (systems).
Traceability of Capabilities across architecture layers

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.


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

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

How to choose Frameworks & Methods

November 16, 2014


Before assessing criteria for long-term commitments, initial selection of a method or framework for systems engineering should consider four basic principles: continuity, duality, parsimony, and artifacts precedence.

A Framed Perspective

Picking a Framework (Spring Garden, Tehran)


Modus operandi are built on people understandings, practices, and skills that cannot be changed as easily as tools. In other words “big bang” solutions should be avoided when considering changes in systems governance and software engineering processes.


While any solution will necessarily entail collaboration between business and systems analysts, they belong to realms with inbuilt differences of concerns and culture. Assuming that the divide can be sewed up by canny procedures is tantamount to ignore the very purpose of the framework.


According to Occam’s Razor, when faced with competing options, the one with the fewest assumptions should be selected. That principle is especially critical when dealing with organizational options that cannot be easily reversed or even adjusted. Hence, when alternative engineering processes are considered, a simple and robust solution should be selected as a default option, and extensions added for specific projects if and when needed.

Artifacts Precedence

Assuming that enterprise architecture entails the continuity, perennity and reuse of shared descriptions and understandings, symbolic artifacts can be seen as the corner-stone of the whole undertaking. As a corollary, and whatever the framework or methodology, the core of managed artifacts should be clearly defined before considering the processus that will use them.

Further Reading