This article will focus on the subject of enterprise architecture. The article will also elaborate what approaches can be used to apply or implement Enterprise Architecture successfully in companies and organizations. Specifically, it will be discussed which conceptual starting points architecture experts in an organization typically use in their approaches to enterprise architecture. In addition, I would like to shed light on the advantages and disadvantages of the discussed approaches. It will also be discussed why it is so important not to be guided by dogmatism in the context of enterprise architecture. Therefore, I recommend considering the article not exclusively from a purely architectural-methodological point of view. Rather, it makes sense to reflect that enterprise architecture is a means to an end for most organizations and corporations. Accordingly, adjustments of the architecture approach chosen shall be possible in case of changing environment or requirements.
The target audience of the article are enterprise architects who want to generate the highest possible added value in the company with their work. However, the target group also includes decision-makers and business executives who want to understand the basic approach to enterprise architecture and wish to define and document their requirements and general conditions in dialogue with the architects.
Typically, experts on enterprise architecture can be characterized by three approaches to the topic. Therefore, in the first step, I recommend that the architect among you reflect which of the three approaches most closely matches your personal methodological approach. For those of you in the business, I recommend that you make yourself aware which of the three approaches most closely matches the current approach in your business.
I want to classify the three different approaches as
and elaborate them in more detail below.
The classic approach is characterized in particular by the fact that the respective architects in the company have identified a concrete architectural framework (for example the TOGAF). This framework represents the guideline on methodology and at the same time the one and only specification in dealing with architectures represents.
Reasons for this approach are that architectural frameworks per se bundle good practice and therefore help to treat typical issues properly. In addition, they provide methodology and interpretation security as to how architectures in the company are to be developed, understood and used.
The disadvantage may be that the standard methods and procedures contained as good practice in the framework are generally not sufficiently matched to the specific business requirements of the company. Consequently, when using the classical approach, there is always a certain balancing act between utility and usability of the respective framework.
The classic approach is often used in organizations which have identified enterprise architecture as a valuable concept and find help and guidelines for the implementation within the company in the framework.
Opposite this is an approach that I classify as the revolutionary approach. It is characterized by the fact that, based on the organizations architectural know-how, the corresponding architectural concepts are developed from scratch and specially adapted to the requirements of the stakeholders involved.
Reasons for this approach are, the fundamental possibility of a tailor-made adaptation of the respective procedures to the requirements of the company. In addition the approach comes with a high degree of self-realization and intrinsic motivation of the employed staff, since major concepts and procedures can be developed and elaborated in-house.
The disadvantage may be the effect that self-developments can lead to reinventing the wheel every time and in every imaginable extent. In addition, the revolutionary approach leads to a high dependency on the expertise of individual methodologists as well as to an inherent risk that conceptual policy work in business is understood more as an academic end in itself and less as a suitable means to an end in terms of corporate requirements.
As a third methodical approach to the topic of enterprise architecture I would like to describe the evolutionary approach. This approach is based on the assumption that all and everything can be represented by a simple relationship of objects (for example, via a generic N3 notation). Proponents of the evolutionary approach consider this type of representation to be meaningful in the context of enterprise architecture.
In simple terms, the N3 notation makes use of the fact that a set of triples of the structure object 1 – relationship – object 2 can be used to represent the relationships between any set of objects (for example systems). The semantics, which defines the meaning of the objects and relations, can be extended or specified evolutionarily and thus gradually. This approach enjoys a certain popularity above all in organizations which, for example because of their relatively small size, have the opportunity to act dynamically and approach the challenges of structured planning and documentation with pragmatism.
Reasons for this approach are its captivating simplicity and its immense flexibility in terms of expandability and adaptation to changing conditions.
The disadvantage may be the danger of rendering complex relationships extremely simplified. The approach also has some drawbacks, as complexity can increase significantly with increasing expansion and adaptation, for example, by specifying custom semantics. This danger exists in particular when vocabulary needs overloaded semantically. In addition, the high degrees of freedom of the evolutionary approach may inadvertently lead to an uncoordinated and fluid transition towards the revolutionary approach.
Regardless of which of the three approaches you have identified as being currently applied in your organization, you may also observe that some stakeholders do not accept the concept of enterprise architecture at all. The major reason is more often than not, that the company does not have consistency in the architecture methodology. This effect often occurs in large organizations where the following typical development can often be observed.
This development can become an unproductive cycle as shown in the following graphic.
Reoccurring phases in approaching enterprise architecture
The cliff that needs to be circumvented at this point is to clearly address the inherent vulnerability in your own business to just that effect and to ensure that your organization does not maneuver into a never-ending and highly destructive cycle.
None of the approaches presented can be described per se as bad or inappropriate. Rather, it has been proven in practice to develop and document a combination of the three approaches based on enterprise architecture enterprise requirements and objectives. It has also been proven to communicate this integrated approach as a common approach within the enterprise.
My recommendation is to enable this common understanding in the sense of the classical approach via a concrete architectural framework. As with a toolbox, this can only be a few appropriate aspects of the framework, for example good practice in terms of methods and procedures for architecture development and use from the TOGAF (i.e. the ADM). The advantage of this procedure, specifically to choose the classic approach as a starting point, is that you profit as early as possible from good practice from the selected initial architecture framework. Another benefit is that this methodology is applicable to all common architectural frameworks which either implicitly or explicitly support the inclusion of evolutionary and revolutionary aspects.
The integrated approach to enterprise architecture
A next step in the sense of an evolutionary extension of the methodological understanding of TOGAF’s ADM, could be to incorporate the views from other architectural frameworks to benefit from proven templates that help to document the different perspectives and stakeholders of the enterprise.
A framework that I would like to recommend to you here and for exactly this purpose is the non-proprietary NATO Architecture Framework (NAF) which, despite its military origins, is very well thought-out and also supported by many architecture tools. NAF provides templates for modeling a wide variety of stakeholder interests in military but also business applications.
Based on the methodology of TOGAF and the views of the NAF, you could then decide that you would like to model your architectures with one of the common architectural tools and therefore want to make use of the very sophisticated metamodel of the NAF. In the spirit of the revolutionary approach, the open documentation of this meta-model would allow you to tailor it to your company’s requirements as needed. With this approach, you would have defined an approach that at least the architects in your company can work with. Thus, the implementation of specific business requirements based on good practice would be sustainably feasible.
What is still lacking in terms of the integrated approach, however, is the bridge from the architectures to all other stakeholders in the organization and in the company. Therefore, in favor of acceptance and sustainability in dialogue with these stakeholders beyond all modeling, I strongly recommend not neglecting the aspect of objective and target group oriented visualization of the achieved concepts and results. In my experience, this aspect can not be emphasized enough, since the core competence of most stakeholders in a company with the exception of architects is not the reading and understanding of more or less cryptic architectural diagrams, but the implementation of the respective day-to-day business in relation to the business model the company.
If architectures, regardless of the chosen approach, whether classic, revolutionary, evolutionary or integrated, should find general acceptance in the enterprise, then the implementation of the concept Enterprise Architecture must generate on the one hand added value for all involved stakeholders. On the other hand these added values in the sense of an appealing usable and possibly adapted visualization shall be usable by all applicable stakeholders. In the case of a system architecture, this can be the transfer of the results to a wiring diagram, but for C-level management this can also be the transformation of the results into a reliable decision template or, for the procurement departments, the documentation as a list of system components to be procured. In any case, it is important to find and select the type of presentation and visualization with which the addressed target groups can work best and most effectively.
In this article on the integrated approach to enterprise architecture, I introduced you to three approaches to architecture.
Based on these three approaches, I have discussed with you that a proper approach to Enterprise Architecture implementation should be made through a so-called integrated approach. For example, in the sense of the classical approach, good practice can be used to start up models and procedures from a concrete framework. Approaching the evolutionary approach with template stakeholder interests and modeling meta-modeling can be followed by enterprise-specific adaptations to procedures and models in the spirit of the revolutionary approach.
Finally, I recommend to focus on the fact that architectures should not be an end in themselves, but that the results should be visualized in a target-group-specific manner. This enables acceptance, usability, and added value for the company, since the majority of stakeholders in an organization does nor expect to work with sophisticated architecture diagrams but with products like wiring diagrams, lists or decision templates which support them in their respective day-to-day business.
This completes the contribution to the integrated approach and I would be delighted if the concepts and experiences presented help you to properly implement enterprise architecture in your business.