There is a direct correlation between each of the domains defined in the TOGAF® specification, understanding those correlations is key to being able to perform impact analysis, developing road maps that are not vendor lead and managing your risks.

Domain correlation

Consider the following model

The model is more than just a taxonomy. If we explode it and present three example what-if scenarios, we can see what these correlations are

In this model, when a particular what-if scenario is run, the arrows indicate the direction of impact analysis e.g. "an operating system becoming obsolete" has a direct impact into the Technology Domain, which directly affects the Information Architecture (Data and Application domains) which may impact on the running of the business - so you might perform an OS upgrade that stops an application from running which means the data made available through that application is no longer available which directly affects the running of the business.

But what about the scenario "take the business into a new geographic region?" It may seem like a no brainer and all you have to do pick up your applications, data and infrastructure and drop them into this new location. That might work if the location is within the same national boundaries. What about moving into a region where the laws on data are different, or the use of certain applications is restricted or banned because of the types of encryption used. You might believe (wrongly) that some of the technical issues go away because you will simply host the services (infrastructure and application) in the cloud, at first sight this is great, but then what about the data, where is it located, who actually owns it, who can access it etc.

The model above is a simple but effective tool for raising questions that must be answered.

Example of building the correlations

Consider the following example where your organisation has a timesheet process

Once you have the basics of the process you begin to assign to roles to the activities

The next thing you might consider is the core types of data that need to be captured or modified by the activities. You would also want to try and understand the data transformation, so we have shown this with arcs between the data entities

Now you start to think to yourself "What type of applications do I need to support the activities and the data?"

And finally, you realise that these applications need a platform to execute on

The picture I've painted is a simple one but it should get the point across, there is a symbiotic relationship between all of the domains. Where you start is irrelevant but starting in the business domain does make more sense in the example above. The key to building a model like the one shown above is that underpinning this model is a meta-model that ensures when you refer to a data entity in the business domain it is present in the data domain and in the application domain etc.

Related articles

Browser not supported