System modeling is all too often a flight for abstraction, when business analysts should instead look for the proper level of representation, i.e the one with the best fit to business concerns.
Caminao’s blog 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.
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.
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 patterns, i.e generic descriptions of system functionalities independently of both their business meaning and system counterpart.
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.
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.
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.
Manufacturing deals with material flows, Software engineering with symbolic ones.
Development processes usually follow one of two schools: bureaucratic or acrobatic. Bureaucratic procedures impose one-fits-all development frameworks and significant overheads to compensate for the misfits; acrobatic endeavors bet on responsibility, expertise and best practices but don’t say much about development artifacts. The challenge is to take the best of each: shared understanding of model contents, lean development processes, sound anticipations, reliable commitments, and traceability.
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.
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 artifacts.
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 time-frame, providing they don’t contradict architectural constraints.
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.
Traceability is obviously a starting point as it is a prerequisite for streamlined engineering (product), portfolio and risk management (project), and application life-cycle 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.
Revisiting the well established distinction between requirements (context objects and behaviors), analysis (symbolic representations) and design (system components), the purpose is to identify core architectural features in descriptive models and map them into qualified constructs within specification models. For that purpose, representation patterns are needed in order to bridge the gap between business and design patterns.
Using well accepted concepts, the proposed approach introduces a new paradigm by putting business objects and system components under a single modeling roof. Moreover, by avoiding the use of best practices, this approach is open to refutation on its own and should open new perspectives to core software engineering problems like traceability, reuse or validation.
Examples are taken from ancient civilizations in order to focus on generic system architectures, whatever the technology.
Original illustrations by Albert (http://www.albertdessinateur.com/) allow for concrete understanding of requirements, avoiding the biases associated with contrived textual descriptions.