Representation (aka Functional) Patterns

Preamble

Whereas modeling languages like UML are just tools to be used to describe artifacts, the means often take precedence over the ends, as if the language telescope was used in reverse, looking at itself instead of targets. Representation patterns are an attempt to correct this bias by picking out features relevant to business requirements and system analysis before selecting language constructs to describe them.

Modeling patterns are reusable descriptions, i.e generic forms that can be used in different contexts. What is usually known as analysis patterns (business patterns may be more accurate) describe basic objects (customer, portfolio, …) or processes (take order, ship, invoice, …) independently of the way systems may support them. Design patterns describe system components independently of their business meanings.

Actual & Symbolic Realities (MC Escher)

Thanks to the Gang of Four, design patterns are widely accepted and consistently implemented across platforms. Yet, nothing equivalent has happened for analysis patterns, which remain confined to specific domains and organizations. That should have been expected considering that specificity and versatility are critical factors for business success: business models are not to be shared but are meant to change as fast as market opportunities. Hence, there is some gap between business and design patterns, namely, there is a need for representation  (aka analysis, aka functional) patterns, i.e generic descriptions of system functionalities independently of both their business meaning and system counterpart.

Beyond lexical controversies, that could be achieved with models and architectures 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).

Interactions could be also symbolized with the “M” of model:

Descriptive (analysis) vs Prescriptive (design) Patterns

The rationale for representation patterns is double:

  • Since systems are defined as combinations of actual objects and processes on one hand, and their symbolic representations on the other hand, patterns of representations are clearly in need.
  • If models (and engineering) are to be driven by architecture, that must be supported by sound foundations, more precisely, it is necessary to map business requirements into functional archetypes.

Organization

Whereas some representation patterns are  sometimes described as analysis patterns, the terminology may introduce some confusion with business patterns. Following the rationale above, core patterns may be organized along two perspectives: representation and persistency.

Along the representation perspective, patterns must characterize how actual objects and processes are associated to their symbolic counterpart.

Symbolic representations and actual counterparts

Along the persistency perspective, patterns must characterize how execution units (i.e activities) are coupled to persistent ones. Depending on domains or architecture, patterns may describe processes synchronization or  time dependencies between persistent representations.

Engineering Symbolic Representations

Engineering processes are meant to sequence activities along intrinsic factors, as opposed to operational processes whose aim is to adapt activities to contexts. Whereas factors governing manufacturing processes depend upon the physical contingencies of material flows, the rationale behind software engineering processes is first and foremost governed by constraints on development flows, whose nature is essentially symbolic.

issa-samb
Seats or Spades, Actual or Symbolic (Issa Samb).

Development processes usually follow one of two schools: procedural or acrobatic. Procedural processes impose one-fits-all development frameworks and significant overheads to compensate for the misfits; acrobatic ones bet on responsibility, expertise and best practices but don’t say much about development artefacts. The challenge is to take the best of each: shared understanding of model contents, lean developpment processes, sound anticipations, reliable commitments, and traceability.

Architecture Driven Modelling takes source from OMG’s Model Driven Architecture. More generally, it follows the well accepted distinction between requirements, analysis, and design, and can be implemented with OMG’s Unified Modeling Language.

Analysis models describe the symbolic representations of business objects and processes. They use requirement models, which describe business objects and processes. They are used by design models, which specify how symbolic representations will be implemented as system objects; implementation and deployment are not considered here.

Model Layers: Requirements, Analysis, Design.

Given those layers, system engineering has to manage objectives pertaining to a three-pronged perspective:

  • The business perspective is synchronic as it deals with the symbolic representation of context objects and processes. Since objectives, constraints, and risks change along their own time-frames, their symbolic representations must do the same; as a consequence system requirements must be continuously and consistently anchored to business  contexts.
  • The engineering perspective is diachronic as it deals with the implementation of system symbolic representation. Once rooted into requirements, the design and implementation of  symbolic representations are only concerned with the life cycle of development artefacts.
  • In between the architecture perspective is meant to be as invariant as core business concerns and corporate identities.

Given an architecture, both business and system models can be managed separately, each along its own timeframe, providing they don’t contradict architectural constraints.

sculptures_ad0
Actual & Symbolic Representations

Based upon the layered view of models,  engineering processes can be built bottom-up from work units directly defined from development flows. As a consequence, they can be better fitted to tasks, assessed, and improved.

Taking inspiration from the Capability Maturity Model Integration (CMMI), the benefits of architecture driven modelling can be identified for product, project, and process areas:

  • Traceability is obviously a starting point as it is a pre-requisite for streamlined engineering (product), portfolio and risk management (project), and application lifecycle management (process).
  • Measurement comes close, with built-in unbiased estimators, project workloads, and process assessment.
  • Quality management would clearly benefits from layered traceability and objective measurements, with built-in controls, non-regressive testing, and model-based validation.
  • Reuse provides another path to quality, with patterns (product), profiles (project) and development strategies (processes).
  • Finally, collaboration is to be facilitated between engineering processes targeting heterogeneous platforms, using different methodologies, across independent organizations.

Modeling Symbolic Representations

System modeling is all too often a flight for abstraction, when business analysts should instead look for the proper level of representation, ie the one with the best fit to business concerns.

Modeling is synchronic: contexts must be mapped to representations (Velazquez, “Las Meninas”).

Caminao’s blog (see Topics Guide) will try to set a path to Architecture Driven System Modelling. The guiding principle is to look at systems as sets of symbolic representations and identify the core archetypes defining how they must be coupled to their actual counterparts. That would provide for lean (need-to-know specs) and fit (architecture driven) models, architecture traceability, and built-in consistency checks.

This blog is meant to be a work in progress, with the basic concepts set open to suggestions or even refutation:

All examples are taken from ancient civilizations in order to put the focus on generic problems of symbolic architectures, disregarding technologies.

Symbolic representation: a primer

Original illustrations by Albert (http://www.albertdessinateur.com/) allow for concrete understanding of requirements, avoiding the biases associated with contrived textual descriptions.