Total Concepts

The architect, in his ‘way of thinking’, needs to reserve an important role for conceptualizing problems from a conceptual level. When the architect has taken stock of sufficient concepts and selected a possible solution, Dragon1 suggests viewing this as an opportunity to create a total concept. By working with a total concept, the architect can communicate better with the client and explain why he chooses to integrate certain concepts.

A total concept indicates the outlines of an architecture, the global architecture of an enterprise, or a part of an enterprise. If a client looks at a total concept, they can visualize many aspects.

Figure 1, Total Concept Example.

Figure 1 provides an example of how concepts fit together without causing a conflict. This total concept can now be elaborated upon with more details at the technological level, but preferably not yet at the product level. The latter only appears in the definitive architecture design.

The total concept shown in Figure 1 consists of two dimensions: 1) an enterprise domain model and 2) allocating technological concepts to a domain. Whether or not the enterprise or its products are perceived as attractive is not controlled by concepts. This is because the architect has not yet recognized decorative concepts, such as a pay-off, information columns, or unity in the physical and digital world with a specific brand name.

In a total concept, we notice hierarchy and decomposition of concepts. An architect must be aware that they must continuously make implicit choices regarding decomposition and hierarchy. To do this more explicitly, the total concept becomes less ‘cut-and-paste’ and ‘copy-work’ and more something the architect can set his seal upon.

On the following pages, we will elaborate further on the different ways of total concept model visualization. We will also cover the different perspectives of the total concept model. The architect needs a mandate to visualize certain versions and parts of the total concept to properly ‘sell’ to or to communicate with the client, steering committee, and other stakeholders.

Architects realize that technology alone is not sufficient. A technical solution must also be accompanied by enterprise restructuring. Therefore, an architect will, in a total concept, not only focus on IT solutions but also on business solutions, such as improving competence and retraining employees.

Dragon1 model - Concepts Framework

Figure 2, Concepts Framework model.

The Concepts Framework model in Figure 2, overviews common enterprise architecture concepts. Concepts could also be referred to as independent building blocks for generic implementation. When communicating with stakeholders, it is sometimes advisable to change the abstract term ‘concept’ in this way. Moreover, all the concepts in this model can be described more abstractly or in more detail. It essentially depends on what the architect considers necessary in a particular situation, and where the client acknowledges their ideas and requirements.

Figure 2 shows an example of a server, a concept utilized within an IT structure. Say that there are only application servers within an enterprise and no file server or print server; the architect should have made the concept of ‘server’ clearer by denoting it as ‘file server.’ Next to the server, the client is also recognized as a concept. Server and client are both specializations of the concept ‘computer’. The architect, however, has decided not to choose the ‘computer’ concept but to recognize the two specializations ‘client’ and ‘server’ as concepts in the architecture of the IT infrastructure.

The architect operates from a certain benchmark when choosing specialization or generalizing concepts: e.g., what does the enterprise want to become independent from, or what must the enterprise become independent from? The architect's choices significantly impact this, as they allow room for strategy, which can either speed up or unwittingly delay or block progress.

Therefore, architects use reference architectures to assess and test how globally or locally, and how generically or specifically they need to recognize concepts in an architecture. In Figure 2, the framework has been built from different levels in the architecture. At one architecture level, we find interconnected concepts. The information architecture level, which encompasses information facility concepts and the technical architecture level with its IT infrastructure concepts, is a level at which the architect conceptually considers the information facility and IT infrastructure elements of the enterprise structure.

Considering the above, working in terms of architecture levels, it becomes possible to assess a structure or total complex, such as an enterprise, as if the architect is wearing blinkers to filter out certain parts or aspects that are not important for the moment, so as not to confuse.

Both business administration and informatics are full of concepts. The more knowledge the architect has of these concepts, the more the architect can evaluate whether an enterprise works with or without these concepts. The architect evaluates by asking himself questions, formulating hypotheses, and testing them to assess their feasibility within the enterprise. An example of a hypothesis is: All work performed in the enterprise occurs through recognized and identified activities. With the help of this hypothesis, it can be investigated whether the business process concept is consistently applied throughout the enterprise.

Architecture as Total Concept

Dragon1 architecture is defined as a total concept: the coherent set of concepts of a structure (a system with constructive, operative, and decorative dimensions).

If the concepts are correctly addressed and blend construction, operation, and decoration, the concept becomes a total work of art. Even with organizations and IT, this can become true. So, concepts are the bricks of architecture. Therefore, it is essential to understand the fundamental concepts that comprise a comprehensive concept or architecture.

An example definition of the concept of Self Service: Self Service is the concept where the customer can select/choose. They also pay for goods, products, and services independently, utilizing resources or personnel within the organization.

This concept saves the organization resources and thus time and money in the sales process and increases the number of sales.

A principle is an enforced or managed way an entity works, behaves, or is constructed, producing certain results.

• Without an effective enforcement mechanism, the principle will not always produce the same results.
• Without knowing about the always and ever-produced results of a concept, you as an architect would not know why you chose a certain concept and made it part of the architecture.
• If you know how a concept works (out of what collaborating entities it exists), you are more able to recreate that way of working (collaboration) in the structure (and thus the produced results).

Every concept has a first principle (the principle that describes the whole way of working on a concept) and principles per function or element.

Example title of the Self-Service Principle: Making customers select and pay by themselves increases sales and saves the organization time and money.

Example short statement of the Self-Service Principle: By having customers select and pay for goods, products, and services by themselves anytime, anyplace, enabled by always available facilities, sales will go up, and sales costs will be lower than with the intervention of the organization's resources.