Search Results for “archimate” – Page 17

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

September 12, 2013 by Open Group

By Serge Thorn, Architecting the Enterprise One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment. Along the years, I have found out that the term … Continue reading →

The 1st Belgian ArchiMate User Group Meeting

July 7, 2013 by BizzDesign Staff

Last week I was proud to chair the first Belgian <a href=”http://pubs.opengroup.org/architecture/archimate2-doc/” style=”font-size: 11px; line-height: 19px;”>ArchiMate</a> User Group meeting in Brussels, hosted by <a href=”http://www.itworks.be/” style=”font-size: 11px; line-height: 19px;”>IT Works</a>. With three good speakers and a group of about 30 participants, the meeting was a big success. Hopefully we will have many more of such sessions in the years to come. In this short blogpost I’ll present some of the highlights from the session. Rather than attempting to summarize the excellent talks by Jan Casteels (AXA, ING), Geert Cannaerts & Christof Nikolay (both HP), and Pieter van Ostaeyen (de Lijn), I’ll stick to presenting some of the highlights.<ul><li>A common element in each of the three stories is “business-focused analyses”. Or, to put it differently: we spoke a lot about the type of analyses we can do for various (business) stakeholders as well as creating powerful visualizations to support decision making.</li> <li>The three speakers each used different tools (including <a href=”http://archi.cetis.ac.uk/”>Archi</a>, <a href=”http://www.sparxsystems.com.au/”>Sparx</a>, and <a href=”http://www.bizzdesign.nl/tools/architect/”>BiZZdesign Architect</a>). The consensus seemed to be that all tools work as long as the focus is on modeling / entry of concepts and relations. A “proper” tool like Architect is needed when the focus shifts to analyses (i.e., color views, label views, generating views and cross tables, roadmapping and so on)</li> <li>There was a lot of discussion about different levels of models. <ul><li>On the one hand this refers to the difference between “architecture” and “design” (i.e., growing attentions to linking architecture models at the enterprise level to process management, business rule management, and data management at the design level).</li> <li>It also appeals to the difference between three levels of abstraction: conceptual, logical, and physical models. A crisp and clear distinction between these levels is far from easy, yet it is important to at least distinguish (and create links) between a “conceptual/logical” model and a “physical” model of the enterprise</li> </ul></li> <li>Other topics that were briefly discussed include </li> <li>The use of reference models for re-use and a head-start in creating consistent models across the enterprise.</li> <li>Starting ArchiMate modeling projects from the bottom-up. That is: rather than shooting for a top-down, enterprise-wide initiative, we see more and more organizations where the first ArchiMate models are developed in projects. This has the added advantage of adding business value early, as well as establishing good practices in modeling from the start!</li></ul>After a good discussions, we also found several areas where more support and guidance would be useful for the ArchiMate community at large. These boil down to the following:<ul><li>Easy exchange of models between tools: we see that different stakeholders and groups of professionals require different types of tools. At some point the necessity to integrate these models / to upgrade to a full-blown EA tool like Architect arises. Being able to seamlessly switch between tools is important. After all, it is about the content, not the tool.</li> <li>In line with the discussion on different levels of models, more guidance on conceptual / logical / physical modeling as well as tool support (i.e., the use of dependency relations in BiZZdesign Architect) will help the community to deal with this issue consistently and effectively</li> <li>Last but not least: in many situations it would be valuable to be able to represent the modality of relations between concepts. This goes for “cardinality” of associations, but it goes further than that. Being able to represent the fact that “a process always uses a services” versus “a process may optionally use a service” can be equally important</li></ul> All in all a great session with plenty of tips, real-world stories, and suggestions for taking ArchiMate initiatives to the next level.

The Decision Model, Enterprise Architecture, ArchiMate and “The Decision Modeler”

May 27, 2013 by BizzDesign Staff

