The Blind Men and the Elephant: knowledge in technical architecture

A human’s ability to perceive objective reality is limited. Every person perceives reality subjectively – complexity and information deficits are just some examples of the causes for this. What is considered a challenge for individuals increases when several actors meet. In the Workflow and Operations Division, we concern ourselves with how we can approach the insurance industry’s objective reality. How do we do that? What does an elephant have to do with it? And how exactly does it affect the development of our applications?

The Blind Men and the Elephant

The parable of “The Blind Men and the Elephant” is about a group of blind men – or men in complete darkness – who would like to understand what kind of animal an elephant is. The men spread out around the elephant and begin to examine it by touching a different body part. The man who feels the trunk asserts that “An elephant is like a snake.” The one who examines the tail counters: “No, an elephant is like a rope.” And the one standing at the elephant’s abdomen concludes in turn that “Clearly, an elephant is like a wall.” The others object, an elephant is rather like a tree trunk, a fan or a spear depending on which part of the elephant they are standing next to. Each of the blind men relies on his individual understanding in his description of the elephant. A dispute begins about what an elephant really is and the men cannot agree on who is right and who is wrong. In the parable, the elephant represents objective reality. The resolution of the conflict between the men would be to consolidate and combine the information that each individual is able to contribute in order to come up with an understanding as a group.

What does technical architecture have in common with our elephants?

Although the parable is believed to be more than 3000 years old (unfortunately, when exactly remains unknown), its key message can be applied in many areas. This is also the case for the subject of technical architecture. As part of a company architecture, technical architecture assumes the role of a guiding technical authority between strategy and implementation. A technical architecture is thus a technically complete frame of reference that specifies target functionalities and structural principles, defines expert responsibilities, and outlines communication between specialist systems. As a result, technical architecture must deal with a great deal of information and involved parties. From these elements arise challenges that it shares with our elephant.

Challenge 1: model diversity

A technical architecture has a variety of models that exhibit dependencies among one another. Technical architecture is familiar with domain models, data models, process models, state models, and many others. It behaves as in the case of our elephant – it does not help to only be familiar with and understand one model. It is also not a question of which model is “more correct” or “more relevant” than the other in a respective context. What is decisive is the entirety of the models and the interplay between them.

Challenge 2: class and entity diversity

An additional challenge emerges at a deeper level of technical architecture. As an essential intersection between business and IT, a technical architecture must combine both departments. In order to do this, the departments must specify and take into consideration both elements of the specialty and elements of the level of application. As a whole, a technical architecture therefore contains a great diversity of classes and entities. Among these are business processes, business identities, business rules, business domains, business functions, business services, interfaces, technical objects as well as complete functional data models. Only when a technical architecture contains all of these elements can it achieve the completeness necessary to serve as a long-term, resilient technical reference. With regard to our elephants, it is of central importance that many people with distinct ways of thinking are regularly involved in the entities listed above. The business domains are frequently specified by domain experts, while business processes are frequently defined and documented by the respective process experts. In order to make the objective whole comprehensible, the technical architecture must establish a connection between the classes and entities with regard to technical architecture’s superordinate technical structural principles.

Challenge 3: language and terminologies

Out of a technical architecture’s diversity of elements and involved parties emerges a third crucial challenge: addressing language and terminologies. Beginning with the role of technical architecture as a technically complete reference, the question arises as to with which uniform terminology you should define and outline such a reference. However, it is often the reality that things that have the same technical description are assigned different names depending on the department in which you work or which business unit you are a part of. The technical architecture is asked to consolidate terminology in order to use it to outline the reference and to be able to specify a technically unambiguous language. With this challenge as well, the technical architecture must therefore connect the individual realities – i.e. go around the elephant – in order to achieve an objective reality.

The challenges compel the technical architecture to actively engage with the information and involved parties. In doing so, the focus must be on the information’s connections and dependencies. This is because in order to comprehend the elephant in its entirety, you need a comprehensive specialist knowledge. And knowledge emerges by connecting information.

Ontologies as a suitable tool for technical architecture

Knowing the challenges and structure of knowledge, you need suitable tools and methods for documenting and managing knowledge. One suitable tool for this is an ontology. An ontology outlines a generally recognized understanding of an area of application that all individuals and applications commonly share and use. Formally, an ontology outlines a hierarchical knowledge structure that consists of classes and subclasses that are correlated to one another via specified attributions, and by means of their relationships with one another. By implementing rules, logical conclusions within the structure are possible. But that’s enough of theory for now – how have we implemented this in practice?

We have set up an ontology in the Workflow & Operations Division. Using sem.reasoner, a deductive database for ontologies and a product of our parent company adesso SE, we have developed a frontend web client. With the help of this application, it is possible to model, document, permanently store, and version the technical architecture and its connections and dependencies in a user-friendly way.

Additional benefits of an ontological technical architecture

Our application as well the knowledge it contains are of course not only a means to an end for making the technical architects happy. Rather, we generate immediate additional benefits from it as part of in|sure Workflow’s product development. We transform business processes. What does that mean? Based on the technical architecture’s structure we transform executable workflow codes. For this purpose, our developers built dedicated development kits that convert ontological structures into a workflow implementation. It is the ontology that allows us to take a low-code approach here.

Of course, there is a long list of benefits beyond those involving in|sure Workflow product development. Here are some of them:

• In technical architecture, knowledge can be made available in a way that is suitable for the context and purpose, and can be used as a key technical reference.
• The semantic evaluation of connections and rules (semantic reasoning) enables you to generate an implicit knowledge – i.e. knowledge that is available in the structure, but was not explicitly modeled.
• The implementation of rules enables you to establish a uniform terminology for subject-matter knowledge.

Beginning with these additional benefits, it is conceivable to use the application and contents in various use cases. Three of these applications are:

• Software test: The ontology can be used to create a test, and to plan and inspect technical testing coverage.
• Analyses of dependencies: As part of an examination of dependencies (e.g. changes to data models or interfaces), the knowledge is structured and can be made available according to context and purpose.
• Terminology: Uniformity and reusability of language and documentation can be utilized for glossaries and performance specifications.

Conclusions

The storage and availability of information does not present a challenge. The connections and dependencies are crucial when dealing with knowledge. An ontology can create a commonly recognized understanding of technical architecture and in this way help us with understanding our elephants in their entirety and with strengthening their function as a technical reference. A technical architecture as a knowledge structure is not only a means to an end – it is also a means of generating additional benefits at various levels. Additional benefits that arise in the field of products and processes can have a positive impact on customer experiences and relationships.

And to everyone who is now thinking about their own elephants, seeing a highly complex task before them, and asking themselves how they can convert their information into a structure, we have the following advice to offer: Begin in subbranches and domains, and little by little establish knowledge as a physical resource. Because there is only way to eat an elephant: piece by piece.