Functional Patterns

 Preamble

The primary objective of enterprise architecture is to bring business, organization, and systems under a single governance roof. Whatever the CxO acronym put on that roof, what is at stake is the dynamic relationship between business and systems concerns, the former subject to external factors and driven by changing opportunities, the latter based on planned developments and constrained by organizational and technical factors.

Managing that pivot cannot be achieved without principled hinges joining actual business environments and processes to serviceable symbolic representations (aka models). Defining such hinges is the aim of functional (aka representation) patterns.

A Taxonomy of Functional Problems

As epitomized by the GoF with designs, patterns are best understood as sound and secure drawbridges linking problems to solutions. Set in the context of enterprise architecture, functional patterns can be organized around three categories of problems:

1. Architectural problems: solutions have to further the alignment of enterprise organization and systems with business strategies.
2. Operational problems: solutions have to further lean and just-in-time processes.
3. Business problems: solutions have to further continuity and integrity of symbolic representations with regard to business entities.

On one side that classification can be neatly mapped to architectures capabilities:

1. Who (agents) is entitled to What (goals): Functional patterns should be first defined with regard to the type of agents (human, systems, or devices) and associated capacities as defined by enterprise organization and resources.
2. Where (locations) and When (events): Then, patterns should consider the control of business processes, namely the action semantics supporting the collaboration between contributing agents.
3. How (business logic): finally, given processes defined with regard to contexts (actors and events) and goals, the focus will be on scripting the sequence of operations affecting the representation of business entities.

On the other side it can be mapped to action semantics:

It can also be mapped to the GoF categories for creational, behavioral, and structural design patterns.

A Taxonomy of Functional Solutions

Functional patterns are archetypes of system functionalities; they should not be confused with business patterns, which are archetypes of business activities, nor with conceptual ones, which are archetypes of thought disconnected from specific considerations. Whereas they can overlap with both, their purposes are essentially different as, contrary to the former  they target system functional architectures, and, contrary to the latter they must stay anchored to the business under consideration (cf abstraction layers).

Since the objective is to fence off technical features, the focus is to be on the symbolic and actual dependencies of objects and activities, e.g:

• Persistency patterns describe archetypes of dependencies between persistency units depending on synchronization constraints and responsibilities.
• Responsibilities patterns describe how active objects are “decorated” with interfaces or roles.
• Workflow patterns describe archetypes of dependencies between execution units depending on synchronization constraints, execution flows, locations, and access authorizations.
• Strategies describe patterns of activities independently of time constraints; transformation patterns describe data flows processing.
• Context and entry points patterns deal with boundaries between systems and contexts. They are the actual complement of user patterns, which deal with symbolic accesses. State patterns deal with the behavior of active objects as processed by workflows.
• Use case patterns deal with functional requirements from an architecture driven perspective.
• Finally, power-type patterns deal with archetypes of partitions as applied to objects (ontologies) and activities (controls).

Representation patterns may be especially adapted to services oriented architectures since they don’t make use of abstractions but are nonetheless meant to map business processes into functional architectures built from services.

Stereotyped Building Blocs

If functional patterns are to be of any use they must be associated with architectural features with unambiguous functional semantics. That can be achieved using a comprehensive and principled set of stereotypes obtained through a cross of UML#  basic archetypes:

• Physical objects: passive, actual documents, agents, I/O devices, information systems, control systems.
• Symbolic representations (aka surrogates) for: physical objects, documents, roles, events, business logic, processes’ states.
• Roles (UML Actors) to be played by: people, systems, objects, documents, users, events, services, processes.
• Events: changes to physical or symbolic objects, expectations, computation, processes’ states.
• Actions performed on (passive entities)/by (active entities): people, physical or symbolic objects, actors, computations, processes execution.
• States of: physical or symbolic objects, interactions, devices, computations, processes.

The same rationale is applied to containers.

With regard to connectors, stereotypes are used to clarify coupling constraints:

• References between symbolic objects may be neutral regarding object states, or may entail synchronized updates.
• Flows between functional units may be neutral regarding execution (data), or may be associated with requests (control).
• Transitions between execution units may be neutral regarding their respective states (asynchronous) or may require synchronization.
• Communication channels between active objects may be neutral regarding objects connection (simplex), or may require synchronization.

Symbolic Objects

Eventually, all business-relevant items are meant to be represented by their symbolic system counterpart:

• Physical objects: state of relevant business features.
• Documents.
• Roles: record of agent activities.
• Event records.
• Activities description.
• Record of process execution states.

Features

Contrary to symbolic objects which are anchored to identified business elements, persistent or transient, features cannot be identified on their own and their business semantics is set by supporting objects. Yet, they may be characterized depending on their processing:

• Literals are symbolic features which can be interpreted directly.
• References are symbolic features whose interpretation require access to other objects.
• Numeric values are non symbolic features whose interpretation require access to other objects.
• Binary objects are non symbolic features which can be interpreted directly.

The same principles may be applied to operations, set along their scope (local or system) and their side effect regarding the status of symbolic representations vis-à-vis actual counterparts:

• External I/O are local operations, whose execution modify the status of symbolic representations vis-à-vis context counterparts.
• Computations are local operations whose execution doesn’t modify the status of symbolic representations vis-à-vis context counterparts.
• Transactions are symbolic operations performed globally, whose execution modify the status of symbolic representations vis-à-vis context counterparts.
• Searches are symbolic operations performed globally whose execution doesn’t modify the status of symbolic representations vis-à-vis context counterparts.

It must be noted that this approach follows the Command-Query Separation introduced by Bertrand Meyer; moreover, by combining change with scope, it provides a sound basis to the Command-Query-Responsibility-Segregation (CQRS) design pattern used by domain-driven methods.

Stereotyped Features

One step further, attributes and operations may also be stereotyped in terms of their functional semantics.

Further Reading

• A Modeling Paradigm
• Enterprise Architecture and Separation of Concerns
• Inducing Functional Patterns from Design ones: a look in rear view mirror
• Knowledge-based Models Transformation
• Open Concepts
• Open Concepts Will Make You Free
• System Conceptual Thesaurus
• UML’s Semantic Master Key, Lost & Found
• Knowledge Architecture

External Readings

• Business Patterns (Aotea)