Preamble
The digital immersion of enterprises in their business environment and the ubiquity of software agents in business processes may put business patterns in a new perspective.
Until now attempts to reproduce on the business side the track record of design patterns on the system side have remained patchy, either too specific or too generic.
Too specific when detailed features generate constrained structures and semantics; too generic when stepping up the abstraction ladder brings about descriptions detached from contexts and concerns and therefore irrelevant.
In between, the focus should be on enterprise architecture patterns set with regard to:
- A distinction between structural and functional aspects
- A reasoned approach to reuse, in particular through models transformation
- Open symbolic representations satisfying SOLID principles
The objective here is to take Party as an archetype and use the basic options to expound the scope of EA patterns and mark the difference with business patterns.
Perspectives & Scope
Business patterns are usually drafted as conceptual models of data-bases, i.e. with regard to system architecture.
Conversely, when they try to reflect business concerns, patterns are confronted to an intrinsic dilemma: enterprises have no reason to publish and share the key success factors behind their management of critical business data.
Nevertheless, given that business objects are routinely traded between enterprises and their environment, a set of agreed structures and semantics have to be supported by enterprise architectures. With regard to parties, such commons must cover two issues: identification is about anchoring enterprises to their environment, roles is about ensuring that enterprises’ business domains and organizational units are on the same page. Going further and delving into the semantics of business features should be left to specific business agreements.
Basic Options
To be of any use, EA patterns should accommodate a variety of contexts through adjustments, specialization, or extension. For parties, that can be best achieved with patterns defined along structural (for identity) and functional (for roles) perspectives, the former set at the enterprise level, the latter through contracts. That distinction is straightforward with extensions and delegation, not so with specialization and subtypes.
Specialization & Subtypes
Assuming a base class providing a generic description of parties, it could encompass both identities and roles (concrete class), or only roles (abstract class).
Concrete class
A concrete understanding (a) means that a base class can directly represent all occurrences (aka instances), assuming that specific features can be ignored. Along that reasoning all parties can be identified (#) independently of their roles through a single identification mechanism, without overlapping roles.
Abstract Class
By contrast, an abstract base class (b) describes only the subset of features common to all parties, independently of their identity. On that basis parties can only be identified through their roles, possibly defined at the domain level.
Limits of Specializations
Defining a Party pattern in terms of specialization implies a single identification mechanism, set uniformly for sets and subsets (concrete base class), or type and subtypes (abstract base class).
A specialization pattern may be relevant at the system level, but not at the enterprise level where internal (blue color) and external (green color) identities must be represented and managed separately.
It ensues that as far as EA is concerned, concrete specialization is irrelevant because the identification of persons and organizations is set by environments, not by enterprises. As for abstract specialization, it makes no room for a full and autonomous management of parties’ identities at the enterprise level.
Extension & Delegation
The limits of structural (identities) and functional (roles) specialization patterns can be overcome through the use of delegation (c). In that case a concrete class can serve three different purposes:
- Uniformly represents all parties identified at the enterprise level
- Ties their internal identity (blue color) to their external counterpart as persons or organization (green color)
- Associates the common structure of all parties to the specific representation of their roles
Why It Matters
A Party pattern epitomizes the specificity of the EA perspective compared to the business and system ones.
Business patterns are not supposed to take into account the representation of business objects and processes by supporting systems; instead, their primary objective is to bring open-ended business domains semantics under a common conceptual roof.
Conversely, design patterns can rely on the well defined semantics of modeling languages.
In between the primary objective of EA patterns is to provide a bridge between epistemic levels without relying on an specific modeling language:
- Epistemic levels: actual objects and phenomena on the one hand, symbolic representation on the other hand.
- Modeling languages: EA patterns must deal with abstractions independently of the semantics of systems modeling languages.
That can only be achieved with ontologies which use knowledge to bring together thesaurus (for business concepts) and modeling languages (for systems semantics).