Collaborative Systems Engineering: From Models to Ontologies

Given the digitization of enterprises environments, engineering processes have to be entwined with business ones while kept in sync with enterprise architectures. That calls for new threads of collaboration taking into account the integration of business and engineering processes as well as the extension to business environments.

Whereas models are meant to support communication, traditional approaches are already straining when used beyond software generation, that is collaboration between humans and CASE tools. Ontologies, which can be seen as a higher form of models, could enable a qualitative leap for systems collaborative engineering at enterprise level.

Systems Engineering: Contexts & Concerns

To begin with contents, collaborations should be defined along three axes:

1. Requirements: business objectives, enterprise organization, and processes, with regard to systems functionalities.
2. Feasibility: business requirements with regard to architectures capabilities.
3. Architectures: supporting functionalities with regard to architecture capabilities.

Since these axes are usually governed by different organizational structures and set along different time-frames, collaborations must be supported by documentation, especially models.

Shared Models

In order to support collaborations across organizational units and time-frames, models have to bring together perspectives which are by nature orthogonal:

• Contexts, concerns, and languages: business vs engineering.
• Time-frames and life-cycle: business opportunities vs architecture stability.

That could be achieved if engineering models could be harnessed to enterprise ones for contexts and concerns. That is to be achieved through the integration of processes.

 Processes Integration

As already noted, the integration of business and engineering processes is becoming a key success factor.

For that purpose collaborations would have to take into account the different time-frames governing changes in business processes (driven by business value) and engineering ones (governed by assets life-cycles):

• Business requirements engineering is synchronic: changes must be kept in line with architectures capabilities (full line).
• Software engineering is diachronic: developments can be carried out along their own time-frame (dashed line).

Application-driven projects usually focus on users’ value and just-in-time delivery; that can be best achieved with personal collaboration within teams. Architecture-driven projects usually affect assets and non-functional features and therefore collaboration between organizational units.

Collaboration: Direct or Mediated

Collaboration can be achieved directly or through some mediation, the former being a default option for applications, the latter a necessary one for architectures.

Both can be defined according to basic cognitive and organizational mechanisms and supported by a mix of physical and virtual spaces to be dynamically redefined depending on activities, projects, locations, and organisation.

Direct collaborations are carried out between individuals with or without documentation:

• Immediate and personal: direct collaboration between 5 to 15 participants with shared objectives and responsibilities. That would correspond to agile project teams (a).
• Delayed and personal: direct collaboration across teams with shared knowledge but with different objectives and responsibilities. That would tally with social networks circles (c).

Mediated collaborations are carried out between organizational units through unspecified individual members, hence the need of documentation, models or otherwise:

• Direct and Code generation from platform or domain specific models (b).
• Model transformation across architecture layers and business domains (d)

Depending on scope and mediation, three basic types of collaboration can be defined for applications, architecture, and business intelligence projects.

As it happens, collaboration archetypes can be associated with these profiles.

Collaboration Mechanisms

Agile development model (under various guises) is the option of choice whenever shared ownership and continuous delivery are possible. Application projects can so be carried out autonomously, with collaborations circumscribed to team members and relying on the backlog mechanism.

The OODA (Observation, Orientation, Decision, Action) loop (and avatars) can epitomize projects combining operations, data analytics, and decision-making.

Projects set across enterprise architectures cannot be carried out without taking into account phasing constraints. While ill-fated Waterfall methods have demonstrated the pitfalls of procedural solutions, phasing constraints can be dealt with a roundabout mechanism combining iterative and declarative schemes.

Engineering vs Business Driven Collaborations

With collaborative engineering upgraded at enterprise level, the main challenge is to iron out frictions between application and architecture projects and ensure the continuity, consistency and effectiveness of enterprise activities. That can be achieved with roundabouts used as a collaboration mechanism between projects, whatever their nature:

• Shared models are managed at roundabout level.
• Phasing dependencies are set in terms of assertions on shared models.
• Depending on constraints projects are carried out directly (1,3) or enter roundabouts (2), with exits conditioned by the availability of models.

Moreover, with engineering embedded in business processes, collaborations must also bring together operational analytics, decision-making, and business intelligence. Here again, shared models are to play a critical role:

• Enterprise descriptive and prescriptive models for information maps and objectives
• Environment predictive models for data and business understanding.

Whereas both engineering and business driven collaborations depend on sharing information  and knowledge, the latter have to deal with open and heterogeneous semantics. As a consequence, collaborations must be supported by shared representations and proficient communication languages.

Ontologies & Representations

Ontologies are best understood as models’ backbones, to be fleshed out or detailed according to context and objectives, e.g:

• Thesaurus, with a focus on terms and documents.
• Systems modeling,  with a focus on integration, e.g Zachman Framework.
• Classifications, with a focus on range, e.g Dewey Decimal System.
• Meta-models, with a focus on model based engineering, e.g models transformation.
• Conceptual models, with a focus on understanding, e.g legislation.
• Knowledge management, with a focus on reasoning, e.g semantic web.

As such they can provide the pillars supporting the representation of the whole range of enterprise concerns:

Taking a leaf from Zachman’s matrix, ontologies can also be used to differentiate concerns with regard to architecture layers: enterprise, systems, platforms.

Last but not least, ontologies can be profiled with regard to the nature of external contexts, e.g:

• Institutional: Regulatory authority, steady, changes subject to established procedures.
• Professional: Agreed upon between parties, steady, changes subject to established procedures.
• Corporate: Defined by enterprises, changes subject to internal decision-making.
• Social: Defined by usage, volatile, continuous and informal changes.
• Personal: Customary, defined by named individuals (e.g research paper).

Ontologies & Communication

If collaborations have to cover engineering as well as business descriptions, communication channels and interfaces will have to combine the homogeneous and well-defined syntax and semantics of the former with the heterogeneous and ambiguous ones of the latter.

With ontologies represented as RDF (Resource Description Framework) graphs, the first step would be to sort out truth-preserving syntax (applied independently of domains) from domain specific semantics.

On that basis it would be possible to separate representation syntax from contents semantics, and to design communication channels and interfaces accordingly.

That would greatly facilitate collaborations across externally defined ontologies as well as their mapping to enterprise architecture models.

Conclusion

To summarize, the benefits of ontological frames for collaborative engineering can be articulated around four points:

1. A clear-cut distinction between representation semantics and truth-preserving syntax.
2. A common functional architecture for all users interfaces, humans or otherwise.
3. Modular functionalities for specific semantics on one hand, generic truth-preserving and cognitive operations on the other hand.
4. Profiled ontologies according to concerns and contexts.

A critical fifth benefit could be added with regard to business intelligence: combined with deep learning capabilities, ontologies would extend the scope of collaboration to explicit as well as implicit knowledge, the former already framed by languages, the latter still open to interpretation and discovery.

P.S.

Knowledge graphs, which have become a key component of knowlege management, are best understood as a reincarnation of ontologies.

Further Reading

• Modeling Paradigm
• Views, Models, & Architectures
• Abstraction Based Systems Engineering
• The Cases for Reuse
• The Economics of Reuse
• Focus: Requirements Reuse
• Projects as non-zero sum games
• Projects Have to Liaise
• Agile Collaboration & Social Creativity
• Caminao & EACOE
• EA & MDA
• EA: The Matter of Layers
• EA: Maps & Territories
• EA: Work Units & Workflows
• Ontologies & Enterprise Architecture
• Ontologies as Productive Assets
• Models Transformation & Agile Development
• Agile Architectures: Versatility meets Plasticity