“The only reason for time is so that everything doesn’t happen at once.”
Time and Events
Time is what happens between events. Without events there will be no time, and each event introduces its own time-scale.
Time is what persists of events (S.Dali)
From the (limited) perspective of system requirements, time is the scale used to position business processes, i.e the execution of business activities. And since systems are meant to support business processes, time must be set by business events before being measured by shared devices.
As a counter intuitive corollary, time is only to run with business: if nothing relevant is meant to happen between two events there is no need of time and both events can be coalesced into a single one. Conversely, if nothing is allowed to happen between two events the system will have to dealt with them in real-time.
Like events, time is necessarily local since physical devices must sit on location, possibly mobile ones; once set by some triggering event, time can only be measured by a single clock and therefore cannot be shared across distributed systems.
Time is local but one can take it along
Moreover, along with its measuring device, time is also an artifact built to meet specific concerns. That can be very useful if activities are to be managed in isolation. Like different objects managed within different address spaces, different activities could be time-stamped and controlled by different time scales.
Time scales can be designed on purpose
Being set by independent clocks, each built to answer it own concerns, the symbolic representations of activities could then be fenced off so their execution will appear as impervious to external events. Yet, if and when architectural constraints are to be properly identified, execution units will have to be timed along some shared time scale. More generally, distributed activities, being executed along different time scales, would have to be synchronized through a logical clock using its own time scale. Another solution is to synchronize physical clocks using a standard protocol like the Network Time Protocol (NTP).
Distributed activities have no time of their own
Along that reasoning, real-time activities can only be supported locally: if events must occur simultaneously within and without the system, i.e nothing is supposed to nothing is supposed to happens between changes in actual objects and their symbolic representation, that can only be achieved under the control of a single system.
Models are representations and as such they are necessarily set in perspective and marked out by concerns.
Model, Perspective, Concern (R. Doisneau).
Depending on perspective, models will encompass whole contexts (symbolic, mechanic, and human components), information systems (functional components), software (components implementation).
Depending on concerns models will take into account responsibilities (enterprise architecture), functionalities (functional architecture), and operations (technical architecture).
While it may be a sensible aim, perspectives and concerns are not necessarily congruent as responsibilities or functionalities may cross perspectives (e.g support units), and perspectives may mix concerns (e.g legacies and migrations). That conundrum may be resolved by a clear distinction between descriptive and prescriptive models, the former dealing with the problem at hand, the latter with the corresponding solutions, respectively for business, system functionalities, and system implementation.
Models as Knowledge
Assuming that systems are built to manage symbolic representations of business domains and operations, models are best understood as knowledge, as defined by the pivotal article of Davis, Shrobe, and Szolovits:
Surrogate: models provide the description of symbolic objects standing as counterparts of managed business objects and activities.
Ontological commitments: models include statements about the categories of things that may exist in the domain under consideration.
Fragmentary theory of intelligent reasoning: models include statements of what the things can do or can be done with.
Medium for efficient computation: making models understandable by computers is a necessary step for any learning curve.
Medium for human expression: models are meant to improve the communication between specific domain experts on one hand, generic knowledge managers on the other hand.
What You Think Is What You Get
Whereas conventional engineering has to deal with physical artifacts, software engineering has only symbolic ones to consider. As a consequence, design models can be processed into products without any physical impediments: “What You Think Is What You Get.”
Yet even well designed products are not necessarily used as expected, especially if organizational and business contexts have changed since requirements capture.
Models and Architectures
Models are partial or complete descriptions of existing or intended systems. Given that systems will eventually be implemented by software components, models and programs may overlap or even be congruent in case of systems made exclusively of software components. Moreover, legacy systems are likely to get along together with models and software components. Such cohabitation calls for some common roof, supported by shared architectures:
Enterprise architecture deals with the continuity of business concerns.
System architecture deals with the continuity of systems functionalities.
Technical architecture deals with the continuity of systems implementations.
That distinction can also be applied to engineering problems and solutions: business (>enterprise), organization (supporting systems), and development (implementations).
On that basis the aim of analysis is to define the relationship between business processes and supporting systems, and the aim of design is to do the same between system functionalities and components implementation.
Whatever the terminology (layers or levels), what is at stake is the alignment of two basic scales:
Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
If systems could be developed along a “fire and forget” procedure models would be used only once. Since that’s not usually the case bridges between business contexts and supporting systems cannot be burned; models must be built and maintained both for business and system architectures, and the semantics of modeling languages defined accordingly.
Languages, Concerns, Perspectives
Apart for trivial or standalone applications, engineering processes will involve several parties whose collaboration along time will call for sound languages. Programming languages are meant to be executed by symbolic devices, business languages (e.g B.P.M.) are meant to describe business processes, and modeling languages (e.g UML) stand somewhere in-between.
As far as system engineering is concerned, modeling languages have two main purposes: (1) describe what is expected from the system under consideration, and (2) specify how it should be built. Clearly, the former belongs to the business perspective and must be expressed with its specific words, while the latter can use some “unified” language common to system designers.
The Unified Modeling Language (UML) is the outcome of the collaboration between James Rumbaugh with his Object-modeling technique (OMT), Grady Booch, with his eponymous method, and Ivar Jacobson, creator of the object-oriented software engineering (OOSE) method.
Whereas UML has been accepted as the primary standard since 1995, it’s scope remains limited and its use shallow. Moreover, when UML is effectively used, it is often for the implementation of Domain Specific Languages based upon its stereotype and profile extensions. Given the broadly recognized merits of core UML constructs, and the lack of alternative solutions, such a scant diffusion cannot be fully or even readily explained by subordinate factors. A more likely pivotal factor may be the way UML is used, in particular in the confusion between perspectives and concerns.
Languages are useless without pragmatics which, for modeling ones means some methodology defining what is to be modeled, how, by who, and when. Like pragmatics, methods are diverse, each bringing its own priorities and background, be it modeling concepts (e.g OOA/D), procedures (e.g RUP), or collaboration agile principles (e.g Scrum). As it happens, none deals explicitly with the pivotal challenges of the modeling process, namely: perspective (what is modeled), and concern (whose purpose).
Processes can be designed, assessed and improved by matching development patterns with development strategies.
Matching Concerns and Perspectives
As famously explained by Douglas Hofstadter’s Eternal Golden Braid, models cannot be proven true, only to be consistent or disproved.
Depending on language, internal consistency can be checked through reviews (natural language) or using automated tools (formal languages).
Refutation for its part entails checks on external consistency, in other words matching models and concerns across perspectives. For that purpose modeling stations must target well defined sets of identified objects or phenomena and use clear and non ambiguous semantics. A simplified (yet versatile), modeling cycle could therefore be exemplified as follows:
Identify a milestone relative to perspective, concern, and architecture.
Select anchors (objects or activities).
Add connectors and features.
Check model for internal consistency.
Check model for external consistency, e.g refutation by counter examples.
Whereas it is based upon well known concepts and accepted standards, the Caminao approach entails a new modeling perspective which calls for change of habits, mostly at requirements level. The objective here is to experiment some Proof of Concept by contriving requirements on-line along the Caminao path.
For that purpose the proposed experiment makes use of four principles:
Crowd-sourcing: except for Caminao stereotypes, understanding do not come from a special expertise or best-practices but is built on collective wisdom.
Iterations: stakeholders and analysts are circling topics until they agree on clear and unambiguous pictures.
Illustrations: requirements begin as expectations, as such they should be best captured through pictures before being analyzed through models.
Assertions: requirements are meant to translate into commitments, hence, associated models should be settled by explicit constraints and expressions.
On that basis stakeholders will introduce their requirements as illustrations, analysts will try to translate them into models which, after being accepted by stakeholders, will subsequently be decorated by assertions.
Requirements rings are managed through the G+ Caminao Rings page.
In order to submit a project, candidate stakeholders must belong to the circle of fellows.
Fellows stakeholders may submit projects by creating their own G+ pages and circles and identifying them with the Caminao G+. A new page is created for each project, to be matched with the fellow G+ circle.
Fellow analysts propose models capturing all or parts of illustrated requirements.
Stakeholders may accept, reject, or hold back their decision. Refusals can be commented but reservations can only be qualified with additional illustrations.
Once approved models may subsequently be fleshed out with expressions, constraints and rules.
Fellow analysts can propose two types of models:
Horizontal models describe individual artifacts and their connections.
Vertical models are anchored to single artifacts and focus on their partitions and inheritance relationships.
While it’s recommended to walk along basic UML conventions, models may include any kind of artifacts providing they are qualified by Caminao stereotypes for actual or symbolic objects and activities, roles, or events.
Stereotypes for containers use the same principle for organizational units (110) physical locations (121), physical executions (141), business domains (120), business activities (140).
The semantics of connectors (association, flow, transition, or channel) can remain implicit and defined by context. They may be stereotyped using standard set operators.
By convention, objects, events and roles are labelled with singular nouns, activities use infinitive verbs, and processes use present progressive ones. Containers are named with plurals.
Who’s in the Loops
Four types of players may appear in requirements loops:
Stakeholders (one by project) set the context and objectives with pictures, photos or drawings. Textual descriptions are not allowed. Stakeholders accept or reject artifacts.
Users and business analysts add to the stakeholder requirements using the same media (no texts); they also may qualify model artifacts with formal expressions, constraints or rules.
System analysts suggest artifacts.
Architects (one by project) accept or reject qualifications on artifacts.
Mind Your Words
Language and meanings may be baffling bedfellows, as what is said is not necessarily what is meant. As a boost to requirements transparency, a simple gizmo may be used by players to speak their mind, for their interlocutor (talking bubble) or only for the audience (thinking bubble).
Price Your Words
Assuming clear understanding and good faith, customers and providers must agree on a price, and for that purpose they must align their respective expectations and commitments.
Expecting to take advantage of business opportunities at a given time, customers define system requirement along a black box perspective; in return, providers analyze those requirements along a white box perspective and make an estimate of cost and duration. Their respective expectations are consolidated and commitments made, customers regarding payment, provider regarding delivery.
As far as customers are concerned, success is measured by the return on investment (ROI), which depends on cost, quality, and timely delivery. Providers for their part will design the solution, develop the components, and integrate them into targeted environments. Narrowly defined, their success will be measured by costs. Those concerns may be played along a non-zero sum game:
Customers assess the benefits (a) to be expected from the functionalities under consideration (b).
Providers consider the solutions (a) and estimate their costs (b).
Customers and providers agree on functionalities, costs and schedules (c).
Hence, while stakes are clearly conflicting on costs, there is room for collaboration on quality and timing, and that will bring benefits to both customers and providers.
Square the Rings
Even for standalone applications, it’s safe to assume that requirements will have to take into account external factors and constraints. Since those requirements will usually be managed by different organizational units, they must be sorted out upfront:
Non functional constraints deal with performances and resources.
Cross functional requirements deal with system functionalities shared by different business processes.
Application specific requirements deal with system functionalities supporting a single business process.
Those rings are used to organize projects according the requirements architectural footprint and associated responsibilities.
Caminao aims to chart all worlds of system models, drawing maps with a kernel of the UML, based upon a reasoned conceptual framework.
Set from a comprehensive and objective survey of system functionalities and architectures, using standard notation applied to unambiguous concepts, those maps should provide all-weather guidance to system modellers, whatever their bearings or creed.
Models, Architectures, Perspectives (MAPs)
Of all industrial artifacts, software components are the only ones that can be fully built from models. As a consequence, charting comprehensive and reliable maps should not only be feasible but also highly beneficial.
Caminao maps are built from models, architectures, and perspectives:
Models set the stages, where targeted artifacts are defined depending on concerns.
Topography put objects into perspective as set by stakeholders situation: business objectives, system functionalities, system implementation.
Concerns and perspectives must be put into context as defined by enterprise, functional or technical architectures.
The aim of those maps is to provide reasoned tools for seasoned modellers, helping them in setting milestones, planning journeys, and appraising itineraries.
Milestones are about sequences: they are necessary whenever expectations and commitments are set across different organizational units.
Appraising is about processes: given sound and objective metrics, tasks traceability to outcomes, and projects built alongside, roadmaps can be turned into development patterns depending on capabilities assessment.
Maps are to be drawn using a standard notation, and for that purpose Caminao uses a kernel of OMG’s Unified Modeling Language.
UML# (for “charpente”, supporting structure in French), is built on a core of UML syntactic constructs, using its stereotyping mechanism to define semantic qualifiers set along functional layers on one hand, OMG’s Model Driven Architecture on the other hand.
UML# objective is therefore not to be a substitute to UML but rather a complement dedicated to requirements and analysis, without affecting continuity with design and implementation models.
Neither maps nor languages are meant to convey any guidance about course or discourse. Hence, modeling languages have nothing to say about what is to be represented and how it should be done. For that purpose a reasoned understanding of system functionalities and architecture is required.
Curiously, while core concepts are already at hand, most of methodologies are either aimed at system design, or lean on fallacies about what analysis models represent.
Caminao ultimate objective is therefore to bridge the conceptual gap between functional requirements and system analysis, bringing both semantics under a common roof. To that end, some principles are to be carried through:
Comprehensive scope: concepts must deal with all and every configuration, without assuming any restriction about functional requirements.
Closed set of concepts: all descriptions of system functionalities and architecture must be upheld by a limited and finite number of concepts.
Thorough and reasoned understanding: all stereotypes are to be unambiguously defined using formal expressions built from core concepts.
No expertise or best practices: maps must support all ventures and befit every methodological inclinations. As a consequence concepts and stereotypes must remain neutral and free of any preference or precedence.
Eventually, that should open a new perspective to model driven engineering by consolidating model layers around functional architectures.
Taking a cue from Ivar Jacobson (“The road ahead for UML“), some modularity should be introduced in order to facilitate the use of UML in different contexts, organizational, methodological, or operational.
Three main overlapping objectives should be taken into consideration:
Complexity levels: the language features should be regrouped into clearly defined subsets corresponding to levels of description. That would open the way to leaner and fitter models.
Model layers: the language constructs should be re-organized along MDA layers if models are to map stakeholder concerns regarding business requirements, system functionalities, and system design.
Specificity: principled guidelines are needed for stereotypes and profiles in order to keep the distinction between specific contents and “unified” ones, the former set with limited scope and visibility, the latter meant to be used across model layers and/or organizational units.
As it happens, a subset of constructs centered on functional architecture may well meet those three objectives as it will separate supporting structures (“charpentes” in french) from features whose specifications have no consequences on system architectures.
State of The Art
Information technologies progress crab-like, the hardware leg striding forward with Moore Law, and the software leg crawling on practices, with rare real leaps like relational (more than 30 years ago) and object (10 years later) technologies. The adoption of UML as a modeling standard at the end of the last century could have spurred a new start of innovation for software engineering; instead, its protracted diffusion and shallow or biased usage suggest a latent factor behind the limping progresses of software technologies. The absence of clear advances for the last 20 years, despite the undisputed soundness and cogency of available concepts and tools, may hint at some basic focusing error regarding what is to be considered.
Whereas object oriented approaches to software analysis and design are now broadly accepted, there is no consensus regarding the nature of targeted objects; more precisely, there is no explicit distinction between symbolic objects and processes on one hand, and their operational counterparts on the other hand. Such a confusion can be observed at different levels:
Requirements: the perspective is limited to a dual distinction between problem (what) and solution (how) spaces. That approach is much too simplistic as it overlooks the functional dimension, namely how a software solution (nothing more than a piece of code) is to be used within operational systems (a distributed set of agents, devices, and symbolic machines).
Time-scales: when models are used (that’s not always the case), operational contexts (business objects and processes) are captured at inception time and their description frozen as snapshots until further notice. This lack of synchronized context and system models rules out any explicit management of systems life-cycles and transformation.
Model contents: the aim of model driven (or based) approaches is to define development flows in terms of models and organize engineering processes accordingly. But that may not be possible if the semantics of model contents are not properly differentiated between modeling stages, the consequence being a lack of principled support for model transformation. That point is best illustrated by the perplexing debate about executable models and models as code.
Processes: the aim of development processes is to manage concerns set by different stakeholders, based upon different rationales, and subject to changes along different time-frames. If those concerns cannot be specified independently, the design and assessment of engineering processes will lack a sound basis.
Yet, since all those problems stem from the same blurred focus, they may also be deal with a shift in modeling paradigm. Moreover, that shift could be especially productive given the availability of the conceptual constructs associated with object oriented approaches and UML. For that purpose it is necessary to clarify model purposes and customize the language accordingly.
Two Legs and a Bridge
From a general perspective, and beyond lexical controversies, models and architectures should be defined along two parallel scales:
Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
Caminao is focused on models as bridges between business goals and system implementation. While simple or standalone applications may often be developed without mediation, that’s not the case for shared applications deployed across distributed system with independent life-cycles.
Enterprise architecture: business requirements are not necessarily expressed with modelling languages.
Functional architecture: functional (aka system) requirements should be expressed with modelling languages.
Technical architecture: non functional requirements are not expressed with modelling languages.
Grammars and Semantics
Whatever the editor, graphical or otherwise, models are built from expressions according to grammatical rules. Some rules are meaningless as they only define what is possible, i.e how to form correct expressions; others are mixed as the associated constructs may also convey some meaning.
In any case, those rules have to deal with three types of considerations: lexical, syntactic, and semantics.
Legitimate items, words or symbols, are defined by the lexical layer.
The way lexical items can be used to build well-formed expressions is defined by syntactic rules.
Finally, language semantics define the relationships between expressions and targeted contexts.
The Unified Modeling Language (UML) is the outcome of the collaboration between James Rumbaugh with his Object-modelling technique (OMT), Grady Booch, with his eponymous method, and Ivar Jacobson, creator of the object-oriented software engineering (OOSE) method. Whereas the Three Amigos did a pretty good job in consolidating the best of different approaches, UML 1.x was not built from scratch along the ideal template: instead of drawing clear lines between lexical, syntactic, and semantics layers, constructs were first established along semantic perspectives, namely static (aka structural) and dynamic (aka behavioral) views. Formal syntactic definitions of qualifiers and expressions came almost as an afterthought.
As is often the case when ambitious objectives set by visionaries are taken over by committees, things certainly didn’t improve with UML 2.x. Having to face a growing complexity without a solid grammatical ground, the OMG turned simultaneously to abstraction and specificity: on one hand Meta-Object Facility (MOF) is meant to bypass classical grammars descriptions by bringing every modeling language under a single meta-language roof; on the other hand stereotypes and profiles provide a very practical way to tailor UML to specific domains and organizations.
But those options have driven UML into opposing directions: on one hand meta-models do nothing to improve UML capabilities and usability as their aim is mainly to enable some interoperability between tools providers; on the other hand stereotypes and profiles push UML users into specific corners, which is not what a “unified” modelling language is supposed to do. As a consequence, more than 15 years since it became a standard, UML is still not widely accepted as such; and when it is used, it is all too often on a very limited scope, or for very specific purpose, or without much of methodology.
Lean, fit, and Sharp, as in “Charpente”
The proposed approach takes advantage of UML stereotyping mechanism to reorganize the semantics around a kernel of simple syntactic constructs dealing with:
Whereas the design side of software engineering has made significant advances since the introduction of Object Oriented approaches, thanks mainly to the Gang of Four and others proponents of design patterns, it’s difficult to see much progress on the other (and opening) side of the engineering process, namely requirements and analysis. As such imbalance creates a bottleneck that significantly hampers the potential benefits for the whole of engineering processes, our understanding of requirements should be reassessed in order to align external and internal systems descriptions; in other words, to put under a single modeling roof business objects and processes on one hand, their system symbolic counterparts on the other hand.
Given that disproving convictions is typically easier than establishing alternative ones, it may be necessary to deal first with some fallacies that all too often clog the path to a sound assessment of system requirements. While some are no more than misunderstandings caused by ambiguous terms, others are deeply rooted in misconceptions sometimes entrenched behind walled dogmas.
Hence, to begin with a tabula rasa, some kind of negative theology is required.
#1: Facts are not what they used to be
Facts are not given but observed, which necessarily entails some observer, set on task if not with vested interests, and some apparatus, natural or made on purpose. And if they are to be recorded, even “pure” facts observed through the naked eyes of innocent children will have to be translated into some symbolic representation. Nowadays that point is taking center stage due to the onslaught of big data (see Data Mining & Requirements Analysis).
#2: Truth and Objectivity are not to be found in Models
The mother of all fallacies is to think that models can describe some real-world truth. Even after Karl Popper has put such a fallacy to rest in sciences more than half a century ago, quite a few persist, looking for science in requirements or putting their hope in abstraction. Those stances cannot hold water because models necessarily reflect business and organizational concerns, expressed at a given time, and set within specific contexts. Negative theology provides an antidote: if a model cannot be proven as true, at least it should be possible to check that it cannot be falsified, i.e is consistent with contexts and concerns.
#3: Requirements are not meant to be “Engineered”
Taking for granted that all requirements can be directly “engineered” is to overlook the role of architectures between stakeholders and users expectations on one side, systems capabilities on the other side. Such assumption is to blur the respective responsibilities of business and system analysts, and induces the latter to second-guess the former. What may be a practical shortcut for standalone applications becomes a major risk factor when robust and stable architecture capabilities are to support constant adaptations to changing business needs.
#4: Objects can be found everywhere
Object Oriented approaches are meant to deal with the design of software components, not with business objects and organization. While it may be useful to look at business contexts from an OO perspective, there is no reason to assume that business objects and processes can be analyzed using the semantics of software design: hope is no substitute for methodology.
#5: “Natural” languages can be applied to every domain
Except for plain applications (calling for trivial solutions), significant business domains rely on specific and often very formal languages that will have to be used to express requirements. That may be illustrated with examples from avionics to finance, not to mention law. When necessary, modeling languages are to provide a bridge between specific (domains) of and generic (software) descriptions.
#6: Business concerns are “Conceptual”
Whatever the meaning of the adjective “conceptual”, it doesn’t fit to business concerns. Hence, trying to bring requirements to some conceptual level is a one way ticket to misunderstandings. Business concerns are very concrete indeed, rooted in the “here” and “now” of competitive environments, and so must be the requirements of supporting systems. Abstract (aka conceptual) descriptions will be introduced at a later stage in order to define the symbolic representations and consolidate them as software components.
#7: Model is Code
If models were substitutes for code, or vice versa, that would make software engineering (and engineers) redundant. Surprisingly, the illusion that the information contained in models is the same as the one contained in programs (and vice versa) has sometimes wrongly taken from the Model Driven Engineering paradigm, despite a rationale going the opposite way, namely toward a layered perspective with models standing for abstractions of systems and programs.
The same fallacy is also behind the confusion between modeling and programming languages. That distinction is not arbitrary or based on languages peculiarities, but it fulfills a well-defined purpose: programming languages are meant to deal with software abstractions, while modeling languages take the broader perspective of systems.
#8: “Pie-in-the-sky” Meta-models
As any model, a meta-model is meant to map a concern with a context. But while models are concerned with the representation of business contexts, the purpose of meta-models is the processing of other models. Missing this distinction usually triggers a “flight for abstraction” and begets models void of any anchor to business relevancy. That may happen, for example, when looking for a meta-model unifying prescriptive and descriptive models; having very different aims, they belong to different realms and can never be joined by abstraction, but only by design.
#9: Problem/Solution Spaces
System engineering cannot be reduced to a simplistic dichotomy of problem and solution as it must solve three very different kinds of problems, with their respective contexts, stakeholders, and life-cycles:
Business ones, e.g how to assess insurance premiums or compute missile trajectory.
Functional ones, how the system under consideration should help solving business problems.
Operational ones, i.e how the system may achieve targeted functionalities for different users, within distributed locations, under economic constraints on performances and resources.
#10: Enterprise Architecture is equivalent to Systems
Enterprise architecture is often confused with IT systems, which induces misguided understandings of business architecture. The key confusion here is between architectures, supposedly stable and shared, and processes, which are meant to change and adapt to competitive environments. But managing the dynamic alignment of assets (architecture capabilities) and supported business processes is at the core of enterprise architecture.
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 (aka analysis, aka functional) patterns, i.e generic descriptions of system functionalities independently of both their business meaning and system counterpart.
Beyond lexical controversies, that could be achieved with models and architectures defined along two parallel scales:
Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
Interactions could be also symbolized with the “M” of model:
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.