In my previous post I discussed my Three Decision Model Predictions and how they were realised by BiZZdesign ‘<a href=”http://www.bizzdesign.com/tools/the-decision-modeler/” target=”_blank”>The Decision Modeler’</a> – a new TDM tool.In this post I shall first explore the relationships between The Decision Model (TDM) and various Enterprise Architecture and design models, and why it is important to be able to model the dependences between TDM and other design and IT domains. Then I will show that BiZZdesign, using “The Decision Modeler” and ArchiMate tools, has become the first vendor to enable TDM models to form inter-model relationships and the advantages that brings to IT and the business.Wikipedia defines <a href=”http://en.wikipedia.org/wiki/Archimate” target=”_blank”>ArchiMate</a> (a technical standard of the Open Group) “[as] an open and independent enterprise architecture modelling language to support the description, analysis and visualization of architecture within and across business domainsin an unambiguous way.”<h2 class=”p1″>The Big Ball of Mud</h2>It was Foote & Yoder who in 1997 described early application software as being a “big ball of mud” because all the aspects and concerns of an application were all mixed together without any perceivable architecture. Later, it became apparent (see figure 1) that if one could separate out each aspect or concern of an application into its own component model, that it would be much easier to develop and maintain separately each aspect as well as the entire application.<img alt=”Balls of mudd or software applications?” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-software-applications_400x307.png” style=”width: 400px; height: 307px;” title=”Software applications are balls of mudd”/>However there was one aspect which did not have a rigorous technology independent model and that was the business logic component, or business rules. This problem was solved with the invention of <a href=”http://www.kpiusa.com/index.php/The-Decision-Model/the-decision-model.html” target=”_blank”>The Decision Model</a> (TDM). All previous attempts had failed in creating a modelling language that could both tame the complexity of business logic and at the same time make it understandable to both business and IT users.One of the brilliant insights that the inventors of The Decision Model (Barbara Van Halle and Larry Goldberg) had was to tame the complexity of business logic using “business decisions” as a first class business logic concept, and then to invent a business logic model based on the inherent structure of logic and the business logic required to reach a business decision.The next insight they had was to choose a graphical notation that was simple for the business to understand yet expressive enough for IT; and then to marry this graphical notation with the 15 The Decision Model principles (declarative, structural and integrity principles) required to provide The Decision Model models with logical rigour.For further information on the 15 The Decision Model principles read the book “<a href=”http://www.amazon.com/Decision-Model-Framework-Technology-Management/dp/1420082817″ target=”_blank”>The Decision Model : A Business Logic Framework Linking Business and Technology” by Barbara von Halle and Larry Goldberg.</a>Business and IT could now use The Decision Model to extract all the business logic that are embedded within existing enterprise architecture, design and IT models and code into separate The Decision Model models, each linked to a business decision that the business wants to manage.<h2 class=”p1″>Integrating The Decision Model models with other models</h2>Having separated out from the “big ball of mud” and created The Decision Model models there is also a need for the integration and connections between The Decision Model models and other design and IT models to be modelled for the following reasons:<ul><li class=”li2″>Creating Decision-aware process models. Having extracted business logic from a process model and created one or more The Decision Model model, it is essential that a connection between a process task that is to execute a business decision and the The Decision Model model for that business decision. This connection can be modelled graphically using shared metadata (in this case the name of each the business decision that is to be evaluated (see figure 2). in BPMN notation the connection point is the name of the business rule task having the same decision name as a The Decision Model model. Figure 2 (taken from The Decision Modeler) shows the link between a business rule tasks (in the process domain) and the The Decision Model models (in the business logic domain). <img alt=”Business rule tasks and The Decision Model” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-rule-tasks_399x283.png” style=”width: 399px; height: 283px;” title=”link between a business rule tasks and the The Decision Model models”/> In fact since business rule tasks are determining a business decisions and should really be called decision tasks. It is possible in BPMN to a define decision task as a stereotype of a business rule task and then to decorate the decision task with the The Decision Model blue octagon, to differentiate between an ordinary business rule task and a decision task. The Decision Model models do not implement actions directly; they only determine decisions based upon the execution of business logic. The results from the execution of a The Decision Model model can be returned to a decision gateway in the process model; which then determines and routes the subsequent actions that are to be executed based on the results returned. If an executable BPM modelling language like BPMN 2.0 is used, then it is possible to execute the BPMN process models in a BPM engine which consumes The Decision Modeler models in the form of Decision Services running in a business rules engine. </li> <li class=”li2″> Enable the Model-Driven Application (MDA) generation of code and other executable artefacts. Figure 3 shows the natural connections that exist between The Decision Model models and many types of models, these include UML, Logical data models, Use Case, Object Model, Fact Models, Business Process Models, etc.Once all the dependencies between a The Decision Model model and other dependant models are determined and modelled it is often possible for software to convert these models into executable artefacts with reduced programmer input leading to increased productivity and reduced defects. <img alt=”The Decision Model has natural connections with other models” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-natural-connections_400x311.png” style=”width: 400px; height: 311px;” title=”Natural connections between The Decision Model and many other models”/> MDA-driven and The Decision Model-based applications offer the potential for a new frontier in enterprise applications. Gone will be the days of expensive consultants tailoring complex enterprise applications where all the business logic has been hard-coded into the application code. Instead a customer need only tailor the relevant The Decision Model models (provided by the enterprise application vendor) to their requirements and then “re-generate” the enterprise application – saving substantial costs and increased business agility. This The Decision Model frontier is yet to arrive but I predict it will be 5 years before such applications arrive – driven by the next generation of agile The Decision Model-driven enterprise application vendors. </li> <li class=”li2″> Using The Decision Model to Manage IT Operational Systems. Many middleware and Service Oriented Architecture (SOA) vendors are now designing their technologies so that a combination of business rules, complex event and BPM engines can be used to model and implement the business logic required to operate and manage their infrastructure. <img alt=”Service Oriented Architecture” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-service-oriented-architecture_316x272.png” style=”width: 316px; height: 272px;” title=”Service Oriented Architecture (SOA)”/> In fact many Enterprise Service Bus (ESB) middleware contain the ability to perform routing based on dynamic rule bases. There is nothing to prevent the business logic that an ESB requires to be developed and maintained using from The Decision Model models. The ability to connect The Decision Model models that are being used to manage IT middleware (such as Figure 4) to components within the architecture is an exciting new development for The Decision Model. Until now, The Decision Model was being considered primarily for developing business applications rather than for controlling and managing complex IT execution platforms and middleware. It is important to realise that The Decision Model models can be automatically converted not only into rules that can executed in rules engines but can be converted into languages such as Java, XML, etc. The ability to model the inter-model relationships between models of IT infrastructure components and The Decision Model models will be required to meet traceability and governance requirements. </li> <li class=”li2″> Linking The Decision Model with Strategic Models. One of the advantages of ArchiMate is that it includes the Motivation extension for modelling (among others) stakeholders, business goals, principles and requirements, which can be linked to the elements in the architecture that realize them. In this way, we can achieve full traceability from goals and requirements to architecture, design and implementation. <img alt=”Motivation Extention” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-motivation-extention-metamodel_550x238.png” style=”width: 550px; height: 238px;” title=”Motivation Extention Metamodel”/> Figure 5 shows the key concepts of the Motivation metamodel. The Drivers are the things, internal or external that creates, motivates change in the organisation. Assessment is defined as the outcome of some analysis of some driver. Goals are the intended end states that a stakeholder seeks to achieve. Requirement is defined as a statement of needs that must be realised by a system. In fact Requirements model the properties of the elements (e.g. business process, business decision logic, application component) that are needed to achieve the “ends” that are modelled as goals. Requirements can therefore be considered the “means” to realise goals. The The Decision Model models that are of strategic interest to stakeholders are those key business decisions that are critical or important to the realisation of the strategic goals. Since The Decision Model is about modelling the business logic behind business decisions these strategic The Decision Model models can be considered high-level requirements that should be linked to Requirements in the Motivation model. Not all The Decision Model models should, in my view, be directly linked to Requirements. For example data-quality The Decision Model models, valuable as they are need not be linked to Requirements. Of course some The Decision Model models need not be directly linked to the Motivation model. For example a Requirement in the Motivation model may be linked to a ArchiMate process model in the business layer which may then be linked to a TDM and BPMN models (see figure 10). However linking The Decision Model models that realise strategic business decisions, that are required to realise business goals, are of immense value to stakeholders. Because these The Decision Model models can be linked to metrics which then drive a corporate balanced scorecard forming a feed-back loop that is required for good strategic planning and implementation. More information on this will be discussed in my third guest post ”Business Performance Management and The Decision Model”. </li> <li class=”li2″> Strategy Models and Skeleton The Decision Model models When modelling and connecting The Decision Model models with strategic and other Enterprise Architecture models it is important to realise that The Decision Model models can be linked to Enterprise Architecture and other design models in their skeleton form before individual rules within Rule Families have been modelled. Assuming that one is using the top-down methodology for developing The Decision Model models one could start with the business decision and then add the supporting Decision Rule Family. This initial minimal The Decision Model model can be linked to other models including strategic motivation models. Then later in the The Decision Model design process these initial The Decision Model skeleton models can expanded until the model is complete. Then the process of completing the individual rows (business rules) in each Rule Family table. The diagram below shows a The Decision Model model in a skeleton form. <img alt=”Skeleton form” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-skeleton-form_450x320.jpg” style=”width: 450px; height: 320px;” title=”The Decision Model model in a skeleton form”/> </li> <li class=”li2″> A Skeleton TDM model The diagram below show what you see when you drill down and expand a Rule Family and see the contents of a Rule Family Table (shown in yellow below). Each row within a Rule Family Table is equivalent to a single rule. Enterprise Architecture The Decision Model modelling does not require that you use completed The Decision Model models. Over time during the design phase the The Decision Model models will be completed and the inter-model links will ensure that the latest The Decision Model model will always be linked. <img alt=”Rule families” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-rule-families_450x327.png” style=”width: 450px; height: 327px;” title=”The Decision Model rule families”/> </li></ul> <h2 class=”li2″>BiZZdesign, ArchiMate and The Decision Modeler</h2>BiZZdesign is the only tool vendor that has produced TDM-aware tools that enable the rich modelling landscape outlined above can be realised.<h2>The Decision Modeler – Integrates Business Logic, Information and Processes</h2>The integration between business logic, Information and Processes is illustrated in figure 7 and is directly implemented within The Decision Modeler; with business logic being modelled by The Decision Model, the information domain modelled by UML and the process domain modelled by Amber and BPMN 2.<img alt=”Information and processes can be related” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-integration-of-business-logic-information-processes_301x275.png” style=”width: 301px; height: 275px; float: left;” title=”Integration of business logic and information and processes”/><img alt=”Policy and claim relation” class=”right” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-relation-policy-claim_300x192.png” style=”width: 300px; height: 192px; float: right;” title=”Relationship between policy and claim”/> Figure 8 show the relationship between Policy and Claim classes and their attributes in the information domain using UML. Figure 9 shows that same information model with a summary of how The Decision Modeler integrates Process, The Decision Model, Rule Family, Rule Family Tables, Fact Types, Glossary and UML.<img alt=”Modeling domains summary” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-summary-relations-modeling-domains_450x365.png” style=”width: 450px; height: 365px;” title=”Summary of relations between modeling domains”/><h2 class=”p1″>Integrating ArchiMate with TDM – The BiZZdesign Advantage</h2>There is no doubt that The Decision Modeler integration of The Decision Model, UML and BPMN 2 (and Amber) has resulted in an excellent TDM tool. However, BiZZdesign integration of the ArchiMate enterprise architecture modelling standard (within its Architect toolset) with The Decision Model sets BiZZdesign as the clear leader in The Decision Model tool innovation.<img alt=”Interrelationships” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-interrelationships_451x273.png” style=”width: 451px; height: 273px;” title=”Interrelationships”/>ArchiMate is particularly suited for modelling the interrelationships between different domains (see figure 10). So in an ArchiMate model we can show what the main products are; which business processes realize them, which information and business decisions are used in these processes, which applications support them, etc. Then we model the details in each of these domains in the appropriate languages, e.g., business processes in BPMN, business decisions and business logic in The Decision Model, information and applications in UML. If we use the same tool suite for these models, we can link these models to elements in the ArchiMate model (using references or inter-model relationships), to link to each other.ArchiMate is an extendable modelling language, for example:<ul><li class=”li2″>It is possible to define new attributes and relationships and to create new concepts based on the specialisation of existing concepts. </li> <li class=”li2″>It is possible to define new domain specific languages (DSLs) as user defined profiles. </li></ul><h2 class=”li2″>Conclusions</h2>All the inter-model relationships I have outlined in this post can be modelled by a combination of ArchiMate and The Decision Modeler. BiZZdesign decision to bring The Decision Model-awareness to ArchiMate’s extensive modelling capabilities is going to transform Enterprise Architecture and decision modelling practice.In one leap BiZZdesign has gone from a standing start, in The Decision Model tools, to being the most innovative The Decision Model tool vendor. In due course, other The Decision Model tool vendors will respond, but for now BiZZdesign leads the The Decision Model vendors with its modelling capabilities. <div class=”p1″ style=”background:#eee;border:1px solid #ccc;padding:5px 10px;”>Suleiman Shehu is the CEO, of Dublin based <a href=”http://www.azinta.com” target=”_blank”>Azinta Systems Ltd</a>. Azinta Systems is a business transformation, business integration and consultancy company. Azinta is a KPI The Decision Model consulting partner for the Europe, Middle-East and Africa (EMEA). Azinta has recently signed a strategic business partnership with BiZZdesign for EMEA region and Azinta will be providing TDM consulting and TDM methodology training services for those looking to start using TDM with the Decision Modeler. Suleiman can be contacted at Suleiman.shehu@azinta.com. </div>

ArchiMate from a data modelling perspective

May 13, 2013 by BizzDesign Staff

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!

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

May 10, 2013May 8, 2013 by Serge Thorn

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

Let’s start with a definition of traceability. Traceable is an adjective; capable of being traced. Trying to find a definition even from a dictionary is a challenge and the most relevant one I found on Wikipedia which may be used as a reference could be “The formal definition of traceability is the ability to chronologically interrelate uniquely identifiable entities in a way that is verifiable.”

In Enterprise Architecture, traceability may mean different things to different people.

Some people refer to

· Enterprise traceability which proves alignment to business goals

· End-to-end traceability to business requirements and processes

· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities

· Requirements traceability which assists in quality solutions that meets the business needs

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

· Traceability between artifacts from business and IT strategy to solution development and delivery

· Traceability from the initial design phase through to deployment

· And probably more

The TOGAF 9.1 specification rarely refers to traceability and the only sections where the concept is used are in the various architecture domains where we should document a requirements traceability report or traceability from application to business function to data entity.

The most relevant section is probably where in the classes of architecture engagement it says:

“Using the traceability between IT and business inherent in enterprise architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.”

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

Using the TOGAF 9.1 framework, we would use concepts of the Metamodel. The core metamodel entities show the purpose of each entity and the key relationships that support architectural traceability as stipulated in the section 34.2.1 Core Content Metamodel Concepts.

