Thread: Model Based Systems Engineering

Synopsis

Whatever the assorted labels (based/driven, system/software, development/engineering), the basic tenet of model based system engineering (MBSE) is to replace procedural approaches by declarative ones, and to define engineering processes in terms of artifacts transformation.

OMG’s Model Driven Architecture (MDA) is a special case of MBSE set along representative  models for computation independent (CIM), platform independent (PIM), and platform specific (PSM) models.

Considering the wide range of actual and possible realizations, the MBSE paradigm is best discussed independently of the different labels used by its promoters.

From Documents to Programs

To begin with the broader picture, models are a special case of documents in which texts are replaced by symbolic artifacts, and as for any document, they should be set with regard to purpose and content.

With regard to purpose, three main categories are to be considered:

• Governance & Regulations.
• Collaboration between organizational (business or engineering) units.
• Use or reuse of artifacts.

With regard to model contents, two criteria are of primary importance:

• Whether the targets are actual (business context and organization) or symbolic (information systems).
• Whether the targets are objects (business entities or system surrogates) or activities (business processes or logic).

That all-inclusive view allows for the continuity of MBSE artifacts, from textual documents to programs (seen as executable models). More importantly, it provides an unifying understanding of enterprise (business objects and processes) and systems (symbolic surrogates) descriptions.

Enterprise: Models, Architectures, Perspectives

From the enterprise point of view, a primary benefit of MBSE is to position problems and solutions in relation with contexts and architectures:

• Enterprise: models can be used to define business objectives and resources on one hand (problems), organization and processes on the other hand (solutions).
• Systems: given business processes (problems), models can be used to describe systems functionalities (solutions).
• Platforms: given systems functionalities (problems), models can be used to specify platforms and designs (solutions).

That should help to clarify the respective responsibilities of enterprise and systems architects and analysts.

Along that understanding, and beyond lexical controversies, it ensues that two basic scales are to be aligned:

• Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
• Models: conceptual (business context and organization), analysis (symbolic representations), design (physical implementation).

A Brief Reminder of Models Logic

From a formal point of view, models can be set in two basic categories:

• Descriptive (aka extensional) ones try to put actual objects, events, and processes into categories defined with regard to enterprise business objectives and organization.
• Prescriptive (aka intensional) ones define what is expected of systems components at functional (PIMs) and technical level (PSMs).

When combined with completeness that classification produces four categories:

• Extensional and partial: the model describes selected features of actual occurrences (e.g organization chart or IT service management)
• Intensional and partial: the model describes selected features of types (e.g functional architecture or business strategy)
• Extensional and complete: the model describes all features of actual occurrences (e.g business process or system configuration).
• Intensional and complete: the model describes all features of types (e.g business rules or SW design)

Since analysis models describe specific business domains they are usually partial and extensional. On the contrary,  as design models are used to generate software components, they are to be intensional and complete.

Engineering: Lean, Just-in-time, Value driven

From an engineering point of view, MBSE replaces a top-down definition of processes by a bottom-up one which defines tasks directly from development flows. That is the necessary condition for automated operations and the rationalization of engineering processes.

Along that perspective, engineering processes can be designed according the needs, from single leaps between initial documents to deliverables, to phased moves between multiple stepping stones, each associated to a specific category of models. With models seen as symbolic inventories, MBSE will foster lean processes by adjusting steps, artifacts, shelf life and deliveries to business and operational needs.

Moreover, the benefits of traceability and transparency of engineering processes can be extended to decision-making across the whole of enterprise architectures:

• Self contained projects can be directly associated to organizational units taking responsibility for users’ value and costs at enterprise (business process) or system (applications) level.
• Projects dealing with assets shared between business processes (enterprise level) or applications (system level) are to be managed in portfolios and their business value and costs assessed across organizational units and business time-spans.

By bringing together business, organizational, and technical decision-making, MBSE emerges as a practical tool of enterprise governance.

Governance: Models in Driving Seats

As epitomized by MDA, MBSE can be usefully applied to the planning and management of portfolios and projects :

