Preamble
According to the Stanford’s Symbolic Systems Program (SSP) the role of computer systems is to manage symbolic representations, that is artifacts engineered from abstract descriptions of actual (external) objects and processes.
As famously stated by Einstein, the reason for time (hence processes) is to ensure that things will not happen at once. Put together, it ensues that software development can be understood as the engineering of abstractions, and that processes are needed when abstractions are to be kept separate. That could be used to neatly define agile and phased development models, the former without intermediate abstractions, the latter braced by architecture ones.
Language, Scope, Purpose
With regard to system engineering, abstractions are first to be defined according to language, scope, and purpose.
Languages: being symbolic, abstractions can only be expressed through languages; and software engineering being about translating users requirements into code, languages can be neatly regrouped into three categories: natural(initial), programming(final), and modeling (in-between):
- Natural languages can be used to describe everything. They rely on semantic abstractions to be interpreted by human speakers.
- Programming languages are specific to software artifacts. They rely on coding abstractions to be interpreted by computers.
- Modeling languages cover all symbolic artifacts. They rely on specifically agreed abstractions to be interpreted by communities’ members or computers.
The same categories also apply to scope.
Scope: core abstractions can be neatly classified with regard to the engineering process:
- Inception: business and organization.
- Completion: software design and implementation.
- Intermediate: systems architectures and functionalities.
Although these categories usually come with the corresponding languages, there can be overlapping, e.g for business logic that can be directly expressed with programming languages. More generally, scoping will depend on project objectives, footprint, and organization: detailed for phased processes that would associate scopes to milestones using differentiated languages and abstractions; seamless for iterative processes that would rely on direct translation from specific to programming abstractions.
Purpose: as engineering processes are not necessarily carried out in a void, different abstractions may have to be considered depending on purpose:
- Governance and regulation: language, scope, and abstractions are set by institutional environment.
- Communication: language, scope, and abstractions are set by enterprise organization.
- Production: language, scope, and abstractions are set by technical environment.
Given language, scope, and purpose, models and abstraction patterns can be formally defined with regard to their content.
Models & Abstractions
Abstractions are symbolic constructs meant to describe relevant features and ignore noisy ones, picking all what is needed, and nothing more. Between simplification (drop irrelevant features) and distinction (factor out relevant ones) they can easily err between lofty generalities and bottomless complexities.
In order to keep them lean and focused, models should be defined with regard to the nature (existing occurrences vs defining conditions) and completeness (partial vs full description of features) of abstractions.
a. Extensional and partial abstractions describe selected features of actual occurrences, e.g:
- Organization charts deal with agents (instances) described with regard to authorizations.
- IT service management (ITSM) deals with processes and services (instances) described from different perspectives: capabilities, resources, availability, etc..
b. Intensional and partial abstractions describe selected features for categories, e.g:
- Business strategies set quantitative or qualitative objectives for market segments and products categories.
- Functional architectures define system capabilities independently of the actual components that will provide them.
c. Extensional and complete abstractions describe all features of actual occurrences, e.g:
- Business process models fully describe actual execution paths.
- Deployment models fully describe how software components are to be run.
d. Intensional and complete abstractions describe all features of types, e.g:
- Business rules fully define what is to be done when some conditions are met.
- Design models fully describe how software components are to be produced.
These four categories provide a comprehensive and formally consistent framework for enterprise architects.
Abstractions in Engineering Processes
As already noted, abstractions must find a path between pointless generalization and boundless intricacy. If the maturity of engineering processes is to be assessed independently of contents, abstractions are to be characterized with regard to level, scope, and objective.
- At enterprise level abstractions are to focus on business and organization models.
- At systems level abstractions are to focus on functional architectures.
- At application level abstractions are applied to software designs.
It ensues a balance between abstractions and reuse on one hand, lean and just-in-time engineering processes on the other hand:
- Lean and just-in-time processes should be considered first, with decisions made at project level and abstraction and reuse limited to implementation.
- Abstractions and reuse may be necessary when cross dependencies cannot be factored out; in that case their actual scope, materialized by models, phases, or milestones, can only be assessed at enterprise level.
That broadly coincides with the alternative between agile and phased development models.
Engineering Footprints
As a working assumption, agile can be set as the default option: lean and just-in-time processes, without stages or intermediate outcomes. Each departing from that cut-to-the-bone scheme should be justified by a clear purpose: governance, communication, or production. Since governance and production concerns can be dealt with without affecting lean and just-in-time capabilities, the focus is to be put on communication needs induced by intermediate stages along the engineering process.
That can be exemplified with MDA’s basic models: Computation Independent (CIMs), Platform Independent (CIMs), and Platform Specific Models (PSMs):
- CIMs: reuse of business processes completely defined independently of supporting systems (green).
- PIMs: reuse of systems functionalities defined independently of business processes and platforms implementations (blue).
- PSMs: reuse of application through code generation targeting specific platforms (brown).
That backbone can then be used to define basic software engineering footprints:
- Typical agile development (top left).
- Phased development of standalone application (top right).
- Agile development for functional patterns (bottom left).
- Agile development for service oriented architecture (bottom right).
Reuse & Abstraction
Reuse can be seen as the ultimate quest of software engineering: always looked for, often approached, sometimes attained, but seldom fully cashed in; as if when at hand the goalposts were eluding. What happens in fact is that since reuse improves with abstraction, each stage seems to offer new possibilities.
That’s the case for models, which can be reused with regard to contents, as illustrated above with MDA’s layers, but also with regard to the level of abstraction, as epitomized by patterns of business functions, systems functionalities, and software designs.
The explicit reckoning of patterns in MDA layers put a new light on models and consequently on transformations: within layers for normalization, refactoring, or optimization; across layers for engineering and code generation.
Transformations & Abstractions
Models transformation is arguably a key MBSE objective, yet it is essentially applied to homogeneous contents at processes last step. At this stage the reuse of design models to generate code (c) is bound to improve the quality of software as well as the lean and just-in-time capabilities of processes without inducing significant overheads at enterprise level. Similarly, rules engines can be used to transform properly formatted requirements into executable specifications (d).
Extending reuse and transformations upstream for heterogeneous contents is more challenging as engineering organization and environments will have to provide for clear and traceable distinctions between:
- Business and organizational contents on one hand (a), functional and technical contents on the other hand (b).
- Two different levels of abstraction: patterns (business, functional, or technical) shared across the enterprise, and applications specific to business units.
Setting up and managing such a supporting environment is to involve significant overheads. More critically, its design and usage is bound to directly impact the quality of software and the maturity of processes for the whole of enterprise.
Conclusion: Patterns as Glue
Understanding models as abstractions put the focus on the two key steps of modeling, namely analysis and design, and on the benefits of associated patterns for the integration of engineering processes.
Further Reading
- EA: Maps & Territories
- Thread: Abstractions
- Thread: Model Based Systems Engineering
- Models Transformation
- Knowledge Based Model Transformation
- Models Transformation & Agile Development
- Languages & Models
- EA & MDA
- The Cases for Reuse
- The Economics of Reuse
- Building a bridge
- Abstractions & Emerging Architectures
- Modeling languages: differences matter
- Alignment: from Entropy to Abstraction