Objectives
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 given
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 (or Objectivity) is 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 flights 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 it 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 are not universal
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 cannot 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 not “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 not 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 must be aligned with architecture layers
System engineering cannot be reduced to a simplistic dichotomy of problem and solution as it must solve three very different kinds of problems:
- 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.
As it happens, and not by chance, those layers are congruent with modeling ones on one hand, architectural ones on the other hand.
#10: Enterprise Architecture cannot be equaled 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.
The article and many comments are worth noting and using. I hope a new article acceptable and useful would emerge soon. Then, it should be cited by IIBA, IREB and BCS. That will unify / reconcile the independent approaches of the three standards. Persistence of irreconciled standards actually proves that none of the standards is reliable.
Putchavn,
From a logical point of view fallacies can only be proven false …
The 10 fallacies have been proposed five years ago, yet they stand as they were without significant modification. Since then the Caminao framework has been developed in line with these premises, which in return have been wholly confirmed. That especially the case for the logical foundations of analysis and design models in terms respectively of extensions for the former, intensions for the latter.
https://caminao.wordpress.com/system-engineering/models-perspectives/abse/
And the theoretical confirmation has been accompanied by a pragmatic one as the distinction can be put to use in enterprise architecture.
https://caminao.wordpress.com/enterprise-architecture/ea-maps-territories/
I liked all the ten points of Remey. They are all helpful to recheck observations, assumptions, representations, their consistencies or inconsistencies etc. Then I read the comments of Ron, Terry and others which cautioned me against total acceptance of Remey’s points. We can now formulate more reliable 10 points which make our models and inferences more robust and reliable.
I hope Remey would do that formulation and let us refine it giving examples / non-examples and counter examples. That would be a good and useful outcome of this philosophical and practical write up.
CHEERS…..
putchavn@yahoo.com
04OCT17
A model is never meant to represent reality. It is meant to represent a vision or perception of reality. Newtonian physics, as we now know thanks to Einstein, did not represent reality but only a particular version , inaccurate as it was , of reality.
So it is with software models, business models,and so on.
The purpose is to provide a , hopefully, cohesive and consistent view or perception of the reality that will serve as a basis upon which an actual system can be built or based.
If it turns out to be inaccurate, as was the case with Newton’s model, it is irrelevant because it served it’s purpose at the time.
“The map is not territory”. I’m a modeling adherent; but every day I feel this.
Re: System Engineering “must solve three very different kinds of problems” I encourage you to consider that SE ‘must prescribe how to suppress a problem situation that contains at least three different aspects.’ OBTW, you mention functionality frequently but not OpAvail which is the larger shortfall in operational systems.
I understand your point now to mean that if 3 of us were to independently produce a model of a domain it is unlikely that any of them would be identical. That I agree with, there is no “right” model of a state-of-affairs (although there could be lots of “wrong” ones).
Right. Requirements model cannot be validate in-vivo, and in-vitro validation is pointless. But perhaps models could be proven wrong. I’ve tried to explore the idea of “ghost models” for that purpose.
By ‘representation’ I mean an expression of our understanding. My models at least are always an imperfect expression of my understanding, some worse than others, if they were perfect then I would have to agree that they ‘are’ my understanding.
There again I was never particularly keen on philosophy so probably wouldn’t have made a very good monk or theoretical physicist!
A model that is valid in representing our understanding of the truth, means that the model, within its scope, enables inferences that continue to be congruent with our observations.
When I say ‘our observations’ I mean the majority of rational people.
A model that represents a madman’s world, is probably not going to be shown by observation to be a valid representation of the truth as we know it. Of course people who believed the earth was round were considered deranged at one time, until observations about the inferences of their ‘mad model’ continued to be shown to be correct.
But models don’t represent “our understanding of the truth”, they are “our understanding of the truth”: all knowledge is representation. So, a “valid representation of the truth as we know it” is circular because it can only mean “a true representation of the truth as we know it”.
About the relationships between models, knowledge and truth I like the article by Davis, Shrobe, and Szolovits (see Selected readings or the post about Knowledge Architecture.
Rémy, that’s why it is the truth ‘as we know it’!
But it’s a circular definition of truth in models …
Ron,
When you write “the model is a sound representation of the truth as we know it”, you’re falling in some circular reasoning.
Models are symbolic constructs meant to represent the world through the lenses of our contexts and concerns. They are all we know about the world, our only knowledge.
Rémy, my view is somewhat different.
To create, modify or engineer systems, start with an exploratory model of the part or aspect of the world that is of relevance.
Models for expressing ‘what’ versus ‘how’ may be but aren’t necessarily different, rather their usage typically evolves through different phases. Initially as a scratchpad for exploring the problem, or the requirements, then for stating the problem or requirements, or whatever, then as a blueprint for specifying how the changes are to be implemented. The phases are rarely distinct, and I suspect the less distinct the better, particularly as usually different parts of a problem/requirements evolve at different rates.
Ok, empirical falsification is pretty fundamental to scientific thinking but I don’t understand your point about models. Good ones can be used to infer facts that can then either be observed as true, indicating that the model is a sound representation of the truth as we know it, or observed as false, indicating that it is flawed in some respects.
What I do see though (particularly in requirements analysis) is descriptive models that cannot be used to infer anything. In which case it is impossible to prove or disprove whether they represent any kind of truth beyond local consensus. Is that your point?
Ron, I’m not sure about engineering models used to represent the world, that would belong to science. As far as engineering is concerned, descriptive models are used for requirements, and prescriptive ones for artifacts, both clearly based (biased) on (by) contexts and concerns. As for truth in models, I’m only following K.Popper position about empirical falsification.
‘The mother of all fallacies is to think that models can describe some real-world truth.’
It depends on what is meant by ‘truth’.
In systems engineering, models are used to represent the world as observed and to express and explore ‘a’ truth that we want to create.
Generally, I agree with Nick, that some supporting examples would help people to better understand the issues that you are attempting to expose.
I don’t ask anybody to believe anything. Those are arguments open to refutation. Some find them convincing and corresponding to their own experience. Others don’t. But counter arguments and examples are welcome.
Your experience tells you that these are “fallacies,” correct? What makes them fallacies? Is there any anecdotal evidence or case study or even a set of blog posts where professionals tried these techniques and they failed, or is this list based on your experience only? Can you give us, your readers, a reason to believe that your experience is specifically note-worthy?
GOLD…