Modeling Paradigm

Objective

As the world turns digital, the divides between social lives, corporate businesses, and physical realities are progressively dissolved. That calls for  some unified modeling framework that would supplement OMG’s unified modeling language (UML).

What is represented ? (E. Antin)

Picturing the representation of a model (E. Antin)

Taking a leaf from the Stanford University’s Symbolic Systems Program:

“Computer systems, robots, and people are all examples of symbolic systems, agents that use meaningful symbols to represent the world around them so as to communicate and generally act in the world,”

the objective would be to consolidate the modeling concepts supporting the symbolic representation of those agents.

Modelling Capabilities

Models can be classified with regard of scope (partial or full description of features), and target (actual occurrences or types):

  • 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)
Procs_IntExt0

Abstractions in Models

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.

Modelling Scopes

Agents with symbolic processing capabilities (systems, humans, robots) can appear into four types of models:

  • Enterprise: models are meant to describe assets, organization, and processes.
  • Domains: models are meant to describe business objects and associated semantics independently of enterprises.
  • Systems functionalities: models are meant to describe how IT systems support business processes.
  • Software components: models are meant to describe how systems functionalities are implemented.

The first step is therefore to characterize modeling languages with regard to scope:

  • Business process modeling languages are used to associate business domains and enterprises organization.
  • Domain specific languages do the same between business domains and software components, bypassing enterprise organization and systems architecture.
  • Generic modeling languages like UML are supposed to cover the whole range of targets.
  • Languages like Archimate focus on the association between enterprises organization and systems functionalities.
  • Contrary to modeling languages programming ones are meant to translate functionalities into software end-products. Some, like WSDL (Web Service Definition Language), can be used to map EA into service oriented architectures (SOA).
eaSQ4_Lang

Targets and Modeling Languages

While those languages can be combined, e.g DSLs coupled with UML or BPM, there is no consolidated representation of targets’ content except for predefined ones, e.g by ERPs.

Consolidated symbolic representations

The next step is to unify the symbolic representation of agents endowed with symbolic processing capability and their behaviors:

  • Containers: physical (e.g locations, systems) or  symbolic (e.g domains) spaces.
  • Physical entities: agents (human beings, robots, systems) or passive objects.
  • Roles of agents.
  • Events.
  • Activities: business logic and processes control.
  • Symbolic descriptions of all the above.

Modeling scopes can be generalized and characterized with regard to visibility and synchronization with their target:

  • Enterprises can be seen as a subset of social organizations, with models describing assets, organization, and processes. While the descriptions are not necessarily shared by outsiders, these models must support the continuity and consistency of the business objects and activities they describe.
  • Business domains can be reset along a knowledge perspective, with models describing items (objects or behaviors), features, and  ontologies. These models are meant to be shared across all concerned social entities. Since those entities are supposed to take full responsibility for the continuity and consistency of domain objects and activities, models of knowledge don’t have to be synchronized with instances and can therefore be modified independently.
  • System functionalities can be reset in terms of services, with models describing access to the symbolic counterparts of actual objects and activities. Those models are by nature public and descriptions have no life-cycles.
  • Software components describe the implementation of symbolic representations. Models are not meant to be shared but systems objects must be kept in synch with their enterprise counterpart.
Models contents with regard to visibility and synchronization with scope

Models contents with regard to visibility and scope synchronization

UML can then be used to bring views and models together:

  • UML diagrams can be customized into BPM editors.
  • UML stereotypes and profiles can be defined for specific domains and/or enterprises.

Yet, the most significant benefits are achieved when model based system engineering is used to bring together conceptual models and enterprise architectures.

From Conceptual Models to Architecture Capabilities

On one hand conceptual models describe business context and enterprise organization and processes. On the other hand architecture capabilities specify what kind of support the systems can provide to processes. In between the functional models define the symbolic representations meant to realize the capabilities.

From Concepts to Capabilities

Software components (for symbolic representations) and resources deployment (for capabilities) are hided as implementations.

By bringing enterprise and system concepts under a seamless modeling framework this paradigm should provide the backbone of enterprise architecture.

Further Reading

External Links

Advertisements

5 Responses to “Modeling Paradigm”

  1. Mordechai d'Angletoofe Says:

    Re “Systems functionalities…describe how IT systems support business processes.”

    Did you mean to include only computerized systems? Or conversely, did you mean to include all data management systems, including for example paper-based systems?

    Like

  2. Mordechai d'Angletoofe Says:

    Thanks.

    Like

  3. Paolo Ciancarini Says:

    Why no mention of Archimate? It seems to me that Archimate is a nice extension of UML for modeling EA

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: