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 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.
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 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.
Reblogged this on Caminao's Ways.