So now, how do we build that traceability? This is going to happen along the various ADM cycles that an enterprise will support. It is going to be quite a long process depending on the complexity, the size and the various locations where the business operates.

There may be five different ways to build that traceability:

· Manually using an office product

· With an enterprise architecture tool not linked to the TOGAF 9.1 framework

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

1. Manually using an office product

You will probably document your architecture with the use of word processing, spread sheets and diagramming tools and store these documents in a file structure on a file server, ideally using some form of content management system.

Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system or an enterprise. The links between these deliverables soon becomes non manageable and in the long term impact analysis of any change will become quite impossible. Information will be hard to find and to trace from requirements all the way back to the business goal that drives it. This is particularly difficult to achieve when requirements are stored in spread sheets and use cases and business goals are contained in separate documents. Other issues such as maintenance and consistency would have to be considered.

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Many enterprise architecture tools or suites provide different techniques to support traceability but do not really describe how things work and focus mainly on describing requirements traceability. In the following example, we use a traceability matrix between user requirements and functional specifications, use cases, components, software artifacts, test cases, business processes, design specifications and more.

Mapping the requirements to use cases and other information can be very labor-intensive.

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

Below is an example of what traceability would look like in an enterprise architecture tool after some time. That enterprise architecture ensures appropriate traceability from business architecture to the other allied architectures.

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

The TOGAF 9.1 core metamodel provides a minimum set of architectural content to support traceability across artifacts. Usually we use catalogs, matrices and diagrams to build traceability independently of dragging lines between elements (except possibly for the diagrams). Using catalogs and matrices are activities which may be assigned to various stakeholders in the organisation and theoretically can sometimes hide the complexity associated with an enterprise architecture tool.

Using artifacts creates traceability. As an example coming from the specification; “A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified”. There are other artifacts which also describe other traceability: Data Migration Diagram and Networked Computing/Hardware Diagram.

4. With an enterprise architecture tool using ArchiMate 2.0

Another possibility could be the use of the ArchiMate standard from The Open Group. Some of the that traceability could also be achievable in some way using BPMN and UML for specific domains such as process details in Business Architecture or building the bridge between Enterprise Architecture and Software architecture.

With ArchiMate 2.0 we can define the end to end traceability and produce several viewpoints such as the Layered Viewpoint which shows several layers and aspects of an enterprise architecture in a single diagram. Elements are modelled in five different layers when displaying the enterprise architecture; these are then linked with each other using relationships. We differentiate between the following layers and extensions:

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

The example from the specification below documents the various architecture layers.

As you will notice, this ArchiMate 2.0 viewpoint looks quite similar to the TOGAF 9.1 Business Footprint Diagram which provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.

