Models, Architectures, Perspectives (MAPs)

What You See Is Not What You Get

Models are representations and as such they are necessarily set in perspective and marked out by concerns.

• Depending on perspective, models will encompass whole contexts (symbolic, mechanic, and human components), information systems (functional components), software (components implementation).
• Depending on concerns models will take into account responsibilities (enterprise architecture), functionalities (functional architecture), and operations (technical architecture).

While it may be a sensible aim, perspectives and concerns are not necessarily congruent as responsibilities or functionalities may cross perspectives (e.g support units), and perspectives may mix concerns (e.g legacies and migrations). That conundrum may be resolved by a clear distinction between descriptive and prescriptive models, the former dealing with the problem at hand, the latter with the corresponding solutions, respectively for business, system functionalities, and system implementation.

Models as Knowledge

Assuming that systems are built to manage symbolic representations of business domains and operations, models are best understood as knowledge, as defined by the pivotal article of Davis, Shrobe, and Szolovits:

1. Surrogate: models provide the description of symbolic objects standing as counterparts of managed business objects and activities.
2. Ontological commitments: models include statements about the categories of things that may exist in the domain under consideration.
3. Fragmentary theory of intelligent reasoning: models include statements of what the things can do or can be done with.
4. Medium for efficient computation: making models understandable by computers is a necessary step for any learning curve.
5. Medium for human expression: models are meant to improve the communication between specific domain experts on one hand, generic knowledge managers on the other hand.

What You Think Is What You Get

Whereas conventional engineering has to deal with physical artifacts, software engineering has only symbolic ones to consider. As a consequence, design models can be processed into products without any physical impediments: “What You Think Is What You Get.”

Yet even well designed products are not necessarily used as expected, especially if organizational and business contexts have changed since requirements capture.

Models and Architectures

Models are partial or complete descriptions of existing or intended systems. Given that systems will eventually be implemented by software components, models and programs may overlap or even be congruent in case of systems made exclusively of software components. Moreover, legacy systems are likely to get along together with models and software components. Such cohabitation calls for some common roof, supported by shared architectures:

• Enterprise architecture deals with the continuity of business concerns.
• System architecture deals with the continuity of systems functionalities.
• Technical architecture  deals with the continuity of systems implementations.

That distinction can also be applied to engineering problems and solutions: business (>enterprise), organization (supporting systems), and development (implementations).

On that basis the aim of analysis is to define the relationship between business processes and supporting systems, and the aim of design is to do the same between system functionalities and components implementation.

Whatever the terminology (layers or levels), what is at stake is the alignment of two basic scales:

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

If systems could be developed along a “fire and forget” procedure models would be used only once. Since that’s not usually the case bridges between business contexts and supporting systems cannot be burned; models must be built and maintained both for business and system architectures, and the semantics of modeling languages defined accordingly.

Languages, Concerns, Perspectives

Apart for trivial or standalone applications, engineering processes will involve several parties whose collaboration along time will call for sound languages. Programming languages are meant to be executed by symbolic devices, business languages (e.g B.P.M.) are meant to describe business processes, and modeling languages (e.g UML) stand somewhere in-between.

As far as system engineering is concerned, modeling languages have two main purposes: (1) describe what is expected from the system under consideration, and (2) specify how it should be built. Clearly, the former belongs to the business perspective and must be expressed with its specific words, while the latter can use some “unified” language common to system designers.

The Unified Modeling Language (UML) is the outcome of the collaboration between James Rumbaugh with his Object-modeling technique (OMT), Grady Booch, with his eponymous method, and Ivar Jacobson, creator of the object-oriented software engineering (OOSE) method.

Whereas UML has been accepted as the primary standard since 1995, it’s scope remains limited and its use shallow. Moreover, when UML is effectively used, it is often for the implementation of Domain Specific Languages based upon its stereotype and profile extensions. Given the broadly recognized merits of core UML constructs, and the lack of alternative solutions, such a scant diffusion cannot be fully or even readily explained by subordinate factors. A more likely pivotal factor may be the way UML is used, in particular in the confusion between perspectives and concerns.

Languages are useless without pragmatics which, for modeling ones means some methodology defining what is to be modeled, how, by who, and when. Like pragmatics, methods are diverse, each bringing its own priorities and background, be it modeling concepts (e.g OOA/D), procedures (e.g RUP), or collaboration agile principles (e.g Scrum). As it happens, none deals explicitly with the pivotal challenges of the modeling process, namely: perspective (what is modeled), and concern (whose purpose).

In order to meet those challenges the objective of the Caminao framework is to provide compass and signposts for road-maps using stereotyped UML constructs.

Models, Architectures, Perspectives (MAPs)

From a general perspective, and beyond lexical controversies, models and architectures should be defined along two parallel scales:

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

Caminao maps add perspectives:

• Models set the stages, where targeted artifacts are defined depending on concerns.
• Topography put objects into perspective as set by stakeholders situation: business objectives, system functionalities, system implementation.
• Concerns and perspectives must be put into context as defined by enterprise, functional or technical architectures.

The aim of those maps is to support project planning and process assessment:

• Perspective and concerns: what is at stake, who’s in charge.
• Milestones: are expectations and commitments set across different organizational units.
• Planning: development flows are defined between milestones and work units set accordingly.
• Tasks traceability to outcomes and objective functional metrics provide for sound project assessment.
• Processes can be designed, assessed and improved by matching  development patterns with development strategies.

Matching Concerns and Perspectives

As famously explained by Douglas Hofstadter’s Eternal Golden Braid, models cannot be proven true, only to be consistent or disproved.

Depending on language, internal consistency can be checked through reviews (natural language) or using automated tools (formal languages).

Refutation for its part entails checks on external consistency, in other words matching models and concerns across perspectives. For that purpose modeling stations must target well defined sets of identified objects or phenomena and use clear and non ambiguous semantics. A simplified (yet versatile), modeling cycle could therefore be exemplified as follows:

1. Identify a milestone  relative to perspective, concern, and architecture.
2. Select anchors (objects or activities).
3. Add connectors and features.
4. Check model for internal consistency.
5. Check model for external consistency, e.g refutation by counter examples.
6. Iterate from 2.

Further Reading

• Architectures
• Model Driven Architecture
• Architecture Knowledge
• Architecture Capabilities
• Architecture Capabilities and Requirements

External Links

• A Historical Look at Enterprise Architecture with John Zachman
• Sowa John F., John A. Zachman, “Extending and formalizing the framework for information systems architecture”
• Enterprise Architecture Explorations