Symbolic Representations
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:
- What is to be represented.
- Who is to use the representations.
- When are the representations to be used.
- How objects and activities are to be represented.
- How are representations to be implemented.
All examples are taken from ancient civilizations in order to put the focus on generic problems of symbolic architectures, disregarding technologies.
Representation Patterns
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.
Symbolic representations of objects & activities
Along the representation perspective, patterns must characterize how actual objects and processes are associated to their symbolic counterpart.
Engineering Processes
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.
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.
Architecture Driven Modelling takes source from OMG’s Model Driven Architecture. More generally, it follows the well accepted distinction between requirements, analysis, and design, and can be implemented with OMG’s Unified Modeling Language.
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.
Taking inspiration from the Capability Maturity Model Integration (CMMI), the benefits of architecture driven modelling can be identified for product, project, and process areas:
- 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.
I never knew there is detailed blog exists on Wordrpess. Way to go. Nice work. Will be waiting for further posts.
Rémy, most interesting, particularly from a personal perspective, as by chance, over the years, I’ve both formally studied and practiced in almost all of the areas that the Stamford program mentions, although without a unifying concept such as ‘symbolic systems’.
Although I had figured out a common thread as as something like ‘semantic architecture’, which few others, maybe some of us that have worked in an area like conceptual data modelling would truly understand, particularly the power and huge practical relevance to business enterprises. ‘Symbolic systems’ I think describes this better.
I will spend some time on your work and provide further, hopefully constructive comments.
I might also try to get in touch with some of the guys at Stamford.
Ron, as a matter of fact, this work is about what Stanford University calls “Symbolic Systems”. It’s an extremely powerful concept, with a much more comprehensive and coherent scope than “Enterprise” or “Organization”.
Rémy, so if the work is primarily concerned with symbolic representations of enterprises, I’d like to suggest that this is said and that ‘enterprise’ is defined up front.
Presumably you are focusing on organisations formally established to produce some kind of value?
But I guess that’s getting into the definition of enterprise.
Ron, almost: while the concepts may have a broader scope, the focus remains on enterprises.
Rémy (Caminao), Ok, I understand the broad application of symbolic representation, and also the frustrations of being pigeon holed (!), so will assume, unless yourself or further reading indicates otherwise, that the scope of the current work is general systems modelling, including social, business, organisation, boats, planes, software applications etc. Is that fair?
Ron, I’m aware of the problem and the “About” page is probably not the best entry point (see “Overview” for that).
Yet, the distinction between “systems” in general and “symbolic systems” is becoming less and less relevant, and the divide between “symbolic systems” and computing ones has almost disappeared.
Rémy (Caminao), Ok, understood that you discuss ‘systems’ elsewhere, but that requires people to work through more of the site so that they can understand (hopefully) its goals. My first impression reading ‘about’ is that the work is dealing with systems in general, which I don’t think is your intended scope.
Best wishes, Ron
Rémy (Caminao), what an extensive, interesting and unusual work. I am trying to understand the scope of the area that you are addressing.
Above you define this as ‘Architecture Driven System Modelling’, so by ‘system’ do you mean ‘software system’, and if so does this exclude hardware?
In any case I suggest that it would help to avoid confusion if you were to say what is in and out of scope, particularly as many of the concepts and tools discussed have wider applicability than computer software.
Best wishes
Ron
Thanks Ron,
Systems are detailed in several pages (e.g architectures) as a combination of software components (symbolic capability), agents (symbolic capability, responsibility), and devices (non symbolic).
I have to agree with William Cook on this.
First off, there is no reference to who you are. Why are you an qualified person to discuss the topic? What training to do you have? Do you have the credentials to discuss this material? If so, how would I know? Am I supposed to accept you on faith?
The fact that another person asked you to identify yourself but you chose not to speaks volumes about your credibility.
Secondly, your writing style is clear, but the content is borderline nonsense. You draw conclusions with no evidence or even logic, relying only upon a few observations by a potentially biased observer. The site is not science… it is a religious treatise.
Note, if you have based your work on a “limited number of concepts with […] unambiguous definitions” then I suggest that you link to those definitions in the articles that use those specific concepts.
What a strange and discomfited comment …
Some “qualified” persons are just self-appointed, others try to convince through their arguments; I belong to the latter category as ten of thousands of readers can testify, what about you ?
Regarding my identity, did you try Google ?
As for contents, I’m aware it’s cutting edge and call for open-minded readers.
The Google suggestion was a good one.
For others trying to find out who the author is, it is Remy Fennader. He is a graduate of Université Pierre et Marie Curie (Paris VI) (world-class research university) and the Hebrew University with Master’s degrees in Economics and Computer science.
He has spent most of the last 30 years as a consultant, about half of that in a solo IT consulting career doing business under the name ‘Caminao’ presumably in the Paris vicinity. He has never held a management or strategic role that I can discern, although I cannot see his client list or list of engagements. Remy is a frequent contributor to various groups on the LinkedIn social networking site.
Given the strength of his credentials and experience, it is puzzling why Remy would not advertise his association with this well organized blogging site.
— Nick
Nick, Thanks. It’s Fannader, and you missed the 3 books I published in French. Remy.
I apologize for the misspelling Remy, and for missing the books. I didn’t see links to that material in my rather quick search. You are a talented individual with decades of valuable experience… why not put your name on every page? I literally could not find your name on ANY of the pages on this rather voluminous site!
I understand the decision to place your opinions on your own site. I do the same. I just don’t understand the decision not to let the world know that these opinions belong to a well-educated, experienced, and well-respected member of the software engineering community.
Your site reads like a textbook. When you suggest specific methods and taxonomies, it would be good to give the reader some basis for believing that your methods and taxonomies have proven useful somewhere (if they have). I’m sure you would not talk to a business person without specific references to actual results. Why are software engineers different?
That said, it’s an interesting site.
— Nick
I have tried reading your articles for a while. I have 30 years of software development and programming language research experience. I find the writing here to be full of buzz-words. It makes lots of connections without really explaining them. It seems to be systematic (in that it often breaks concepts down into sub-concepts or related concepts) but there is no justification why these particular concepts are chosen. In the end I just find it frustrating. Why aren’t there more comments? Maybe the ideas are too fuzzy.
I have to thank you for your perseverance but feel sorry for your disappointment. I’m aware of the difficulty of introducing a new paradigm, but, as you noticed, the proposed approach is systematic and (you missed that point) built on a limited number of known concepts with redacted but unambiguous definitions.
As for comments, there are still just a few but most of them are as encouraging as your is disparaging.
Excellent!
interesting blog.really.
Who is the author? why didn’t find it.