• Computation Independent Models (CIMs) can be used to describe business objects, roles and processes independently of supporting systems. Portfolios can then be managed with regard to business objectives and enterprise assets.
• Platform Independent Models (PIMs) can be used to define the functional architecture of supporting systems independently of technologies. Projects can then be identified and planned depending on users’ requirements and architecture functional capabilities.
• Platform Specific Models (PSMs) can be used to design applications and software components as implemented by specific technologies. Projects can then be developed and deployed with regard to users’ schedules and platforms technical capabilities.

Given a differentiated and fine-grained description of artifacts at enterprise level, the next step for MBSE would be to facilitate the collaboration between organizational units.

Collaboration: MBSE & EA

MBSE can bring under a common roof procedural (e.g TOGAF) and declarative (e.g Zachman) approaches to enterprise architecture. For that purpose architecture layers (declarative view) are to be crossed with archetypal tasks (requirements, analysis, design) redefined as enterprise processes (procedural view):

1. Requirements: processes deal with organizational and business objectives. They start with portfolio management; are carried on with systems functionalities; and complete with platforms operational requirements.
2. Problems Analysis: processes deal with symbolic representations of enterprise environment, objectives, and activities. They start with the consolidation of symbolic representations for objects (power-types) and activities (scenarii); are carried on with functional architectures; and complete with platforms non-functional features. Contrary to requirements processes which are meant to convey changes and manage frictions  (dashed lines) between actual architecture layers, the aim of solutions analysis processes is to consolidate symbolic representations and guarantee their consistency and continuity. As a corollary, analysis at system level must be aligned (continuous lines) with its enterprise counterpart before functional requirements are taken into account.
3. Solutions Design: processes deal with operational concerns and resources deployment. They starts with locations and resources; are carried on with systems configurations; and complete with platforms deployments. 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.

Once engineering is driven by architectures, enterprise processes can be outlined according business and engineering contexts and objectives. While that could come with various terminologies, the guiding principles and resulting profiles should not be very different, e.g:

• Agile processes will combine requirements with development, bypassing 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).

By reinstating architecture as a primary factor of systems governance MBSE clarifies the relationships between architecture layers and enterprise processes.

Models Transformations

From an engineering point of view, one of the main benefits of MBSE is to support automated and differentiated transformations of models:

• Technical: how to generate code from models, possibly targeting different platforms (a).
• Development: how to generate views (on shared data models) or modules (e.g for standards) to be (re)used by different projects (b).
• Enterprise: how to generate models (e.g canonical data models) supporting the consolidation of different business objects and activities within the same functional architecture (c).

Yet, it must be noted that if such a reasoned catalog may help to guide MBSE implementation, it usually remains implicit and most of concrete realizations just follow the traditional data/application divide:

• Data models transformations are based on relational theory and implementations are often fully supported by data base management systems (DBMS) or tools providers.
• Domain specific approaches integrate development processes for applications targeting the same business domain, using specific languages built on purpose with meta-languages.

Whereas data models transformation has a well established track record, domain specific transformations are by nature more fragmented and proprietary despite standards like the OMG’s Meta Object Facility (MOF). But both rely on embedded knowledge, the former formal and generic, the latter pragmatic and specific.

Knowledge Based Models Transformations

Knowledge being a critical success factor for models transformation, it should be managed with regard to contexts and objectives.

Based on standard transformations (code generation, reverse engineering, migration, refactoring, optimization, normalization), three basic operations can be identified:

• 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 different steps may be associated with different languages, the primary objective is to transform model contents.

Not surprisingly, each operation primarily relies on a specific category of knowledge:

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

Contrary to syntactic knowledge (whose clear rules can be efficiently managed by parsers), business and engineering knowledge scale poorly with rules engines due to exponential complexity, blurred semantics, and limited transparency and traceability. Hence the benefit of a declarative approach that could move knowledge from rules to models, enhancing reuse and change management.

KM & Reuse: Domain Specific Contents

Reuse and transformation can be seen as the dual hands of MBSE: on one hand modeling assets are meant to be shared and reused, on the other hand transformation is pointless if not applied to modeling assets. That duality appears clearly when models and transformations are set along MDA layers:

• Platform independent models reuse computation independent ones for the definition of business objects and activities set by enterprise objectives and organization (a).
• Platform specific models reuse platform independent ones for the functional specifications of the components to be designed (b).
• Platform specific models reuse computation independent ones for the business rules that can be managed independently of functional architectures (c).
• Deployment models reuse platform specific and computation independent ones respectively for technical and operational constraints (d).

