EA: A Common Modeling Roof

To become a discipline enterprise architecture has to contrive some shared modeling paradigm; that can be done from established ones like layers, MVC (Model-View-Controller), MDA (Model Driven Architecture), or the 4+1 views.

A Portable & Inter-operable Roof (Jonas Bendiksen)

Architecture Layers

To begin with, the basic layers of process, data, application, and technology layers can be rearranged as to make data orthogonal to other layers.

Then, Model Driven architecture (MDA) can be used as representative of model based systems engineering (MBSE) approaches:

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

It can also be easily aligned with Zachman framework.

With regard to data bases modeling, there is a large consensus for the conceptual, logical, and physical distinction:

  • Conceptual models describe enterprises organization and business independently of supporting systems.
  • Logical models describe the symbolic objects managed by supporting systems as surrogates of business objects and activities.
  • Physical (nowadays digital) models describe the actual implementation of symbolic surrogates as binary objects.

As for systems functional modeling, the Model-View-Controller (MVC) is arguably the leading pattern whatever the guises:

  • Model: shared and a life-cycle independent of business processes. The continuity and consistency of business objects representation must be guaranteed independently of the applications using them.
  • View: what is not shared with a life-cycle set by user session. The continuity and consistency of representations is managed locally (interactions with external agents or devices independently of targeted applications.
  • Controller: shared with a life-cycle set by a business process. The continuity and consistency of representations is managed independently of the persistency of business objects and interactions with external agents or devices.

Services can be introduced to represent functions to be shared with no life-cycle.

Architecture engineering

Finally, the relationships between architecture blueprints and systems engineering can be derived from Philippe Kruchten’s “4+1”: View Model of Software Architecture”:

  • Logical view: design of software artifacts.
  • Process view: execution of activities.
  • Deployment (aka physical) view: mapping of software components across physical environments (platforms).
  • Development (aka implementation) view:  organization of software artifacts in development environments.

A fifth view being added for use cases describing interactions between systems and environments.

At first, views at enterprise architecture level appear to be congruent with these ones, e.g: logical for data, process for applications, physical for technology. But labels may be misguiding when applied indifferently to software architecture (views) and enterprise architecture (layers): contrary to views, which are solely defined by concerns independently of targeted structures, layers reflect definitive assumptions about architectures. That confusion between views and layers, illustrated by a miscellany of tabular and pyramidal representations, would be of little consequence were the modeling of changes not a critical issue; not so for enterprise architecture.

As it happens the confusion can be worked out if views are redefined solely and comprehensibly in terms of engineering:

  • Domains modeling: conceptual, logical, and physical.
  • Applications development: business logic, systems functions, programs.
  • Systems deployment: locations, processes, configurations.
  • Enterprise organisation and operations.

That make views congruent with engineering workshops, enabling a seamless integration of enterprise architecture blueprints with evolutionary processes.

FURTHER READING

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.