ArchiMate from a data modelling perspective

After my webinar on “building a data management capability with <a href="http://www.bizzdesign.com/consultancy/enterprise-architecture-management/togaf/">TOGAF</a> and <a href="http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/">ArchiMate</a>” I received several E-mails with interesting questions and useful suggestions. In one of those conversations we touched upon an issue that I stumble across in practice a lot: how to effectively use the classic ‘conceptual / logical / physical’ dichotomy when modelling with ArchiMate. After some E-mails back and forth, I found myself writing a rather long note which might be useful for a broader audience. I’ve included it below. I left out a few sentences here and there due to privacy considerations. If you have any related thoughts or suggestions, please drop me a note or leave a comment. If you like the work of Halpin, then I can recommend Kent as well. His classic book on "<a href="http://www.amazon.com/Data-Reality-Perspective-Perceiving-Information/dp/1935504215">Data and reality</a>" is now available as e-book. Good read with some thoughts that are still more than relevant. Let’s dive in […]. There are 2 aspects that are relevant in my opinion: (1) the dichotomy of architecture and design, and (2) the conceptual / logical / physical distinction.ad 1: dichotomy of architecture and designFor some reason this remains tricky for many practitioners. Constantly confusing the two "levels". Of course we can argue that <a href="http://www.bizzdesign.com/consultancy/enterprise-architecture-management/togaf/">Enterprise Architecture</a> is also a form of design… but that’s not the point. Following the generally accepted definitions, architecture deals with the fundamental organisation of a system as well as the principles guiding design and evolution. It’s high level, about coherence, and about how "things" in the enterprise are put together. The actual details of how things are organized in reality are more "Design" or "implementation". For a previous Webinar I made the following illustration:<img alt="Identifying solutions in ArchiMate" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/capability-architecture-solution-model.png" style="width: 300px; height: 239px;" title="ArchiMate can be used for identifying solutions (i.e. the SBB’s in TOGAF)"/>ArchiMate is very usable for architecture models. For identifying solutions (i.e. the SBB’s in TOGAF), ArchiMate is very usable too. For fleshing out the details, we need more detailed solution models and tend to use different notations, such as UML, BPMN, SBVR and so on. ad b. conceptual / logical / physicalUnfortunately here too we see many different interpretations. You’d think we have figured it out by now. Here are two interpretations that are used a lot:<img alt="Conceptual, logical and physical models" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/conceptual-logical-physical-model-data.png" style="width: 379px; height: 273px;" title="A conceptual model captures the business scope of the business solution, and the physical the technical solution."/>TOGAF seems to follow the interpretation close to Capgemini’s IAF where conceptual is about "what", logical is about "how" and physical is about "with what". In that case, conceptual/logical appears to map on the architecture level, whereas physical seems to map on the design/ implementation level. All three are somewhat in line but in practice we still see people mix-and-match between abstraction levels.My personal view is that we should pay close attention to the "level" (architecture / design) and "abstraction" (conceptual / logical / physical) that we’re working on. Don’t mix them. Also, I tend to merge the conceptual/logical levels at least for my ArchiMate models. That makes it easier to understand for many stakeholders in practice. Consider this simple example to see how it can work:<img alt="You can merge the conceptual and logical levels in ArchiMate to make it easier to understand for many stakeholders" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/data-modelling-business-process.png" style="width: 414px; height: 347px;" title="A merged version of the conceptual, logica land physical models"/> If you follow the strict definitions then you could argue that:<ul><li>conceptual: what is needed is the two application services s1 and s2</li> <li>logical: how we go about realizing it? In this case (due to some principles), apparently we chose for a solution with a single application component. For example "the ERP package"</li> <li>physical: with what is not in this model. There we have to look for physical counterparts of this ERP package. For example "SAP R/3"</li></ul>The same line of reasoning can be repeated between the application layer and the technology layer. Great, but what about the information/data world? I really like the way ArchiMate decided to not introduce a separate layer for information/ data […] I want to be able to talk about "what information is needed in the context of some business process or organisational role", or about "which data sits in what system" or "how did we organize information storage in in the infrastructure". Of course the data dissemination (one of the viewpoints in TOGAF) is part of that.While I agree that the definition of business object / data object / artefact / representation can be improved further, the intention behind them does work in practice. Let’s start with the conceptual/ logical level (incomplete, but it gives an idea):<img alt="Application and technology layer in ArchiMate" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/ArchiMate-conceptual-logical-level.png" style="width: 500px; height: 399px;" title="What information is needed in the context of some business process or organisational role"/>Here we see the following:<ul><li>In some process we need a bit of information (bo1). With bo1 (which is what I called an Entity in my webinar) we can represent attributes and all sorts of metadata. </li> <li>In order to get to this information, we need two data objects. That is, it appears that there are two data objects, both managed by the same system, which together realize the information that is needed for bo1. Remember that this is the architecture level. If we really want to dive into mappings between definitions, attributes, fields and so on then (in my opinion) we cross over into the realm of design. I’d be much happier using my favourite ORM2 or ERD tool for that!</li> <li>We also see that the application component needs (at least) two bits of infrastructure in order to function. Data storage and rule execution. Note that I haven’t specified what type of storage this will be. That’s an implementation choice that can be made later. Are we going for relational? or xml db? or flat file? At this point I don’t care!</li></ul>Diving into the solution would be something along the lines of:<img alt="SAP R/3 component" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/ArchiMate-solution.png" style="width: 500px; height: 275px;" title="deployment of the executables that make up the SAP R/3 component"/> Here we see the actual deployment of the executables that make up the SAP R/3 component (the two top artefacts) on the system software in the infrastructure. We also see how the artefacts are accessed by this system software. Note the dual use of the artefact concept: on the one hand it is used as the manifestation of data in the infrastructure, on the other it is used as an executable. Not ideal, but it is what it is…One thing that we still have to do is linking our conceptual / logical models to the physical models. There is no built-in mechanism in ArchiMate to handle this (the specialisation relation comes close but doesn’t do what you want it to do). Most tools these days (BiZZdesign Architect included) use the idea of "dependency relations" to create links across models.I think that it is high time for some best practices on how to deal with these issues. I also agree that a lot can be learned from the past. It’s up to us to make that happen!