As far as the transformation of large and changing semantic contents is concerned, models are the assets of choice for reuse and knowledge management. So, while some parts will have to be kept textual or coded in rules, most is to be best managed through models.

But there may be caveats with crossed concerns: since there is no reason to assume that knowledge contents will neatly match architecture layers, reusable artifacts may have to be organized with regard to conflicting criteria, e.g business objectives and technical contingencies. Introduced as a level of indirection, functional models could be used to reduce frictions and manage adjustments between solutions architectures.

Taking an extended version (3+services) of the well known three-tiers architecture paradigm for example, engineering concerns will map artifact along:

• User interface tier (boundary symbol) deals with transient and local (non shared) functionalities. It follows the Model/View/Controller patterns whose components can be neatly matched to the three architecture tiers.
• Functional tier (control symbol) deals with transient and shared functionalities.
• Persistent tier (entity symbol) deals with persistent and shared functionalities.
• Service tier (interface symbol), a subset of the functional tier, deals with instant and shared functionalities.

These engineering-based tiers can be crossed with requirements taxonomy (business, functional, and non functional) and footprint (enterprise or domain specific). For instance:

• Enterprise wide knowledge (green) may deal with presentation standards (boundaries tier), authentication and authorization (control tier), or encryption (entities tier).
• Knowledge specific to business or application domains (brown) may deal with views (boundaries tier), business logic (control tier), or business objects (entities tier).

With business, functional, and non functional knowledge comprehensively and consistently garnered in models, engineering can be fully described in terms of transformations. But that’s still not the whole knowledge as one must also consider the engineering knowledge governing the transformations.

KM & Reuse: Engineering

Engineering knowledge is widely spread across development process, and its reuse may take different forms, e.g:

• Parameters: how to translate operational constraints into deployment models (e.g rules-based heuristics).
• Business rules: how to translate users defined rules into executable ones (e.g syntactic transformation).
• Services and polymorphism: how to support consolidated functions independently of the context of their execution.
• Inheritance : how to combine general and specific knowledge.
• Design patterns: how to combine functional (PIMs) and technical (PSMs) architectures.
• Functional patterns: how to consolidate business and functional requirements into functional architecture (PIMs).

Whereas rules-based transformation is often the best option for syntactic and targeted heuristic knowledge, analysis and design patterns are different because their use involves decision-making. Due to the need of greater transparency and traceability, the corresponding engineering knowledge is to be better managed as models in engineering profiles and reused through composition or inheritance.

The objective would be to spread the benefits GoF’s design patterns to the whole of the modeling process through a transparent mapping of functional and design patterns. That could be achieved by inducing a functional catalog from its design equivalent.

Agile Architectures

The benefits of model based systems engineering are best summed up in terms of enterprise agility, namely a mix of versatility and plasticity:

• Versatility: enterprise ability to perform different activities in changing environments without having to change its architectures.
• Plasticity: enterprise ability to change its architectures without affecting its performances.

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

Looking for versatility, changes in business environments as expressed by users’ requirements must be rapidly taken into account by applications. Looking for plasticity, changes in business objectives as translated into business processes are meant to be supported by enterprise capabilities. 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 to provide the expected quality of service. That is what requirements traceability is meant to achieve.
• At system level the objective is to ensure that business functions and features can be directly mapped to systems functionalities. That is what services oriented architectures (SOA) are  meant to achieve.
• At enterprise level the objective is to ensure that the enterprise capabilities are congruent with its business objectives, i.e that they support its business processes through an effective use of assets. That is what maturity and capability models are meant to achieve.

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

Further Readings

• Architectures
• Models, Architectures, Perspectives (MAPs)
• Abstractions Based Systems Engineering
• Architecture Capabilities
• Capabilities vs Processes
• Enterprise Governance & Knowledge
• Enterprise Architectures & Separation of Concerns
• From Processes to Services
• EA & MDA
• EA Documentation: Taking Words for Systems
• Abstractions & Emerging Architectures
• Alignment for Dummies
• Alignment: from Entropy to Abstraction
• Products, Projects, Processes
• Knowledge Architecture
• Holistic view
• Agile Architectures: Versatility meets Plasticity