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 this post we continue to describe examples for ArchiMate modeling using a top-down modeling strategy. In the previous posting we presented some examples from the business architecture domain, in this posting we will cover three examples in the IT domain:
Logical application components
Information / Data decomposition
Logical infrastructure components
We will give a high-level overview of an approach for each of the items: how to do it, who to talk to, where to find the right information.
As also mentioned in the previous posting, some general remarks apply. We repeat them here:
The trick to be successful with building up the top-down (homogeneous), high-level models is to avoid going in to much detail
Especially for the baseline situation, a lot is already ‘known’ and ‘in the heads of people’. There is usually also quite a bit of debate on how to structure models, definitions, scope, etcetera. We advocate a workshop-based approach to facilitate knowledge sharing and getting a shared understanding. This works best in a small team with expertise from various domains
Typically reference models help. E.g. for telco’s TAM/eTOM/SID, or BIAN for banks
Also make sure to use a two-pronged approach: one group creates the models, the other is “devil’s advocate” and challenge the results and assumptions in them.
Logical application landscape
Developing an application landscape map is not new. We’ve been doing that for years. It is tempting to say: “Been there, done that”. For many that may be true, but a few words of wisdom may help to get you started and get the most out of the initiative.
First, note that there is a difference between “logical” and “physical” components: logical is what we’ve architected, physical is what is actually “out there”. The difference can be important. For example, you’ll want to catch that you’ve architected a situation where you have 1 billing component for “regular (batch) payments” and “instant payments”, but needed to develop/ buy two components to make that happen. In our experience, at the enterprise level it makes sense to at least model the logical landscape. If you have time to spare, also capture the main (first level decomposition) functions of each of your components. Last but not least: you should also capture data flows if at all possible.
Tip: Don’t worry too much about the “physical” landscape. At this level you should not be interested too much in how many instances you have of each component. Do worry about a first level functional decomposition, and data flows between your applications.
Information / data decomposition
This is another interesting area of ‘enterprise models’. We typically follow the classic distinction between conceptual / logical / physical data models as illustrated in the diagram. We “borrowed” this from the excellent book Data & Reality which is highly recommended. Our best practice is fairly straight forward: we use Business Objects as a counterpart for the conceptual data model. Here we represent the “things people talk about in the business”. Data Objects are used as a counterpart for the logical data model. Here we may apply techniques such as normalization to better understand data structures. As a small example:
“Customer” would be a Business Object
In order to get to “Customer data” we may need two Data Objects: Party and Transaction. By analyzing which Parties have made a Purchase over the last n months, we arrive at the set of Customers.
The two levels are interlinked with the Realization relation.
Tip: Keep the Business Object model as simple as possible. Avoid composition/ aggregation. Don’t worry about normalization yet. That would be a topic more applicable to Data Objects.
Logical infrastructure components
Infrastructure architects have a reputation for drilling down to the (technical) details. Perhaps your mind already wanders to the wall-sized, Visio-made posters with lots of details about servers / server types, LAN, WAN, bridges, switches, firewalls etc. These maps are extremely valuable in the day to day work of the it / Infrastructure architect. In the context of enterprise models, though, we need something different. The trick is to keep a functional perspective: what are the types of nodes we see in our landscape, what services do they offer, and how are they connected?
Loosely based on OIAM, our best practice is simple: start by identifying the infrastructure services that are offered (or: the services that are required by your application). Keep these as functional as possible. Make a high-level functional decomposition and find out which functionality can / should be grouped in a node. Don’t worry about hardware of platforms just yet.
In the previous and this blog postings we discussed using a top-down approach for setting up enterprise models, and shared some of our tips and best practices that we’ve developed over the last few years. In the next two postings we will do the same for the “bottom-up” approach: figuring out how the pieces of the puzzle fit together. Stay tuned!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: