Synopsis
Open concepts and functional patterns can be seen as the two faces of the business/systems divide, the former dealing with business domains, the latter with systems functionalities.
They can be used to build robust and versatile blueprints that could simultaneously tag along the fickleness of markets whims and steer steadfast evolution of systems architectures. One step further, they may also help to reconcile the concerns of business and systems analysts.
Descriptive & Prescriptive Models
As far as systems modeling is concerned, the primary objective is to guarantee the continuity and consistency of representations of business objects and activities along time and across domains; hence the need for business and systems analysts to agree on the identification of targeted individuals and the semantics used to classify them.
On the business side models are used to identify and describe targeted objects and activities. From a formal point of view such models are said to be extensional as their aim is to derive symbolic descriptions for relevant subsets of actual instances.
On the system side models are used to prescribe how these objects and activities are to be represented by symbolic surrogates. Such models are said to be intensional as their aim is to design and build software instances from symbolic descriptions.
Overlooking the difference would imply that descriptive models are fire-and-forget artifacts with no other purpose than bearing out the development of systems which could then be left to stand on their own. What may be a practical assumption for standalone applications is to become a critically misguided one when systems are considered: if IT systems are to be continuously yoked with enterprises’ organization and environment, forsaking descriptive models would be tantamount to cutting IT systems loose from their environment, arguably a terminal offense for enterprise architects.
With that assumption roundly defeated, the aim of blueprints is to chart robust and tested mappings of business processes into supporting systems architectures.
Domain vs Architecture Blueprints
The purpose of blueprints (aka patterns) is to embody expertise that can be directly applied to similar problems. As for reuse in general, the caveat is to bring the relevant blueprints to the fore whenever and wherever needed; that can only be achieved if blueprints are managed along knowledge swim-lines:
- Conceptual blueprints are built with regard to domain specific knowledge; their aim is to feed the functional requirements of supporting systems.
- Functional blueprints are built with regard to IT systems knowledge; their aim is to cross functional and business requirements taking into account architecture capabilities (e.g authorizations or encryption).
As illustrated above, conceptual and functional blueprints are set along orthogonal dimensions: the former as silos set on business domains and activities, the latter set along layers aligned on interactions with supporting systems. The objective would be to achieve transparency and traceability between them.
Open Concepts & Domain Driven Blueprints
Domain driven blueprints are meant to deal with business entities whose identity and integrity have to be guaranteed independently of business processes. Such entities are best epitomized by aggregates as defined by the DDD approach.
As mentioned elsewhere, conceptual blueprints are two-faced: on one side they take from domain specific contents and can therefore be compared to analysis patterns; on the other side they have to remain focused on the corresponding symbolic representations by supporting systems:
- Objects: how to ensure the continuity of identities and the integrity of structures between business entities and their symbolic counterparts.
- Events: how to characterize the synchronization constraints (aka coupling) between respective changes in actual and symbolic realms.
- Activities: how to ensure that business rules and constraints are consistently and comprehensively applied to pertaining symbolic surrogates across processes.
Leaving aside domain specific knowledge (which can be hidden within objects), these issues can be framed in terms of overlapping domains (aka bounded contexts), i.e the management of symbolic representations of business entities subject to cross integrity constraints.
A practical option has been to allocate responsibilities between domains:
- First with regard to identification and integrity, to be managed through aggregates,
- Then, with regard to semantics and use, to be managed through contexts.
The downside of that scheme is its reliance on best practices, and consequently its limitation when faced with exponential complexity.
That’s where a “divide and conquer” policy could help, especially one based on formal distinctions: open concepts are introduced to factor out and differentiate patterns of structural and functional integrity constraints.
Taking agents as example, open concepts for Human and Social agents are introduced for entities with social identities, respectively with and without physical existence (and therefore interaction capability); by contrast, concepts of Organization, Person, and Product are bound to domains, some institutional, others business specific.
The benefits of open concepts are twofold:
- They open the door to design patterns that can be applied to shared entities independently of domains specificity.
- Conceptual (aka domain based) blueprints set with regard to identification and collaboration mechanisms can be formally mapped to functional patterns or combined into architecture driven blueprints.
On a broader EA perspective open-concepts could be combined with ontologies and used to organize enterprise knowledge according to the nature of contexts (institutional, professional, corporate, social or personal) and concerns (business, systems, technologies).
Functional Patterns & Architecture Driven Blueprints
Functional Patterns (aka blueprints) are archetypes of system functionalities, not to 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 take from both sides, functional patterns come with a specific purpose, namely to associate relevant problems set by business processes to functional solutions to be supported by systems architectures.
The term of footprint can be used to illustrate the transition: conceptual patterns are focused on the identity, structure, and aspects of business elements (objects, events, or activities), footprints focus on their system surrogates, to be refactored according to functional patterns. Put together they provide the pillars of a bridge between business problems (as expressed by conceptual models), and supporting systems solutions (as represented by functional footprints).
And beside their role as a modeling glue between business domains and architecture functionalities, conceptual blueprints can also be directly mapped to enterprise objectives, strategies, and capabilities by introducing enterprise architecture blueprints.
Finally, if effective reuse is to be achieved, user-friendly environments should help analysts with the selection and mapping of conceptual patterns and functional blueprints.
Blueprints and Thesaurus
Blueprints benefits go back and forth: on one hand they pull normalized problem layouts as befitted to the requirements under consideration, on the other hand they push well tested solutions as befitted to current functional architectures. Yet that is more easily said than done and blueprints are to remain pointless if not systematically, continuously, and properly updated and reused. And that cannot be achieved without an user-friendly thesaurus able to characterize problems and contexts and suggest suitable options.
Further Readings
- Open Concepts Will Make You Free
- Open Concepts
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- Focus: Bounded Contexts & Open Concepts
- Functional Patterns
- Conceptual Thesaurus: Overview
- Conceptual Thesaurus: Typical use cases
- Projects Have to Liaise
- UML’s Semantic Master Key, Lost & Found
- Conceptual Models & Abstraction Scale
- Architectures capabilities