sunevang

The V-model provides a structured approach for managing the development of features and modules within both new and existing IT systems. It offers a visual representation that reveals the level of effort required to progress from conceptualization to implementation. While not delving into all the intricacies of the V-model, it presents the essential conceptual leap required to distill the complexity of reality into the encapsulated version represented by an information system. However, comprehending certain aspects of the V-model is necessary to reach to get to this point.

Left leg: Reality to development

We start in the top left corner of the diagram with what in the diagram is called “Concept of Operations” – which is what I also would call “Context”. This includes use cases, usage volumes and boundary condition – like for instance given integrations, legal requirements and guidelines for look and feel and data and functionality access.

The context of operation might be articulated in a mixed bag of documents, examples, use case description and aspiration as well as language styles. Hence to get manageable we synthesize it all into requirements where we now expect logical break down and grouping and precise definitions.

At the same level in the diagram, we observe the term architecture. This is a crucial yet subjective task, focusing on identifying the logical structures within the requirements or problems, and analyzing how the IT system’s model can be expanded to address the issue. This is truly the crux of the matter – when addressing the business problem, we may employ various terminologies, business entities, analogies, and diagrams to articulate our objectives. However, at this stage, it is essential to scrutinize the existing and potential data structures of the IT system (the data model) and make an informed estimation about the necessary extensions to resolve the business problem and, consequently, meet the requirements.

The architecture decisions often involve addressing conceptual issues, outlining the solution’s structure, and detailing how the current data model can be expanded. However, it is also crucial to provide a detailed specification for the precise implementation of changes within the code base, configurations, and data store. This detailed design, represented at level 3 in the diagram, results in specifications that describe the system changes.

We have reached the final stage of the V-model, where we initiate the process of modifying the system. Moving forward, we will forego further elaboration on the V-model and concentrate on our main point.

The conceptual leap

If we revisit the activities of the left leg of the V-model we see that we start at the top with business (or broader context of operation) and end with system changes. And this is the conceptual leap – mapping our daily rich understanding of the real world into the restricted modelling and language capabilities of an (IT) system. And, this is important; IT-systems are simplified and limited version of the real world, that we map our business concepts, process steps and data fields into. Therefore, this is why the architecture work is important – as the architect needs to insure that the business and technical world connects correct here. Hence, the architect needs to understand both the business and modelling in the system.

Data and Reality

Try and have a look at this quote from William Kent the author of “Data and Reality”:

People are awed by the sophistication and complexity of computers, and tend to assume that such things are beyond their comprehension. But that view is entirely backwards! The thing that makes computers so hard to deal with is not their complexity, but their utter simplicity. The first thing that ought to be explained to the general public is that a computer possesses incredibly little ordinary intelligence. The real mystique behind computers is how anybody can manage to get such elaborate behavior out of such a limited set of basic capabilities. The art of computer programming is somewhat like the art of getting an imbecile to play bridge or to fill out his tax returns by himself. It can be done, provided you know how to exploit the imbecile’s limited talents, and are willing to have enormous patience with his inability to make the most trivial common sense decisions on his own.

https://www.bkent.net/Doc/darxrp.htm

For me this statement emphasizes the point from last section regarding the leap from going from a real world free form articulation to a limited set of structures that must be able to handle the requirements.

Further Reading

Wikipedia:

https://en.m.wikipedia.org/wiki/Data_modeling

https://en.m.wikipedia.org/wiki/Data_model

These are quite elaborate articles and hence might not be the practitioners best aid. In my own work as a software and solution architect I have focused on the conceptualization of the problem/solution – with a focus on the striking the balance of generalizing entities on the one hand while at the same time ensuring that each entity has a meaningful role in the model. You can read more about that here.