Another example could be the description of the traceability among business goals, technical capabilities, business benefits and metrics. The key point about the motivation extension is to work with the requirement object.

Using the motivation viewpoint from the specification as a reference (motivation extension), you could define business benefits / expectations within the business goal object, and then define sub-goals as KPIs to measure the benefits of the plan and list all of the identified requirements of the project / program. Finally, you could link these requirements with either application or infrastructure service object representing software or technical capabilities. (Partial example below).

One of the common questions I have recently received from various enterprise architects is “Now that I know TOGAF and ArchiMate… how should I model my enterprise? Should I use the TOGAF 9.1 artifacts to create that traceability? Should I use ArchiMate 2.0? Should I use both? Should I forget the artifacts…”. These are good questions and I’m afraid that there is not a single answer.

What I know is that if I select an enterprise architecture tool supporting both TOGAF 9.1 and ArchiMate 2.0, I would like to be able to be able to have a full synchronization. If I model a few ArchiMate models I would like my TOGAF 9.1 artifacts to be created at the same time (catalogs and matrices) and if I create artifacts from the taxonomy, I would like my ArchiMate models also to be created.

Unfortunately I do not know the current level of tools maturity and whether tools vendors provide that synchronization. This would obviously require some investigation and should be one of the key criteria if you were currently looking for a product supporting both standards.

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

This other possibility requires that you have an up to date Configuration Management Database and that you developed an interface with your Architecture Repository, your enterprise architecture tool. If you are able to replicate the relationships between the infrastructure components and applications (CIs) into your enterprise architecture tool that would partially create your traceability.

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

