Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
In two previous postings we have discussed the necessity of separating the what of architecture from the how and concluded that it is both useful and important to distinguish between a logical, ideal-world architecture description for a solution and a physical, implementable description therefore.
Consider again our running example:
This example shows a process which allows one to register for a concert via the internet. The process consists of three steps: (1) register for a performance, (2) specify payment details, and (3) receiving the electronic ticket. In order to make this happen, the organization offering this online service has identified four pieces of automated functionality that are required, modeled using application services. These services are implemented by two standard, off-the-shelf type components called Concert and Collection. The former has a database with concert information which is updated on a daily basis. The latter system stores client information until the concert has taken place, after which it is purged for reasons of confidentiality. So far so good.
This configuration, however, is rather inflexible. Suppose, for example, that marketing wants to start collecting client information to analyze customer purchases over the last year. This information is no longer available since data is purged after the concert has taken place. In practice, we often see that an extension is “hacked” onto the collection system to start saving that data for marketing purposes. This mixing of functionality and ‘hacked’ extensions will eventually decrease the flexibility and manageability of the application landscape will be seriously hampered. In turn, this will lead to higher operational costs.
From the perspective of architecture, it therefore makes sense to describe both the current situation and the (potential) future situation(s), taking into account the changes that may come. Therefore, an extra layer should be included which describes the “ideal world” solution and separates this from the implementation choices that have been made.
Consider therefore the above example. Here we see the same process still, using the same conceptual application services, focusing on the “what”. These application services are realized by logical application components, focusing on the “how”. The logical architecture describes the ideal-world architecture and structuring in components.
Finally, the logical application components are realized by physical artefacts, focusing on the “with what”. These artifacts are assigned to a Node – a bundling of hardware and system software. Here, the requirements around off the shelf software, budgets and other implementation considerations kick in. Therefore, a different modularization can be chosen at the physical level.
A strict implementation of the logical architecture is desirable in terms of maximizing reuse, leads to a more robust application landscape and is often more scalable. In other words, it provides companies with a good point of departure to achieve advantages in the competitive arena.
The distinction between a logical and physical architecture gives insight in current inefficiencies in implementation as well as guides future implementation choices in terms of reaching the goals set out in the logical architecture.
Based on the examples and analysis presented in this series of postings, we conclude that it is useful to distinguish between conceptual, logical, and physical architectures. Presently the ArchiMate language does not explicitly offer support for these three layers. We have shown, however, that with some common sense, architects can already define architectures on each of these layers. To end the series: it should be noted that using these three layers aligns nicely with the TOGAF content meta model (Link) which also uses this partitioning.
For more information, leave a comment.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: