Applying reference models with archi mate
•
10 likes•6,885 views
This is the slidedeck for a webinar that I presented for the opengroup. It presents a high-level overview of the use of reference model in the field of EA. Even more I present with some tips on how to use BiZZdesign architect to effectivdely implement reference models in organizations
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Applying reference models with archi mate
Similar to Applying reference models with archi mate (20)
More from Bas van Gils
More from Bas van Gils (7)
Applying reference models with archi mate
- 1. Applying reference architectures with ArchiMate® Dr. Bas van Gils
- 2. Agenda • Definitions & terminology • (Very) high level intro: ArchiMate® • Modeling reference architectures in ArchiMate® • Considerations • Contact info 2
- 3. Slides If you would like to have a copy of the slides, please contact me at b.vangils@bizzdesign.com 3
- 4. Architecture: ISO/IEC 42010:2007 The Architecture (of a system) is the fundamental organization of that system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Simply put: structure with a vision 4
- 5. Architecture: examples What is the fundamental organization of the enterprise? What Enterprise is its fundamental behavior? How is it structured? What is the underlying rationale? How is the IT landscape structured? What are the main IT components, how do they interact, and what behavior does it landscape offer to its environment? Why did we structure it this way? How is our product offering structured? What are its Product components, how do they relate, and what is the underlying architecture principle for structuring it in this way? 5
- 7. Documenting architectures (2/2) Passive structure Behavior Active structure Business Application Technology 7
- 8. Reference model / architecture Wikipedia TOGAF A reference architecture in the A reference model is an field of software architecture abstract framework for or enterprise architecture understanding significant provides a template solution relationships among the for an architecture for a entities of [an] environment, particular domain. It also and for the development of provides a common vocabulary consistent standards or with which to discuss specifications supporting that implementations, often with environment. the aim to stress commonality. 8
- 9. A pragmatic definition • A reference architecture is an architecture that is referenced. • Following the ISO/IEC 42010:2007 definition, a reference architecture consists of: – A reference model that describes the fundamental organization of the domain under consideration – Principles underlying this fundamental organization • ArchiMate® is the language to choice for modeling reference architectures! 9
- 10. TOGAF®’s Enterprise continuum Reuse of (reference) architectures 10
- 11. Challenge A key challenge when using reference architectures is: how do we relate elements from a reference architecture to elements from concrete architectures? 11
- 12. In the following slides I have used a fictitious example. This enables us to focus on the mechanisms rather than the actual reference model. 12
- 13. Reference architectures in ArchiMate® Reference architecture Concrete architecture How to connect the two models? 13
- 14. Reference architectures in ArchiMate® The concrete model instantiates the services from the abstract model Functions/ capabilities are instantiated in a Application services process and components are instantiated in the concrete model 14
- 15. Relations in ArchiMate® • Structural relations • Behavior relations – Composition – Triggering – Aggregation – Flow – Assignment • Other relations – Realisation – Specialisation – Used by – Junction – Access – Groeping – Associatie 15
- 16. The specialization relation • In a “pure ArchiMate®” setting, the specialization relation comes closest to modeling the relation between elements from a reference architecture and a concrete architecture. • Specialization can be interpreted as an “is a” relation • E.g. – Application X from my architecture, is an instance of application Y from the reference architecture – Business function / capability X from my reference architecture translates to process step Y in my concrete architecture 16
- 17. Not allowed Allowed 17
- 18. Model packages and extra relations To solve the “specialization relation issue”: • Use tooling that supports model packages – A model package consists of more than one model – Use one model for the reference architecture, the other for the concrete architecture • Use extra relations that span models 18
- 19. Visualization (concrete model) using labels 19
- 20. Visualization (ref. architecture) using labels 20
- 21. Considerations Principles Language • Some reference architectures • Not all reference models / consist largely of principles reference architectures are • Example: NORA/ PETRA/ … documented using • Principles can still be put in a ArchiMate® separate section of the model • Translation may be necessary! package; use the “principle” • Using a unified language for concept from ArchiMate®’s all architecture models motivation extension! greatly improves their value 21
- 22. Conclusions • Reference Architectures: – Greatly improve effectiveness of the architecture practice of the enterprise – Should be modeled using ArchiMate®, using a combination of core concepts and principles • Tooling makes model management easier: – Combine reference models and architecture models in one model package – Relate elements from one model to another model within the same package 22
- 23. More information, next steps • Architecture Standards Kit webinars http://www.bizzdesign.nl/quickstart1 • Blog http://blog.bizzdesign.com • Training: http://www.bizzdesign.com/training • BiZZdesign Architect http://bizzdesign.com/tools/architect • Open Group website for ArchiMate®: http://www.opengroup.org/archimate/ 23
- 24. Contact information +31-(0)6-484 320 88 b.vangils@bizzdesign.nl http://nl.linkedin.com/in/basvg http://blog.bizzdesign.com http://www.bizzdesign.com http://twitter.com/basvg 24
Editor's Notes
- Welcome at this webinar on the modeling of reference architectures with ArchiMate. The goal of this webinar is to give you a solid starting point for getting started with reference models using the ArchiMate language. I am assuming that you’ve at least heard from the ArchiMate modeling language. However, for those of you who’re only just starting, I have also included a very high-level overview of this language.
- The agenda for today is as follows:We will start with some elementary definitions to make sure we’re all on the same page. In this part we’ll discuss concepts such as architecture, reference architecture, reference model, as well as briefly say a few words about the necessity of a good framework for architecture visualizations. This provides the ground work for the rest of the presentationThen we’ll provide a quick high-level overview of the core concepts of ArchiMate. Don’t worry: this is not a full-blown tutorial: it is just enough to provide background for those of you who haven’t been exposed to ArchiMate a lot.After this quick intro we’ll get to the meat of the presentation: how to model reference architectures in ArchiMate. I’ll give a pure-ArchiMate solution first and then show how ArchiMate tools like BiZZdesign Architect can support you in handling this in practice.As usual, we’ll end the session with Q&A.
- Before we get started: I will gladly make the slides available for you. If you want a copy, please drop me a note on b.vangils@bizzdesign.com. I’ll send you a copy as soon as I can.So, Let’s get started!
- Many definitions of architecture have been proposed in practice. It seems that no paper, book, or webinar can exist without discussing definitions and this webinar is no exception. The TOGAF definition of architecture is based on the IEEE standard. It roughly says that architecture consists of two things: on the one hand there is the “fundamental organization of a system” and on the other there is the “principles guiding design and evolution”. This translates well to the catch phrase “structure with a vision”. The city of Toronto is an interesting example.Structure: the city is organized in a gridVision: appeals to principles such as ease of navigation in a grid-like structureThe same principles apply to organizations. The question for architects then becomes: how do we want to organize ourselves?
- Lets apply this in practice. Looking at an enterprise, such as the OpenGroup, BiZZdesign, of any other organizations from an architecture perspective leads to t he question: what is the fundamental organization of this enterprise? The fundamental organization can probably be expressed using concepts such as processes, information, applications and so on. Similarly, if we look at the architecture of the application landscape, we’ll dive into questions such as: what is the fundamental organization of this application landscape and why did we choose this particular setup? Does it follow SOA-patterns? Point-to-point connections? Perhaps a monolith? Why?The choice of a proper scope is very important, as it says a lot about the usability of your architecture. Also, it makes it possible to relate elements from one archtitecture to another, fleshing them out by adding more detail and so on. This is, for example, the basis for the enterprise continuum in TOGAF
- Finding the proper scope for your architecture is a good first step. By itself, it is not sufficient though. To make architecture useful and practice, choices also have to be made with respect to the question: how will we communicate the architecture with key stakeholders? Here we see three different versions: the layered poster-sized picture that gives a clear overview of how things fit together, an informal comic that shows how one part of the architecture actually functions in practice and a formalized process models that shows all the underlying details. Of course, one can argue that the latter is ‘design’ rather than ‘architecture’, but that is a story for another day.
- In my opinion, ArchiMate is the language for doing architecture modeling, be it for enterprise architectures, reference architectures or any other form of architecture. Its core consists of three layers similar to the layering in the TOGAF standard. Furthermore, we distinguish between active structure – thigns that show behavior, the behavior itself, and passive structure – the results of behavior. This works as followsIn the business layer, we see how actors perform roles in processes and functions. These result in all sorts of business services that are offered via business interfaces, or channels.The application layer follows a similar pattern. Application components are assigned to functions, that jointly realize application services. This external behavior of applications is made accessible via application interfaces. The data object concept provides a bridge to disciplines such as data management and data governance.Again, the infrastructure layer follows a similar pattern. The node is the structure concept, that realizes all sorts of external services such as messaging, storage, and printing. As before, this behavior is made accessible via interfaces. This may seem like a lot, but it is only the tip of the iceberg. ArchiMAte core is fairly straightforward, and can be learned with just a few hours study because of all the symmetry in the model. For those interested: ArchiMate 2.0 also has a motivation extension, as well as an implementation and migration extension.
- So, with those preliminaries out of the way, lets dive into the world of reference architectures.Many definitions have been proposed, and are used in practice. Lets start with the Wikipedia definition, which simply states that a reference architecture is a reusable solution for a generic problem. In other words, it seems that this definition is very close to the definition of a pattern.Interestingly, TOGAF doesn’t seem to have a definition of the reference architecture concept. It does have one for reference model, though. This definition is close enough to the ISO/IEC definition of architecture, as it says something about a fundamental organization expressed in entities and relations between them.
- This brings me to my working definition: a reference architecture is an architecture that is referenced. Simple as that. The implications are simple: a reference architecture is an architecture itself, so regular architecture modeling techniques such as ArchiMate apply. As such, it consists of a model-part and a principle part. Lets call the model part a reference model to keep life simple. Keeping things simple has advantages, as it allows us to tie in with things like TOGAF’s enterprise continuum
- Lets say that we’re making a generic architecture description of organization in a certain industry, similar to the TM-Forum models for the telecom industry. If we do a proper job, then this architecture is general and covers several facets of organizations in this industry, such as business functions, processes, information, data and application components. We may even formulate some general principles. In the enterprise continuum, this architecture would sit in the industry-bucket. Any organization that reuses this architecture by referring to it, sit more to the right in the organization-bucket of the continuum.
- The key challenge, then, is how to model this? How does this fit in ArchiMate? Or, more specifically: how do we relate elements from the reference architecture to elements in the organization specific architecture?
- Please note, that I’ve deliberately used an abstract, ficticious example in the next few slides. This allows us to focus on the mechanism rather than the actual model. Sit tight, here we go!
- Lets say we have a reference architecture, consisting of two business services, functions, and a bit of supporting application stuff. Also, we’ve defined three generic principles.<click>An organization that reuses this model, may indeed implement the two services, define a process and so on. So far so good. <click> As I’ve just explained, the main question is: how to relate these two?
- The answer is not very hard to find at first:<click>The two services are identical, so we would want to use an ‘is equal to’ type of relation, or simply re-used the concept itself<click>The functions translate to, or are instantiated in a process. This changes things slightly, as direct re-use is now out of the question. Instead, we’ll want to use a different type of relation that expresses that one is translated into the other<click>At the application leve, we see that one service and the component are reuse, and one more service is added
- The archimate language has many types of relations available, ranting from 7 different structural relations, two behavioral relations and some other relations. Relating elements from reference architectures to elements from concrete architectures seems to be a matter of selecting the right relation type! However, life isn’t t hat simple as we’ll see shortly.
- At first, it may seem that the specialization relation is the one to use, as it denotes an “is-a” relation. Using the is-a relation, we can model the fact that some application from the concrete architecture, “is a”n instance of one of the elements from the referenced architectures. So, the question is: lets just draw specialization relations and be done with it? Unfortunately, no.
- Here we see two examples, inspired by our running example. On the left, we try to express the fact that the function F1 is an instance of the Step 1 process. On the right, we model something similar for two applications.<click>In the archimate language, though, the former is not allowed. This is because the specialization relation only works on objects of the same type. This means that we have to find another trick to relate the two models.
- To solve this issue, it makes sense to look at a tool-specific solution. Remember: what we’re trying to achieve is to relate elements from one model to elements from another model.To achieve this, we start by putting both models in the same model package as we’ll see here. Each model has its own views, application layer, business layer and so on. With both models in the same package, we’re ready for the next step.The idea is as follows: select an object – such as an application component – in one of the models, and use a dependency relation such as “is equal to” or “is refinement of” to precisely indicate how the two elements are related. Do this wherever applicable.
- Once all that hard work is done, it is fairly straightforward to make visualizations that show how the two models relate. Here we see the concrete model, where the labels indicate which objects from the referenced architecture. In this case, I’ve tweaked the labels a bit to also show what type of dependency relation was used.
- Here we see the reverse. This is the reference model, with labels from the concrete model. This can be interesting in many cases, such as mergers and acquisition: one of our clients is currently in the middle of a merger process, and by relating two concrete architectures to a generic reference architecture we can easily compare and analyze the situation, determining the best way forward for this company!
- Finally, lets finish this presentation with some considerations. <click>First of all, today we’ve focused mostly on the archimate modeling part of architecture work. It should be noted that some architectures consist mostly of principles. For example, there is a set of architectures for the Dutch government sector that are principle based. These architectures go by the names of NORA/ Petra / Gemma etc. Just like with models, these generic principles can still be put in a separate model-section and re-used in concrete architectures.<click>A second issue pertains to the situation where an architecture that we want to refer to isn’t in the ArchiMate language yet. I am convinced that all enterprise-focused architectures can be translated to ArchiMate. Doing so is a good starting point, both to improve communication about these reference architectures within an organization as well as in the professional community in that specific branch or industry.
- Last but not least my conclusions to help you get started in practice:Reference architectures should be approached just like regular architectures. Model them in ArchiMAte, and make them universally accessible.Tooling makes life easier. A lot easier. I am convinced that life for architects will greatly improve by making use of the fact that a modelpackage can consist of more than one model, and by relating elements from different models using dependency relations. As such, it’ll help us improve the effectiveness of the organization overall.
- Thank you very much for joining me in this webinar. If you have any questions or comments, feel free to drop me a note. For now, I wish you goot luck in getting started with ArchiMate!