Achieving traceability within an Enterprise Architecture is key because the architecture needs to be understood by all participants and not just by technical people. It helps to incorporate the enterprise architecture efforts into the rest of the organization and it takes it to the board room (or at least the CIO’s office) where it belongs.

· Describe your traceability from your Enterprise Architecture to the system development and project documentation.

· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

If a development team is looking for a tool that can help them document, and provide end to end traceability throughout the life cycle EA is the way to go Make sure you use the right standard and platform. Finally, communicate and present to your stakeholders the results of your effort.

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

May 10, 2013May 8, 2013 by Serge Thorn

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

In Enterprise Architecture, traceability may mean different things to different people.

Some people refer to

· Enterprise traceability which proves alignment to business goals

· End-to-end traceability to business requirements and processes

· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities

· Requirements traceability which assists in quality solutions that meets the business needs

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

· Traceability between artifacts from business and IT strategy to solution development and delivery

· Traceability from the initial design phase through to deployment

· And probably more

The most relevant section is probably where in the classes of architecture engagement it says:

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

There may be five different ways to build that traceability:

· Manually using an office product

· With an enterprise architecture tool not linked to the TOGAF 9.1 framework

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

1. Manually using an office product

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Mapping the requirements to use cases and other information can be very labor-intensive.

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

4. With an enterprise architecture tool using ArchiMate 2.0

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

The example from the specification below documents the various architecture layers.

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

· Describe your traceability from your Enterprise Architecture to the system development and project documentation.

· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

Case Experiences and Best practices Using ArchiMate® and TOGAF®

March 25, 2013 by BizzDesign Staff

Implementing Enterprise Architecture in any organization requires an effective method and a consistent way of modeling to build architecture models. The Open Group standards <a title=”proven, comprehensive and generic methodology and framework” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/togaf/#The Open Group Architecture Framework”>TOGAF</a>® and <a title=”open modeling language for architects to model and communicate Enterprise Architecture” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/#Architects need a unified framework to describe enterprise architectures”>ArchiMate</a>® are used worldwide to implement Enterprise Architecture. TOGAF® focuses on the method of implementing and maintaining Enterprise Architecture. ArchiMate® is an Enterprise Architecture modeling language standard. A lot of organizations in various markets worldwide use (a a combination of) these standards.On 28-March-2013 I will present a webinar via <a title=”Leading the development of open, vendor-neutral IT standards and certifications” href=”http://www.opengroup.org”>The Open Group</a> in which I will give an overview of some real-life case experiences in using ArchiMate® and TOGAF® for implementing Enterprise Architecture. The approach, deliverables and examples of the several case studies will be shared. Furthermore, practical do’s and don’ts in adopting ArchiMate® and TOGAF® will be discussed. Attendees of this webinar will benefit from the lessons learned, and will learn which aspects are typically important to consider when implementing Enterprise Architecture in any organization.<a title=”Register for this webinar” href=”https://opengroupevents.webex.com/ec0606l/eventcenter/enroll/join.do?confViewID=1003593497&theAction=detail&confId=1003593497&path=program_detail&siteurl=opengroupevents”>Registration details</a> for this webinar can be found on the Open Group website. <div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600255-Togaf-archimate-repository-reference-models.png” alt=”Togaf archimate repository reference models” title=”During the webinar Rob Kroese will explain TOGAF and archiMate” width=”600″ height=”255″/>ArchiMate® and TOGAF®</div>

An Update on ArchiMate® 2 Certification

March 6, 2013 by Open Group

In this blog we provide latest news on the status of the ArchiMate® Certification for People program. Recent changes to the program include the availability of the ArchiMate 2 Examination through Prometric test centers and also the addition of the ArchiMate 2 Foundation qualification. … Continue reading →

EA Panel on Big Data and Cloud Trends Enabled by ArchiMate and TOGAF

March 2, 2013 by Mike Walker

I had had the pleasure of being on a panel of Enterprise Architecture (EA) experts at The Open Group Conference in Newport Beach, California. We were assembled to discuss complex trends such as big data, Cloud Computing, security, and overall…

Complexity from Big Data and Cloud Trends Makes Architecture Tools like ArchiMate and TOGAF More Powerful, Says Expert Panel

March 1, 2013 by Open Group

We recently assembled a panel of Enterprise Architecture (EA) experts to explain how such simultaneous and complex trends as big data, Cloud Computing, security, and overall IT transformation can be helped by the combined strengths of The Open Group Architecture Framework (TOGAF®) and the ArchiMate® modeling language. … Continue reading →

Delivering Business Value with Enterprise Architecture Using TOGAF® and ArchiMate®

February 19, 2013 by BizzDesign Staff

The last few years have been tough for many organizations, especially in (the aftermath of) the global economic turmoil. Getting to grips with the complexity of doing business is increasingly important. Many of the problems that organizations struggle with have similar characteristics. Consider for example:<ul><li>Business transformation has major impact on the organization, from work floor up to (top) management, ranging from process, organization structure, data, and IT infrastructure</li><li>Various solution alternatives for business- and IT problems are available and viable. Which alternatives will we pursue?</li><li>Business Units have concerns that do not always align. Both for change projects and for business as usual we see BU’s competing to meet their own targets rather than keeping an eye on common goals</li><li>Etc.</li></ul>In these cases it pays off to use Enterprise Architecture methods! On 21-February-2013 I will present a <a title=”Register if you would like to attent” href=”https://opengroupevents.webex.com/ec0606l/eventcenter/enroll/join.do?confViewID=1003476223&theAction=detail&confId=1003476223&path=program_detail&siteurl=opengroupevents”>webinar </a>in which I will show how <a title=”Specification TOGAF” href=”https://opengroupevents.webex.com/ec0606l/eventcenter/enroll/join.do?confViewID=1003476223&theAction=detail&confId=1003476223&path=program_detail&siteurl=opengroupevents”>TOGAF </a>and <a title=”Specification ArchiMate” href=”https://opengroupevents.webex.com/ec0606l/eventcenter/enroll/join.do?confViewID=1003476223&theAction=detail&confId=1003476223&path=program_detail&siteurl=opengroupevents”>ArchiMate </a>add business value. The combination of these open standards provides organizations with a balanced approach to EA with extensive tool support. <a title=”Register if you would like to attent the webinar” href=”https://opengroupevents.webex.com/cmp0307l/webcomponents/widget/detect.do?siteurl=opengroupevents&LID=1&RID=2&TID=11&rnd=3433236763&DT=60&DL=nl&isDetected=true&backUrl=%2Fec0606l%2Feventcenter%2Fenroll%2Fjoin.do%3FconfViewID%3D1003476223%26theAction%3Ddetail%26confId%3D1003476223%26path%3Dprogram_detail%26siteurl%3Dopengroupevents”>Registration details for this webinar</a> can be found in the Open Group website. If you are interested in the slides, you can download them on the right of this page. <div class=”captionImage left” style=”width: 600px;”><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600437-Agenda-Webinar-TOGAF-ArchiMate-Delivering-Business-Value.png” alt=”Webinar delivering business value with TOGAF and ArchiMate” title=”During this webinar we’ll teach you how to add value to your business” width=”600″ height=”437″/>Webinar Delivering Business Value with Enterprise Architecture Using TOGAF® and ArchiMate®</div></div>

Three Best Practices for Successful Implementation of Enterprise Architecture Using the TOGAF® Framework and the ArchiMate® Modeling Language

February 8, 2013 by Navin Anand

Reblogged from The Open Group Blog: By Henry Franken, Sven van Dijk and Bas van Gils, BiZZdesign The discipline of Enterprise Architecture (EA) was developed in the 1980s with a strong focus on the information systems landscape of organizations. Since … Continue reading →