If you are new to Enterprise Architecture, you might wonder what is meant with the term “Architecture Landscape” or “Architecture Blueprint”. While strategists and consultants love these terms, they are sometimes not used correctly. Let´s define them, their components, and what different types there are.
An Architecture Landscape in IT describes the assets that an organization needs to provide IT. As there are different types of assets and showing all of them in one picture would result in an extremely complex one, a view of an architecture landscape is typically filtered for a particular type or so-called architecture layer. Putting all the different views of the layers onto each other would provide the full architecture landscape.
Depending on the framework and the company´s enterprise architects, there can be different architecture layers. Best practices for architecture layers include using the following:
- Business Architecture
- Application Architecture
- Data and Information Architecture
- Technology Architecture
The set of those four layers is also called the BAIT layers, where every B stands for Business, A for Application, I for Information, and T for Technology. An additional layer that is becoming more famous is the Security Architecture layer, which is sometimes added as a fifth layer to the framework above. The results is called BAIT+S, where S stands for Security.
Besides the commonly used BAIT and BAIT+S models, TOGAF also provides its own set of layers. While the TOGAF layers are the origin of today´s models, the TOGAF layers itself a rather outdated and not practical anymore. TOGAF uses the following layer:
- Business Architecture
- Information Systems Architecture
- Technology Architecture
Those layers are not optimal, as enterprise architects often want to point out data and applications on separate layers (in TOGAF, both are part of the Information Systems Architecture) to emphasize that both are quite important nowadays and are addressed by different architectural use cases.
An Architecture Blueprint in IT describes a high-level view of an architecture landscape. While the architecture landscape is the real landscape itself, the blueprint is the representation of it on a PowerPoint slide, as picture or in a tool. Architecture blueprints are prepared for different use cases and for different stakeholders. As a blueprint always needs to simplify and abstract the real world, it is very important to understand what should be shown and what can be left out. The stakeholder audience and the use cases decide on the view.
Views and Viewpoints
The concept of views and viewpoints is introduced by TOGAF, but it is quite easy to understand. Imagine the following:
This morning, you climbed a mountain and now you stand on top of it. From there, you can see the valley with its three small rivers, two small villages, and a forest.
The next day, you climb another mountain and again, you stand on top of it. From there, you can again see the valley. This time, there is one big river, a large city, and an airport next to it.
In both occasions, the “top of the mountain” is the viewpoint and the “valley” is your view. It is the same in enterprise architecture. The viewpoint describes a generic point of view from which you take a look at your architecture – for instance from an application landscape point of view. However, even if the viewpoint is the same, the view will be a different one if you take a look at a different architecture. Like different architectures between departments or companies, the valley at the foot of the mountain looks different depending on the mountain that you climbed or even the time you did it!
Remember the following: Viewpoints are a generic point of view. Views are what you see, which can be represented as an architecture blueprint of a particular layer.
An “As-Is Architecture” or “Current Architecture” refers to the current architecture of a company, i.e. how it is today. It is a very important concept to identify the starting point for improvements such as an architecture roadmap. However, as architectures are often quite large and complex, an assessment of an As-Is Architecture is often in parts outdated before it is fully assessed. This is also why many enterprise architects put a high priority on assessing and updating As-Is Architectures easier and faster. Levers for this can be the amount of data assessed, the stakeholders and processes, and the governance, especially the tool that is used to capture and update the assessment.
A “To-Be Architecture” or “Target Architecture” refers to what architecture should be achieved in the future. The To-Be Architecture is the desired result of a set of work packages and activities carried out in projects. As they are the result of concrete changes on the As-Is Architecture, they also consider architecture-specific particularities that are neither likely, nor targeted to be changed. For instance, a company that is the result of a merger of two companies with a similar size that both operative in very different industries might not have the goal to harmonize many of their systems and applications. Therefore, the To-Be Architecture will still have separated systems and applications, while changes are done at other fronts. A To-Be Architecture can have a particular year or it can be communicated without a particular year in which it will be achieved.
Sometimes, the differences between As-Is Architecture and To-be Architecture can be quite large and lead to many projects carried out over a long period. In such cases, it can be helpful to define transition architectures. A transition architecture defines an architecture state that lies between the As-Is and To-Be Architecture at a specific point in time. Transition architectures are often used as major milestones in large transformation projects and there can be more than one transition architecture.
The term reference architecture is often confused with the term To-Be / Target Architecture. The difference is that a To-Be Architecture is the concrete view of how a company wants to be in the future, while a reference architecture is a general reference of how a To-Be Architecture could look like. Reference architectures are often specific for an industry or department, but not for a particular department of one particular company (that would be the To-Be architecture then). A reference architecture does not include company-specific constraints or requirements (the To-Be Architecture does this!) and illustrate a best case / target architecture that someone would develop on a greenfield. Therefore, a reference architecture would not show the historical separation of the systems and applications as described in the example above – as such a separation would not be a generic reference for a whole industry.