Objectives
Reuse can be managed at component or model level. At model level patterns describe stable and safe engineering solutions both for business and engineering perspectives:
- Business perspective, reuse targets services defined by the enterprise architecture.
- Engineering perspective, reuse targets development artifacts as defined by the different model layers.
Patterns are especially effective when defined within the model driven engineering framework and the objective is to build models from modules set along architectural concerns.
Levels
Representation (aka functional) patterns are archetypes of symbolic representations and should not be confused with business patterns, which are archetypes of business activities. Whereas both can overlap, their purpose is essentially different as, contrary to business (aka analysis) patterns, representation patterns target system functional architectures. As for design patterns, thanks to the Gang of Four, they are now well understood and accepted as archetypes of component implementations.
Patterns of symbolic representations can also be seen as archetypes of functional architectures as they deal with the organization of core system functionalities (persistency, authorization, communication, etc.) independently of the technical platform supporting them. That approach to reuse is best represented by Service Oriented Architectures (SOA) whose rationale is to map corporate business invariants, business entities or processes into services supported by unspecified systems.
Reusing well-tested artifacts is arguably a win-win option, with benefits on costs as well as on quality. Yet, if design patterns are widely used for system components, that’s not the case for analysis patterns, which are kept within the silos of domain specific languages. As a consequence, the benefits of reuse remain local and contingent:
- Local, because design patterns are limited to individual components while analysis patterns are mostly confined to attributes implemented through semantics domains.
- Contingent, because whatever the maturity of design patterns, their benefits depends upon the soundness of the analysis models which support them.
In order to overcome those limitations, patterns and semantic domains must be seamlessly integrated from requirements to design while, at the same time, architectural patterns should be fenced off.
Analysis vs Design
Given that patterns are symbolic constructs meant to be reused, a clear understanding of purposes is a prerequisite. And purposes must, first and foremost, be set along the Analysis/Design divide:
- Analysis deals with the problem under scrutiny. Its objective is to extract the relevant aspects.
- Design deals with the solution. Its objective is to define the corresponding artifacts.
The challenge is to build a bridge between patterns used for analysis to those used for design.
Patterns and software development methods
Beyond and above the jungle of acronyms, things are much more stable and consistent than what it seems, and the different approaches can be set along shared perspectives, namely problems, solutions, processes.
Problem patterns should be examined according to requirements nature:
- Business problems are set by contexts and objectives and should not be dependent of system functionalities or technical platforms. That is what MDA’s Computation Independent Models (CIMs) are meant to describe.
- Functional problems examine how the system under consideration should support users dealing with business problems, whatever the technical platform. That is what MDA’s Platform Independent Models (PIMs) are meant to describe.
- Technical problems examine how the functionalities under consideration should be implemented, given the way they will be accessed and the constraints on performances and resources. That is what MDA’s Platform Independent Models (PIMs) are meant to describe.
Solution patterns should be set according their architecture footprint:
- At their simplest, solution patterns deal with standalone accesses.
- Next, one should find patterns dealing with collaboration at application level, i.e functionalities encompassing simultaneous accesses to transient business objects.
- Finally, one will find patterns dealing with collaboration at domain level, i.e functionalities encompassing simultaneous accesses to persistent business objects.
Patterns like Model-View-Controller (MVC), Presentation-Abstraction-Control (PAC), or Boundary-Entity-Control (EBC) are set along those principles at functional level; classic design patterns of the GoF take also into account implementation concerns.
Process patterns should be set according to the problems to be solved and their architecture footprint:
- Agile-like development patterns are first candidates when problems and solutions can be examined within single loops with stakeholders, users, and developers.
- Staged development patterns are necessary when solutions are to be consolidated across architecture layers.
- Milestones and waterfall development processes cannot be avoided whenever stakeholders belong to different organizational units.
Patterns and Enterprise Architecture
Enterprise architecture introduces a new perspective best defined when compared to conceptual and functional ones:
- Conceptual blueprints can be seen as a generalization of business patterns as they target business domains independently of the representation by systems.
- Functional blueprints can be seen as the external view of architecture patterns as they target systems functionalities independently of their implementation by platforms
Along that perspective enterprise architecture blueprints would be about the governance of architecture capabilities along time and across architecture layers: business, systems, and platforms.