BizzDesign Staff – Page 8

Enterprise Architecture Roadmap for success: Capability Based Planning

June 13, 2013 by BizzDesign Staff

This is the 12th posting of the enterprise architecture Roadmap for success blog series, before we wrap it up with an overview in the last posting. We have covered a wide range of topics so far, in this posting we zoom in on one of the most useful techniques in the field of strategic enterprise architecture planning: capability based planning.<div class=”captionImage leftAlone” style=”width: 337px;”><div class=”captionImage leftAlone” style=”width: 600px;”><img alt=”Capability Based Planning” class=”leftAlone” height=”375″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600375-Roadmap-for-success-capability-based-planning.png” title=”12th posting in the roadmap for succes series” width=”600″/>Part 12: Capability Based Planning</div></div>Capability based planning<img alt=”Capability Based Planning” class=”left” height=”139″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage150139-capability-based-planning.png” title=”It may take a long time to realize the architecture” width=”150″/>There are many ways to look at architecture as we have seen in this blog series. Generally, architectures of systems (in the broadest sense of the word) are fairly high level and focus on the fundamental organization of the system as well as principles underlying this fundamental organization.Especially for complex systems, it may take a long time to realize the architecture. Or, to put it in a different light, organizations may be smart and to cater for the fact that their long-term vision may change, deciding to take it one step at a time, allowing for the vision / architecture to change. This also takes into account the fact that organizations already have certain capabilities that they may wish / need to develop further in an incremental fashion. This is where Capability Based Planning kicks in.<h2>Capability Based Planning – the TOGAF™ way</h2>Many definitions for capabilities (and frameworks around capabilities) have been proposed and used in practice. In this post we zoom in on the TOGAF-framework which is fairly well aligned with other capability frameworks. The TOGAF-standard has two definitions for the term Capability, which can loosely be paraphrased with the statement “A capability is an ability that an organization, person, or system possesses”. Capabilities are typically ‘horizontal’ in the sense that they span many lines of business as is illustrated by the figure below (from <a href=”http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html” target=”_blank”>Chapter 32</a> of the TOGAF standard), but that is not always the case.<img alt=”TOGAF and Capability Based Planning” class=”leftAlone” height=”333″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600333-TOGAF-framework.png” title=”The TOGAF-standard has two definitions for the term Capability” width=”600″/>Two capability definitions in TOGAFThe idea is that an organization’s capability may be at a certain ‘level’ at some point in time. In order to further that capability – conform the Architecture Development Method – a new architecture is developed (using e.g. ArchiMate), which is fleshed out in more detail in a solution model (e.g. ArchiMate, UML, BPMN) before it is actually implemented:<img alt=”Capability, Architecture, Solution model” class=”leftAlone” height=”193″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600193-Screen-Shot-2013-04-26-at-11.32.44-.png” title=”a new architecture is developed (using e.g. ArchiMate), which is fleshed out in more detail in a solution model (e.g. ArchiMate, UML, BPMN) ” width=”600″/>Another important aspect of capabilities lies in the fact that they may have different ‘dimensions’. For example, <a href=”http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html” target=”_blank”>Chapter 32</a> of the TOGAF standard lists a people dimension, process dimension, and material dimensions for a given capability. In other words, when planning the next increment for our ability (i.e., the goal we want to achieve for this increment in the next ADM cycle), we should consider the ramifications for each of these dimensions.<h2>Modeling support</h2>Given the integration between ArchiMate® and TOGAF™, we feel that capability based planning also deserves proper modeling support. We are working on a simple meta-model to support capability based planning, the core of which looks like this: <img alt=”Capability based planning. A meta model” class=”leftAlone” height=”301″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/core-modeling-ArchiMate-TOGAF.png” title=”meta-model to support capability based planning” width=”422″/>This sample shows that capabilities may have one or more dimensions, and are realized by one of more increments, indicative of the different points in time. These increments are still conceptual in nature, and indicate points in time. Each increment may be realized by an architecture, expressed as a set of core concepts (<a href=”http://www.bizzdesign.com/blog/archimate-core-overview/” target=”_blank”>see our series on ArchiMate</a>). Using this simple meta-model we can create the following view:<img alt=”Capability with 5 different dimensions” class=”leftAlone” height=”299″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage500299-core-concepts-meta-model-ArchiMate-TOGAF.png” title=”Each increment may be realized by an architecture, expressed as a set of core concepts” width=”500″/>Here we see a capability with 5 different dimensions. In each of the four increments, the capability has a certain value that indicates ‘how good we are doing with respect to this capability’. As the analysis of this diagram may be hard, we propose a simple radar view as follows:<img alt=”radar view of capability” class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/customer-dimension-capability-increments.png” title=”Capability radar view” width=”350″/><h2>Use in practice</h2>In our experience, Capability Based Planning as a technique can be used in a many different settings. The main benefit of this approach lies in the combination of easy communication (capability is a term that management tends to understand well) while still allows for formal modeling and analysis. We have used it successfully in helping one of our clients in furthering their data management practice, linking the technique of capability based planning with the DAMA DMBOK framework. The DMBOK framework decomposes the data management capability into several sub capabilities such as data governance, master data management, Business Intelligence and so on. It also proposes to consider each capability from different dimensions which may lead to an assessment such as:<img alt=”Capability assessment” class=”leftAlone” height=”270″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage450270-DAMA-DMBOK-framework.png” title=”such diagrams communicate well and provide a solid basis for further analysis and realization” width=”450″/>Indeed, such diagrams communicate well and provide a solid basis for further analysis and realization (which steps will we take? When? What is the architecture that goes with each of these steps? How does this translate to projects that take us to the next level?).<h2>Next posting</h2>If you’d like to know more, please contact the authors directly at <a href=”mailto:b.vangils@bizzdesign.com” target=”_blank”>b.vangils@bizzdesign.com</a> / <a href=”mailto:s.vandijk@bizzdesign.com” target=”_blank”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next wraps up the series! It is scheduled to between 6th and 10th of May.

Data Management 3: Realization of Entities in applications

June 11, 2013 by BizzDesign Staff

This is the third blog post in the Data Management series. Last time we discussed the notion of subject areas and entities. This time we zoom in on the realization of these entities in applications.<img alt=”Content. Data Management part 3″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-realization-of-entities-in-applications.png” style=”width: 501px; height: 334px;” title=”Data Management part 3: Realization of Entities in applications”/> <img alt=”Data Management. Coverage analysis” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-Coverage-Analysis.jpg” style=”width: 150px; height: 114px; float: left;” title=”A “coverage analysis” will be the tricky part”/>One of the things we should be able to do is to create views that show which systems have data about a certain Entity. Similarly, we want to link our Entities to Processes. Going forward, we will use the term ‘Data Object’ to differentiate between the Entity in a business context and its data-counterpart. The ‘Attributes’ of Entities (see also our previous post), are reflected as ‘fields’ in their Data Object counterparts. A “coverage analysis” will be the tricky part: suppose that we have a Subject Area called ‘Customer’. The key Entity in this Subject Area is also called Customer with Attributes such as name, social security number etcetera. Other Entities are such things as shipping address, E-mail address, etcetera. There are two things we want to visualize for business stakeholders: <ol class=”ol1″><li class=”li1″>Which information with respect to a customer is relevant from a process perspective? Only name? Only Social Security Number? Both?</li> <li class=”li1″>Which information about a customer is stored in a system? One system may store the E-mail address of a customer, whereas the physical address may sit in another system</li></ol>We have call this a “coverage analysis” because: from a data governance perspective we want to make sure that all Entities in a Subject Area, as well as all Attributes of an Entity are represented somewhere in a System!This type of modeling is quite ‘standard’ in ArchiMate. There are separate concepts for BusinessObjects and DataObjects. Also, there is a standard way of relating the two, using a RealizationRelation. The fact that DataObjects have Fields is modeled using a CompositionRelation and more DataObjects. This is not a very ‘pretty’ solution. Especially when a data object has many fields, the visualization will quickly become cluttered. For example, 4 DataObjects with 3 Fields each ads up to at least 12 concepts and 12 relations which has a high visual complexity. Using graphical nesting will result in a much cleaner visualization.The standard way of modeling the relation between a system (ApplicationComponent) and a DataObject uses the behavioral concept of an ApplicationFunction. The idea is that an ApplicationComponent has (internal) behavior to manipulate DataObjects. While it is correct, and often useful to model Application Functions, for most visualizations it is equally useful to hide them and use a short-cut notation as follows:<img alt=”A model of application functions” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-model-application-functions.png” style=”width: 599px; height: 262px;” title=”model Application Functions”/>With respect to the coverage-type analyses mentioned previously, this could be done and visualized in many different ways such as:<ul><li class=”li1″>Select a Subject Area or an Entity and list (color view) all Data Objects that are associated with it</li> <li class=”li1″>Select a Subject Area or an Entity and show (color view) all Systems that manage a data object that is associated with this Subject Area or Entity. </li> <li class=”li1″>Select a Subject Area and highlight (color view) the entities that have an associated Data Object that is managed by some system</li> <li class=”li1″>Generate a CRUD-matrix that lists which Entities are accessed by which Process. Use the CRUD notation in the cells to show the nature of the access relation</li> <li class=”li1″>Select a Subject Area and create a CRUD-matrix as listed above</li> <li class=”li1″>Select a Subject Area and create a CRUD-matrix that shows which System manages (!) a Data Object that is a realization of an Entity that sits in that Subject Area. At the intersection of the columns and rows we should list the name of the Entity</li></ul>Modern tools such as BiZZdesign Architect make these analyses fairly straightforward and reusable. We mentioned techniques such as creating color views and generating tables. This functionality is available in our Enterprise Architecture tool BiZZdesign Architect, which can be downloaded here (30-day free, fully featured, trial license). If you would like a demonstration, please leave us a note!As a final thought for this posting: note that this list has a mix of different types of visualizations, such as diagrams and matrices. This is partly because of communication preferences of key stakeholders, but also because some results are easier to interpret in different formats. In the next posting we will dive into Data Governance with a strong focus on data stewardship (Data Stewards are generally considered to be the heroes of the field), so stay tuned!

EAM2013 Enterprise Architecture Management recap

May 30, 2013 by BizzDesign Staff

<img alt=”EAM congres 2013. Tekening door Frank Los” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130531_BasvanGils/EAM2013-drawing-by-frank-los.png” style=”width: 260px; height: 857px; float: left;” title=”Tekening door Frank Los”/>I had the pleasure of attending the <a href=”http://www.eam-congres.nl/” style=”font-size: 11px; line-height: 19px;” target=”_blank”>EAM2013</a> conference in Houten this year. The topic for the conference: “innovation through interconnection”. In my opinion, this took place on more than one level! Of course, the topics of the sessions covered it in detail. But more importantly, people indeed (re)connected at the EAM conference. For me, the day had a feel of a reunion mixed with great content and inspiration for the next year. As usual, the venue was great. For the first keynote from Cor Franke the main room filled up. With only a few seats left we discussed the merits and development of NORA, one of the most widely used reference architectures for (the Dutch) government. With a good discussions (both in the room as well as live on twitter, continued face to face over coffee) we set the tone for the rest of the day: good sessions, good discussions and a nice balance between academic rigor and practical relevance. Some highlights and trends:<ul style=” float: right; width: 395px; ”><li class=”li6″>There is still talk about architects struggling to get (enough) management attention and support. However, we’ve taken big steps as a community to improve the situation. This is mainly due to focus on results rather than frameworks, and taking our circle of influence / interest into account when trying to “get shit done” (the GSD-paradigm has made its way into the enterprise architecture community too!) Paraphrasing Dijkstra, it is safe to say that “enterprise architecture is as much about frameworks as astronomy is about telescopes”</li> <li class=”li6″>More attention for managing and using data in building a strong enterprise. The data-theme was covered / touched upon in several sessions but it was quite an inspiration to discuss it during the breaks with several people. Looking forward to the follow-up discussions!</li> <li class=”li6″>In several sessions we saw discussions on the interplay between “how we get organized” (functional organization? Process focus?) and the way our IT-landscape is organized (SOA? Using cloud?). Compared to other years, there appeared to be less discussion about the IT-aspects and more about the business impact. </li> <li class=”li6″>Not only on EAM, but also in twitter and the blogosphere we see a trend that more attention is given to the ‘soft skills’ of architects (“Should architects be more like Einstein or like Mandela?”). For more insights into this realm, check out “<a href=”http://www.amazon.co.uk/IT-Savvy-What-Executives-Must/dp/1422181014/ref=sr_1_1?ie=UTF8&qid=1369986542&sr=8-1&keywords=it+savvy” target=”_blank”>IT Savvy</a>”! </li> <li class=”li6″>Some other themes that made their way into EAM: OIAM as a framework for thinking about infrastructure architecture in a functional way, linking agile development to enterprise architecture, and the struggle of Ron Roozendaal to visualize the architecture on a massive (country) scale.</li></ul>Overall, the day was an inspiration. A good lunch helped, and so did the funny “visual summaries” of the sessions in the main room by sketch artist Frank Los (check out his <a href=”http://twitter.com/franklosdus” target=”_blank”>twitter feed</a> to see some of them – in Dutch) but it was the excellent content that did it for me. Looking forward to EAM2014!

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>

Data Management 2: Subject Areas and Objects

May 23, 2013 by BizzDesign Staff

This is the second blog post in the Data Management series and we will dive straight in with a discussion about subject areas and (information) objects, often called Entities. We start with a high-level overview of the theory and then dive into ArchiMate modeling.<img alt=”Subject Areas and Objects. Data Management blog series” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/Data-management-subject-areas-objects_424x283.png” style=”width: 424px; height: 283px;” title=”Data Management blog series. Part: Subject Areas and Objects”/><h2 class=”p1″>Theory</h2>A subject area model is used to differentiate between areas of interest from a data/ information perspective in the organization. These are called Subject Areas. Examples of subject areas are: customer, product, and supplier. This is not a new concept; it seems that it was introduced by James Martin in his books on Information Engineering in the late 1970s/ early 1980s. A Subject Area typically consists of 12-20 Business Subjects. These are the key areas of interest in the business domain. Simplifying slightly from the <a href=”http://www.amazon.com/Guide-Management-Knowledge-DAMA-DMBOK-Edition/dp/1935504029/” target=”_blank”>DMBOK</a> best practice, we use the concept of an Entity as a synonym for a Subject. Note that in fact we are talking about Entity Types rather than Entities (see the work of <a href=”http://www.amazon.com/Data-Reality-Perspective-Perceiving-Information/dp/1935504215/” target=”_blank”>Kent</a> for an extensive discussion of why this distinction is important). We focus on the type level, not the instance level. For purposes of readability, we will consistently use the term Entity rather than Entity Type. The following ORM diagram illustrates this point:<img alt=”Entity types related by means of a fact type” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/data-management-entity-types.png” style=”width: 202px; height: 110px; float: left;” title=”Two Entity Types (Person and Company) related by means of a fact type (“works for” with the inverse reading “employs”).”/>Here we see two Entity Types (Person and Company), each identified by their na,e. These are related by means of a fact type (“works for” with the inverse reading “employs”). The purple dot signifies the constraint that “each Company employs at least one Person”The population of this scheme in terms of Entities is visualized by the supporting table. Here we see for example that the label “Bas” identifies an Entity of the Entitiy Type “Person”. Business Entities are the ‘things’ we talk about in a business context. For example, the Subject Area ‘Customer’ would be decomposed in Entities such as customer, address, and purchase history, etcetera. One would typically make an ERD to show the relations between entities as well as constraints on these entities (for each order the customer supplies a shipping address and a billing address). This may be a bit too much at the architecture / ArchiMate level, but we should at least be able to tie in to an ERD.<h2 class=”p1″>Modeling</h2>In summary: we introduced and defined two concepts for information modeling that we will be using throughout this blog post series: <ul><li class=”li2″>Subject Areas, which are used to structure areas of interest from an information perspective, for example customer, or product; and,</li> <li class=”li2″>Business Entities (or just short: Entities), which are the key concepts or “things” that are part of a Subject Area, e.g. for the Subject Area customer: address or purchase history;</li></ul>In this part we describe how these concepts could be modeled in ArchiMate. This makes it possible to integrate model support for Data Management into the overall Enterprise Architecture expressed in the ArchiMate standard. Also, tool support such as BiZZdesign’s modeling and analysis tool for Enterprise Architecture, BiZZdesign Architect, can be leveraged for Data Management. It seems to make sense to model the Subject Area concept with the BusinessObject concept. In BiZZdesign Architect, we could add a profile to this concept so that we can distinguish them from regular BusinessObjects in the sense that they could have a different graphical shape. Along the same lines: Entities should be modeled using the BusinessObject concept. This does not require any further profiles, except for cases where the model also captures other types of business objects (i.e., non-informational objects) and we want to be able to distinguish between the two types. Two challenges remain:<ol class=”ol1″><li class=”li1″>Entities have Attributes. It may be very important to be able to represent the fact that we distinguish between “first name” and “last name” rather than simply using “name”. Since ArchiMate does not have a concept for Attribute, we propose to simply use a CompositionRelation to decompose BusinessObjects into its attributes. Domains, cardinality and optionality are not modeled at the ArchiMate level.</li> <li class=”li1″>Many organizations choose to explicitly model meta-data about Entities. For example: definition of the concept, relevant business rules and legislation, stewardship (as we will describe in a later posting) and so on. It seems to make sense to use the ‘Meaning’ concept for this. However, this quickly becomes tedious and will crowd the model. Also, some meta-data is represented by the fact that BusinessObjects are linked to other ArchiMate concepts in the model. We will get back to the meta-data discussion in a separate post! </li></ol>To provide a link with the design level, it makes sense to relate Subject Areas to more detailed ERD models. To do this, we have recreated the basic Chen ER diagramming notation as a separate meta model in Architect which allows us to do the following:<ul><li class=”li2″>A Subject Area as modeled in the ArchiMate world is refined in an ERD view</li> <li class=”li2″>An Entity as modeled in the ArchiMate world is equal to an entity in an ERD view</li></ul><img alt=”Subject area and entity modelled in ArchiMate ” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/Data-management-ArchiMate-model-package_599x274.png” style=”width: 599px; height: 274px;” title=”Subject Area as modeled is refined in an ERD view in ArchiMate. An Entity is equal to an entity in an ERD view in ArchiMate”/>In the next posting in this series we will describe how entities are realized in applications. As always: if you have questions or suggestions, please drop us a note. Stay tuned!

Implementation-independent design of business logic, integrated with business processes and information

May 16, 2013 by BizzDesign Staff

BiZZdesign has a long tradition in model-based design and improvement of organizational processes. Building on this tradition, we have extended our portfolio with a method and tool for implementation-independent design and analysis of business logic, which seamlessly integrates with business process and information design.<h2 class=”p1″>Why yet another modeling domain?</h2>A problem that many organizations are facing is that the rules originating from legislation or business policies eventually end up in many different places in the organization, with many opportunities for misinterpretation along the way. The resulting business logic is hidden in business processes or hard-coded in software, which makes it very inflexible and hard to manage. Although most of the current business rules approaches promise to offer a solution to this problem, by “separating the know from the flow”, this promise is often not fulfilled, due to a number of reasons:<ol><li>There is still a lot of confusion as to what a business rule actually is, and what different types of business rules exits.</li> <li>Business rules are often specified in a very detailed way, in one of the proprietary languages of a rule engine. As a result, they usually have a technical 'technical’ flavor, which makes it difficult for business stakeholders to verify them, and they are tied to a specific implementation platform.</li> <li>Business rule specifications, and the tools that support them, are often poorly integrated with the existing process and information models and tools.</li></ol>When modeling your business logic, business processes and information as separate, coequal domains, loosely coupled through a limited set of linking elements, the resulting designs become much more flexible and manageable. By first specifying them in an implementation-independent way, it becomes easier to verify whether a design actually meets the requirements of the business. And once there is agreement on the correctness of the design, different implementations can be derived from it.<h2>Towards an integrated design</h2>As illustrated in the picture below, your business processes, information and business logic can be developed in separate design ‘flows’, in an arbitrary order; but ultimately, these flows will have to come together, to form an integrated design of your organization:<img alt=”The integration of Decisions, Processes and Information” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130517_Implementation-independent-design/Integrated-decision-modelinglegenda.jpg” style=”width: 607px; height: 550px;” title=”Integrate Decisions, Processes and Information”/>For the implementation-independent design of business processes, we use our proprietary modeling language Amber or the BPMN 2.0 standard. For information modeling, a wide variety of formalisms is available, e.g., Entity Relationship diagrams or UML class diagrams. To complete the trio, we have adopted The Decision Model, as described in the book “The Decision Model: A Business Logic Framework Linking Business and Technology” by Barbara von Halle and Larry Goldberg, as our language of choice for designing the business logic. This approach turned out to be perfectly suited for our purpose. It matches a simple graphical notation to model the decision structure with an intuitive tabular specification of the business logic and a rigorous set of integrity principles. Moreover, it can be combined with business process models and information models in a natural way.<h2>The Decision Modeler</h2>On June 11th, we will launch <a href=”http://www.bizzdesign.com/tools/the-decision-modeler/”>The Decision Modeler</a>, our software tool a tool for implementation-independent modeling and analysis of business logic based on The Decision Model. Because the tool is part of the BiZZdesign design suite, decision models can be linked to other models in this suite, including business process and information models, but also enterprise architecture models and requirements models in the ArchiMate language.The figure below summarizes how the different elements of a decision model in The Decision Modeler are related to each other, and to element from process and information models.<img alt=”” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130517_Implementation-independent-design/The-Decision-Modeler-relations.png” style=”width: 600px; height: 468px;” title=””/>In my next blog in this series, I will give a more in-depth description of the concepts and functionality of The Decision Modeler, and apply the approach described here to a real-life example. In the meantime, if you have any questions or suggestions, please send me an e-mail on <a href=”mailto:h.jonkers@bizzdesign.com” target=”_blank”>h.jonkers@bizzdesign.com</a>, or add a comment below.

From Business Design to Business Change (#3) – The Learning Circle

May 14, 2013 by BizzDesign Staff

Let us suppose you are to consult in the redesign of the ‘Incident Management’ process in a business-IT environment. This is not necessarily rocket science. But what do you do when the managers of the six different teams involved in the process have overlapping views on the roles of their teams? How do you avoid the pitfall of endless discussions on roles and responsibilities between teams and business units? And how do you take advantage of the involvement of the employees to arrive at a workable and acceptable solution?The case I write about in this blog is situated in a governmental service organization, 15k+ employees, where a restructuring of the organization required this cross-business unit redesign. This case represents a nice example of how I recently encountered the <a href=”http://www.bizzdesign.com/blog/from-business-design-to-business-change-1-the-content-paradox/” target=”_self”>content paradox</a>.<img alt=”” class=”right” longdesc=”Improvisation on television” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130515_From-Business-Design-to-Business-Change-3/Business-design-business-change-improvisation_large.jpg” style=”width: 180px; height: 124px; float: right;” title=”Improvisation. Dutch TV show the Lama’s”/>A traditional design approach would start out by trying to define a design scope and process requirements by interviewing stakeholders. We assumed this approach would be a one-way ticket to views a world apart. We looked at other options and our good experiences with <a href=”http://www.bizzdesign.com/blog/business-games-1-of-4-why-and-when-of-gaming/” style=”font-size: 11px; line-height: 19px;” target=”_self”>serious gaming</a> came to mind. What I personally like about it is that participants are caught in the moment and have to improvise. Sensible decisions and behaviour just arise. We used this effect to kick-start our design process. We organised what we called a Learning Circle with participants from each team. <h2>The Learning Circle</h2>We planned a full day for the Learning Circle workshop. We had one of the team managers as the sponsor for our approach. He asked all other team managers to send two or three employees to participate, in total about fifteen people. The participants had no idea what to expect and came without preparation. The workshop had three parts:<ul><li class=”li1″>The first part of the session was the gaming-part. We started from scratch with a simulation, as if the future process was already there. The idea was to just see what would happen, to experiment and to harvest the issues that would naturally arise.</li> <li class=”li1″>The second part of the session was the dialogue-part. For every issue teams were asked to share their view with the other teams. No discussion, just sharing of truths.</li> <li class=”li1″>The third part of the session was the solution-part. The participants were split into two groups with all teams represented in both groups. The groups were asked to come up with a draft proposal addressing as much issues as possible. Issues could also be put in the ‘for management to decide’ box.</li></ul><h2 class=”li1″>The gaming part</h2><img alt=”” class=”right” longdesc=”Learning Circle” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130515_From-Business-Design-to-Business-Change-3/Learning-Circle-workshop-set-up_large.png” style=”width: 171px; height: 180px; float: right;” title=”Learning Circle workshop set-up”/>The participants were seated into a half circle, grouped in teams, facing a number of flip over sheets put on the wall. We asked the participants to imagine as if the process to-be was already in place and they were performing their future roles already – whatever that might be. In case of doubt we asked them to act the way they would find most logical or sensible for the organisation as a whole and its (internal) customers.We triggered the incident process by presenting typical incident calls and handing over a marker pen to the team that first indicated they would receive it. The rules of the game were simple:<ol><li>The team with the marker pen decides how they act themselves and which team they trigger next by handing over the marker pen.</li> <li>The team with the marker pen is allowed to discuss among themselves what to do. The other teams are to remain silent</li> <li>The team with the marker pen writes down on the flip over sheet which activities they perform (if any!) and what result or information they pass on to which team</li> <li>All other participants are allowed at any time to come forward, in utter silence, with a sticky note with their initials. They can place it on the flip over sheet on the spot where they want to raise an issue (or question).</li></ol><img alt=”” class=”left” longdesc=”The power of silence” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130515_From-Business-Design-to-Business-Change-3/Learning-circle-the-silence-rule_medium.gif” style=”float: left; width: 120px; height: 113px;” title=”The best and most fun part was the silence rule”/>The harvest of the gaming part was rich. A process developed spontaneously and at the same time the astonishing number of 28 issues were already raised during the handling of the first incident alone – but no panic at all. The best and most fun part was the silence rule. With some small interventions from our side and some grinning of team members even the most control-freaky participants were able to zip it, just let it happen and use their – silent – sticky notes. <h2>The dialogue and solution part</h2>After the game we saw curious and smiling faces going for the coffee break. With the notion that each participant would get their turn on expressing their views the atmosphere had become open and calm. After the break issue per issue was addressed. Participants were amazingly patient with each other and interruptions were rare. The result was interesting: without making agreements it was clear that most issues could be resolved. The role of one team appeared to be almost completely omitted in the simulation of the process. Yet the dialogue part gave this team a great platform to position with their tasks themselves in a way that was logical and sensible for the other teams. After sharing six separate truths in a dialogue, the two groups had a good go at resolving the issues and their first ideas were presented. <h2 class=”p1″>Follow-up of the Learning Circle</h2>With just a few issues to be resolved, the overall result was a great kick-start. It brought about a good energy among participants who brought this feeling across to their respective team managers. Next we, as independent consultants, formulated a number of recommendations on the redesign for management. We based this on the results of the Learning Circle. We organised a management meeting to have them decide on these recommendations. We asked the participants to prepare this meeting with their team manager. The managers were happy that a lot of issues were already tackled by their employees. The open energy was also present on this table. It took management two meetings to resolve all redesign issues and start the implementation. <img alt=”” class=”left” longdesc=”How to bring these different truths together” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130515_From-Business-Design-to-Business-Change-3/How-to-bring-different-truths-together_700x184.png” style=”width: 700px; height: 184px; float: left;” title=”All in all it was not about “which team is right?”, but more about “how to bring these different truths together?””/><h2 class=”p1″>In conclusion</h2>In a traditional design approach it is good practice to test a business process design when it is finished in a simulation workshop with employees. In the case above we turned it around! We used the Learning Circle as an open experiment to speed up the design process with a lot of parties involved. Each participant brought along their own mix of ideas, stakes, insecurity on the outcome, personal preferences and historical context. Still, we noticed everyone was in his or her own way committed to deliver a good service in the end. All in all it was not about “which team is right?”, but more about “how to bring these different truths together?”.

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!

Three Decision Model Predictions and The Decision Modeler

May 5, 2013 by BizzDesign Staff

<a href=”http://www.kpiusa.com/index.php/The-Decision-Model/the-decision-model.html”>The Decision Model</a> (TDM) is new and rapidly growing methodology and framework for modelling the business logic (business rules) behind business decisions, using a powerful graphical notation, that is easy for both business and IT to understand and implement.<img alt=”” class=”right” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130506_Three-Decision-Model-Predictions-and-The-Decision-Modele/Decision-Modeler-Method-KPI.png” style=”width: 120px; height: 124px; float: right;” title=””/>The Decision Model was co-invented by <a href=”http://www.linkedin.com/in/larrygoldbergkpi” style=”font-size: 11px; line-height: 19px;”>Larry Goldberg</a> and <a href=”http://www.linkedin.com/pub/barb-von-halle/1/7ab/130″ style=”font-size: 11px; line-height: 19px;”>Barbara von Halle</a>, who are the co-authors of the seminal book <a href=”http://www.amazon.com/Decision-Model-Framework-Technology-Management/dp/1420082817″ style=”font-size: 11px; line-height: 19px;”>“The Decision Model: A Business Logic Framework Linking Business and Technology“.</a> In early January 2012, I made <a href=”http://www.azintablog.com/2012/01/08/three-predictions-for-the-decision-model-in-2012/”>three predictions</a> about the urgent need for a low cost software tool that would support the modelling of TDM models, and, that this tool would be available by the end of 2012.It is now 5 months after my original predictions were expected to be fulfilled and this blog post briefly outline the three original TDM predictions and compare them with the functionality of the new TDM tool, The Decision Modeler, which will be launched in early June 2013 by <a href=”http://www.bizzdesign.com”>BiZZdesign</a><h2><img alt=”” class=”right” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130506_Three-Decision-Model-Predictions-and-The-Decision-Modele/the-Decision-Modeler-logo.jpg” style=”width: 100px; height: 120px; float: right;” title=””/>My Original Decision Model Prediction 1</h2>By the end of 2012 a low cost entry-level TDM modelling tool will exist that will enable modellers to create and validate that their TDM models comply with the TDM 15 principles. There is currently only one tool that has this capability and that is the <a href=”http://www.sapiensdecision.com/”>heavy-weight Sapiens DECISION tool.</a> DECISION is designed for enterprise TDM modelling, life-cycle management and governance.My reasons for an entry-level low cost TDM modelling tool are:<ul><li>There are a large number of small to medium size companies who in the coming months and years would like to use TDM but who will not be able to afford heavy-weight tools such as Sapiens DECISION. Using Excel and Visio for TDM modelling is better than nothing but a modelling tool with proper validation would be much better.</li> <li>Many departments in many large companies may still like to experiment with TDM using a low-cost entry tool to get started and after the success of an initial TDM project move up to governance products such as Sapiens DECISION.</li> <li>Having a low-cost or open source TDM modelling tool will empower many thousands to experiment on their own and drive the bottom-up adoption of TDM within organisations of all sizes.</li></ul><h2>My Original Decision Model Prediction 2</h2>By the end of 2012 a low cost TDM model translator will exist that will be able to automatically convert high-level graphical TDM models into actual “business rules code” for a number of business rules engines.This tool will enhance the productivity of business rules programmers and ensure that Decision Models are converted without error into code that can execute within different rule engines.<h2>My Original Decision Model Prediction 3</h2>From my perspective Business Decision Management = BPMN + TDM. It is therefore my prediction is that by end of 2012 that a low-cost entry tool will exist that will enable business analysts and TDM modellers to model TDM and BPMN process models in an integrated modelling environment. Let’s not forget that actions required to be executed on completion of a TDM decision should be executed within a BPMN process task. See The Decision Model Book by Barbara von Halle and Larry Goldberg. Also for more information on the integration of TDM with BPMN process models see the <a href=”http://brsilver.com/integrating-process-and-rules-part-2/”>BPMN guru Bruce Silver’s blog post</a><h2>The Three Predictions and The Decision Modeler</h2>At the time that I made these prediction I was not aware that BiZZdesign was about to embark on developing a TDM tool. It was only until the autumn of 2012 that I became aware of BiZZdesign TDM plans and finally an alpha version of the tool was available by end of 2012.So how does BizzDesign’s The Decision Modeler compare with the three TDM predictions?<ul><li>TDM Prediction 1 and The Decision Modeler – BiZZdesign’s The Decision Modeler is priced at around $5,000 for a single user licence and later a lower priced SaaS/Cloud version is planned. The Decision Modeler current checks for some of the 15 principles, including the structural principles and some other checks. In forthcoming releases the software will validate for all the 15 principles. I can therefore confirm that The Decision Modeler meets TDM Prediction 1.</li> <li>TDM Prediction 2 and The Decision Modeler – BiZZdesign has the ability to export TDM models into Excel format that enables TDM models to execute on the <a href=”http://openrules.com”>OpenRules open source business rules platform</a>. The ability to export to other business rules platforms such as Drools and ILOG are on the roadmap. I can therefore confirm that The Decision Modeler meets TDM prediction 2.</li> <li>TDM Prediction 3 and The Decision Modeler –The Decision Modeler has excellent integration with process modelling tools. Both BPMN 2.0 standard and proprietary Amber process modelling languages are fully supported and integrated with The Decision Modeler into an integrated modelling environment. I am therefore very pleased to say that the Decision Modeler fully implements TDM Prediction 3.</li></ul>The Decision Modeler enables a TDM modeller view all the process models that are using a specified TDM model. From a process model, one can click on a business decision task and automatically view the associated TDM model. No other TDM tool has this tight execution with process models, out of the box, as does The Decision Modeler.I can therefore confirm that The Decision Modeller meets all the three TDM Predictions.Given that TDM is rapidly revolutionising enterprise business decision management, by enabling the business to re-gain control of the business decisions that business managers are responsible for managing, I believe that the Decision Modeler will have a significant impact by reducing the costs of engaging with TDM.<h2>Future Predictions for Decision Modeler</h2>It is my view that the Decision Modeler, including the integration of TDM with other BiZZdesign modelling tools and languages will rapidly grow from strength to strength in subsequent releases. It is my prediction that BiZZdesign will become the de facto modelling tool for doing TDM modelling within the enterprise.The second post in the 3-part series will look at how BiZZdesign has integrated TDM with its other modelling tools and languages and some of the implications of this integration for the business and IT.In the olden days, thousands of years ago, prophets who made predictions that did not materialise were either ignored or more often stoned to death as false prophets. So my thanks BiZZdesign for developing its TDM product, The Decision Modeler, just in time!By <a href=”http://suleiman.shehu@azinta.com”>Suleiman Shehu</a>Suleiman Shehu is the CEO, of Dublin based <a href=”http://www.azinta.com”>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. The <a href=”http://www.azintablog.com/2012/01/08/three-predictions-for-the-decision-model-in-2012/”>original article on the three TDM predictions can be viewed.</a>

Data Management: Introduction

May 5, 2013 by BizzDesign Staff

The topic of Data Management (DM) is increasingly important for many organizations. Much has been researched and written in this field, both from a business and a technical perspective. For example:<ul><li><a href=”http://www.amazon.com/The-Data-Asset-Companies-ebook/dp/B002JMV6LY”>The Data Asset</a> by Tony Fisher presents a strong argument for considering data from a business perspective and argues the case that quality data is quintessential for sustainable business success</li> <li><a href=”http://www.amazon.com/Master-Data-Management-Press-ebook/dp/B001FA0HAM/”>Master Data Management</a> and <a href=”http://www.amazon.com/Practitioners-Guide-Quality-Improvement-ebook/dp/B004HD63OS”>The Practitioner’s Guide to Data Quality Improvement</a> by David Loshin provide an excellent technology independent overview of several key aspects of data management with attention for business and technology concerns</li> <li>The <a href=”http://www.amazon.com/Management-Knowledge-DAMA-DMBOK-Portuguese-Edition/dp/1935504177/”>DAMA DMBOK</a> is considered to be the most comprehensive overview of the field of data management in existence</li></ul>It is increasingly recognized that enterprise architecture (EA) models are a valuable tool in this field. At the recent MDM/DG summit, hosted by IRM UK, (see also our previous <a href=”http://www.bizzdesign.com/blog/mdm-dg-summit-recap/”>blogpost</a>) it was agreed that:<ul><li>Architects and Data Management Professionals often talk to the same stakeholders</li> <li>Share a common mindset, tools,and models</li> <li>Tackle similar issues</li></ul>Given BiZZdesign’s proposition in this field with ArchiMate and Architect, it makes sense to investigate how ArchiMate can be leveraged in the field of Data Management – at least from a modeling perspective. Obviously, the Data Management -space covers much more than models but that is beyond the scopeof this series. This subject is too large to tackle in one go though, so we follow an incremental approach and tackle various aspects one by one, as depicted in the figure below:<img alt=”Data management. Incremental approach” id=”” longdesc=”An incremental approach to tackle various aspects one by one” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130506_Data-Management-Introduction/Data-Management-Incremental-approach.png” style=”width: 550px; height: 334px;” title=”An incremental approach to tackle various aspects one by one”/>For each aspect we will give a short introduction describing context and relevance, after which we explore the relevant modeling concepts and how they could be translated to ArchiMate:<ul><li>Subject Area & objects: an overview of how the information landscape can be subdivided into coherent subject areas, which can be decomposed into business entities</li> <li>Realization of Entities in applications: entities represent business concepts, and may be realized by some IT system. In this post we will show how to model this</li> <li>Stewardship: a steward is the person responsible for the quality of information, i.e. the entities that are part of a subject area</li> <li>Mastering data: many organizations have dispersed data about key entities. It is not uncommon for these versions to mismatch. Master Data Management (MDM) is about creating a master record for these key entities</li> <li>Meta Data: meta data is often defined as data about data. This is a broad discipline which covers various topics including business- and technical metadata</li> <li>Business Intelligence: is a discipline in its own right. Loosely defined it is the discipline that is concerned with providing management with the ‘intelligence’ necessary to run the business. It is often associated with such things as an Enterprise Data Warehouse.</li> <li>We end the series with:an overview of the relevant concepts from the ArchiMate metamodel and provide an idea of what advanced / custom visualization in this context would look like.</li></ul>Stay tuned for the next posting in which we dive into the “meat” of the series. If you have a question or suggestion, please leave a comment.

Building Networks with Business Models: Two approaches that will help you to understand and improve your value network

April 28, 2013April 15, 2013 by BizzDesign Staff

In an earlier posting we addressed <a href=”http://www.bizzdesign.com/blog/7-applications-of-the-business-model-canvas/”>7 applications of the Business Model Canvas</a>. Sure, we can agree that the Business Model Canvas is very useful for establishing, evaluating and reinventing businesses. But we should not only highlight the countless possibilities of it for a single enterprise. We need to synthesize our understanding of Value Chains and the Business Models and look for the next level of analysis: Value Networks.In this blog we will highlight a less addressed aspect from the Business Model Canvas that is rooted in Value Network thinking. There are multiple methods and even tools that support the analysis of Value Networks which is regarded as the collaborations, interactions, and exchanges between business actors. You might have heard or read about <a href=”http://www.amazon.com/Mobile-Service-Innovation-Business-Models/dp/3540792376″ target=”_blank”>STOF</a> and <a href=”http://e3value.few.vu.nl/” target=”_blank”>e3-value</a>. But apart from academic research, Value Networks are less represented in practical settings today. Why? Because of the rapidly increasing complexity of Value Networks – soon we lose track when we think about relations between multiple actors involved in our business such as suppliers, customers, governments, partners, NGO’s. Therefore in this blog we will explain how the simplicity of Business Model Canvas can be used to highlight Value Networks. We discuss an external network approach as well as a more internally oriented network approach.<h3>The network is the challenge</h3>Imagine a pension fund with three business units – one for asset management, one for customer advice and a third one for customer relationship management and administration – that attempts to broaden its service offerings. We can use the Business Model Canvas to guide this effort. First, we establish the pension fund’s current Business Model Canvas. Then we formulate our goal – which is to broaden the current service offerings. Step by step we elaborate desired Business Model Canvases that include different new service offerings. Finally we selected the most feasible Business Model Canvas for implementation. Business as usual – except that until now we have limited ourselves to only the Business Model Canvas of the pension fund.<div class=”captionImage leftAlone” style=”width: 561px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/business-model-canvas-pension-fund.png” alt=”Business Model Canvas pension fund” title=”The main goal is to reach our customers, provide them with our value proposition, and get paid” width=”561″ height=”417″/>three main elements of the business model canvas: key partners, enterprise and customers</div>Although external elements like key partners (1) and customers (3) are included in the Business Model Canvas, at the end of the story the emphasis is on the business model of a single enterprise (2). It seems that key partners are just there to be included in our Business Model Canvas. We also take customers for granted. The main goal is to reach our customers, provide them with our value proposition, and get paid.Today more than ever, an isolated view on an organization is not feasible. We are not suggesting that the Business Model Canvas only provides an isolated view. Instead, we want to add some additional support to the Business Model Canvas to broaden and deepen its application from the perspective of Value Networks. This support comes in the form of a Networked and an Aggregated Business Model Canvas.<h3>The chained network approach</h3>Lets think about the pension fund example again. In addition to the single enterprise view of the Business Model Canvas we should also consider the canvases of our partners and customers for broadening our service offerings. That way we will be able to highlight the interactions of the pension fund and its actors for the sake of the pension fund and its actors –so basically focusing on the Value Network instead of a single company in order to retrieve additional insights that might not be highlighted through a single Business Model Canvas. <div class=”captionImage leftAlone” style=”width: 600px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600210-canvases-of-partners-and-customers.png” alt=”chained network approach” title=”Does the entire Value Network benefit from newly offered services of the pension fund?” width=”600″ height=”210″/>consider the canvases of our partners and customers for broadening our service offerings</div><div class=”captionImage leftAlone” style=”width: 561px;”><div class=”captionImage leftAlone” style=”width: 561px;”>By representing the Value Network through Networked Business Model Canvases we could answer new questions like: How can we broaden our service offerings through the current Value Network? What improvements can we implement? Does the entire Value Network benefit from newly offered services of the pension fund?</div></div>Now we are able to involve our partners as well and benefit as a group from the applications of the Business Model Canvas by:<ul><li>considering the potential improvement for all value network actors;</li><li>identifying (un)equal distributions of risks, costs and profits for actors based on changes in the value network;</li><li>and using the capabilities and knowledge of all actors to improve the value network;</li><li>Address opportunities of <a href=”http://en.wikipedia.org/wiki/Disintermediation” target=”_blank”>disintermediation</a> concerning removal of intermediaries from a value chain;</li><li>Apply (elements of) the unbundling pattern (page 62), concerning specialization. In commoditizing markets successful organizations focus on either Product Innovation, Customer Relationship Management or Infrastructure Management. Also see <a href=”http://www.amazon.com/Discipline-Market-Leaders-Customers-Dominate/dp/0201407191″ target=”_blank”>Tracy & Wiersema’s value disciplines</a> and <a href=”http://en.wikipedia.org/wiki/Porter_generic_strategies” target=”_blank”>Porter’s generic strategies</a>.</li></ul><h3>The aggregated network approach</h3>In addition to a networked Business Model Canvas we can also establish an aggregated Business Model Canvas for the pension fund. Think about the individual business units that are part of the pension fund. While customers may perceive the pension fund as one entity, business units could be independent in terms of their financial performances. Each business unit operates independently and is responsible for own results and achievements. However, because all business units are part of the same pensions fund, the might be using each other’s assets, serve similar customers and share similar partners. Actually a customer could be advised by one business unit on his savings and investment plans, while the same investments could be managed by the assets management business unit. Along the process the customer wants to experience being served consistently by one organization – the pension fund – instead of separate business units. Providing such consistency is obviously important for the pension fund and its business units. But how can they start addressing related issues? And all business units have other internal and external customers as well….That is when the aggregated Business Model Canvas comes into play. First we need to establish the individual Business Model Canvases of the pension fund and its business units. Then we need to examine the relations between building blocks across the network by connecting the Business Model Canvases. <div class=”captionImage leftAlone” style=”width: 600px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600219-Aggregated-Business-Model-Canvas.png” alt=”aggregated Business Model Canvas” title=”Along the process the customer wants to experience being served consistently by one organization instead of separate business units” width=”600″ height=”219″/>The aggregated business Model Canvas asks more questions</div>Again this allows us to answer additional questions like: How can we improve our corporate business model? Is each business unit aligned properly with the corporate organization? What similar partners are used by the different business units? Do we collaborate sufficiently to provide consistent service quality to our customers? Where are opportunities for synergy?Now we are able to understand our internal model and consider our business models as complementary parts of the same aggregated model. Benefits of applying this internal network approach are:<ul><li>Aligning the whole with its parts</li><li>Learn from each other: using the capabilities and knowledge of all actors to improve the network</li><li>Understand and learn how costs and value creation are distributed throughout the organization in more detail then seen when only creating an enterprise view</li><li>identifying (un)equal distributions of risks, costs and profits for business units based on changes in the value network;</li><li>Understand and manage differences in the business unit’s business models</li><li>Understand and benefit from synergies between the different business models</li></ul><h3>Conclusions and advice for applying business model networks in practice</h3> Supported by the alternative application suggestions of het Business Model Canvas discussed above, we recommend you to:<ol><li>Establish your current business model canvas</li><li>Establish the business model canvases of your internal and external customers</li><li>Establish the business model canvases of your internal and external partners and suppliers</li><li>Interconnect and aggregate the business model canvases</li><li>Assess the effectiveness of the network in term of experienced pain and gain by each partner</li><li>Elaborate opportunities to improve the networks performance as a whole</li><li>Work out these opportunities by following each dependency relation through the network, taking into account pains and gains addressed by each actor in the network</li><li>Establish an integrated implementation plan for the whole</li><li>Establish detail implementation plans for each partner</li></ol>Whether the additional Business Models concern internal or external customers and partners, in both cases you will benefit from the additional insights – you will improve your understandings of your own business model as well as the business models of your stakeholders and together you will be able to identify improvement opportunities in your value network. At the end of the day no business operates on its own. Every organization has to collaborate to different extends with multiple actors. Trends that are already here to stay, and trends that should be on your agenda today, all underline the importance of collaboration and require insight in your network. Supply chain management, co-creation, open innovation, knowledge sharing, social enterprise, big-data, predictive analytics. “Understanding your business model is only a first step in understanding your value network.”We look forward to helping you achieve your goals in the new, networked, normal! BiZZdesign organizes <a href=”http://www.bizzdesign.com/training/business-model-management/”>training on Business Model Innovation</a> in London (UK), Brussels (BE) and Amersfoort (NL – <a href=”http://www.bizzdesign.nl/training/business-model-management/”>see our Dutch website</a>). More about BiZZdesign’s Business Model Management services, examples and a reference to recent webinars on this subject can be found <a href=”http://www.bizzdesign.nl/consultancy/business-model-management/”>here</a>. Feel free to download the <a href=”http://www.bizzdesign.com/tools/business-model-canvas-module/”>free trial version of our Business Model Canvas tool</a> from our website.

From Business Design to Business Change (#2) – Be John Malkovich!

April 10, 2013April 2, 2013 by BizzDesign Staff

What interests me is that in many cases success in our work is not about the content per se (see <a style=”font-size: 11px; line-height: 19px;” title=”From Business Design to business Change” href=”http://www.bizzdesign.com/blog/from-business-design-to-business-change-1-the-content-paradox/#Blog series: business design to business change”>post #1 </a>of this series). Let me start this blog by recommending a somewhat strange, but brilliant and award winning movie ‘<a style=”font-size: 11px; line-height: 19px;” title=”1999 American comedy-fantasy film written by Charlie Kaufman and directed by Spike Jonze” href=”http://en.wikipedia.org/wiki/Being_John_Malkovich”>Being John Malkovich</a>’. It is – quite literally – about entering the head of John Malkovich. This is exactly what I try to keep in mind when meeting new clients. Seeing reality through John’s eyes. It became my associative reminder: “Be John Malkovich, be [Client’s Name]! “. <div class=”captionImage left” style=”width: 214px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Being-john-malkovich.png” alt=”Being John Malkovich” title=”There is not one reality” width=”214″ height=”317″/>Be aware of the subjective reality in business change</div> Although of interest, I do not just mean diving into the requirements regarding my client’s business problem – this is all content. What I mean is taking it a step further. What drives my client? What are his/her fears or frustrations? What are his/her shortcomings? What is the meaning of this context for my design approach? I have experienced that having a somewhat deeper understanding of my client’s pain and gain (see below) pays off. It has improved my approach towards a business solution and has helped me gaining trust and acceptance. The Empathy Map below has, apart from my John-motto of course, helped me in changing my perspective.<h2>The Empathy Map</h2>The Empathy Map is a technique developed by <a title=”Go to the EXPLANE website” href=”http://www.xplane.com/”>XPLANE</a> and presented in the book <a title=”Book: business Model Generation” href=”http://www.amazon.com/Business-Model-Generation-Visionaries-Challengers/dp/0470876417/ref=sr_1_1?s=books&ie=UTF8&qid=1280587028&sr=1-1″>Business Model Generation</a>. It looks like this:<div class=”captionImage leftAlone” style=”width: 600px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600456-empathy-map-for-business-design.png” width=”600″ height=”456″ alt=”” title=””/>Empathy map</div>The Empathy map is most often used to develop imaginary client profiles for customer segments. I used it for the first time in the field of <a title=”Business Model Management” href=”http://www.bizzdesign.com/consultancy/business-model-management/”>business model management</a>. I find it equally powerful for existing individual clients. It is a collaborative tool for teams (workshops) but I use it for myself on the back of a napkin as well. The following is what I do to get inside my client’s head. Please note I adjusted some of the standard questions in the technique to fit my purpose here: 1. Tape a big flip over sheet to the wall, in landscape orientation; 2. Draw the head of the manager in the centre – with resembling characteristics for more empathy, and fun – and draw the template around it, with keywords. You can also download the <a style=”font-size: 11px; line-height: 19px;” title=”Download the empathy map poster in PDF” href=”http://ebookbrowse.com/empathy-map-poster-pdf-d341627585″>empathy map poster template</a> and print a poster; 3. Enter the client’s head and answer the following questions one by one by placing sticky notes on the sheet (in this order).<div><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600279-empathy-map-questions-for-business-design.png” alt=”Empathy map questions” title=”Ask these quentions about your client” width=”600″ height=”279″/></div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div> </div> 4. Analyse the results above, and answer the following questions:<img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600172-empathy-map-final-questions-for-business-design.png” alt=”Empathy map questions” title=”Final quentions about your client” width=”600″ height=”172″/> <h2>The result</h2>Below I present a case I made anonymous. Let us call my client Kees – team manager, 62 years old, insurance company, 5000+ employees, big change ahead. The result could look like this: <div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600463-Results-empathy-map-Alex-Hendriks2.png” alt=”Empathy map result” title=”This is what is inside your clients head!” width=”600″ height=”463″/>If you’re working on buniess change, you should know what is inside your clients head</div>By entering the head of Kees for about an hour, I changed my perspective and gained some valuable insights for consulting him in the design and change challenges in his project.Please share your experiences and ideas on this with me at <a title=”E-mail Alex” href=”mailto:a.hendriks@bizzdesign.com”>a.hendriks@bizzdesign.com</a>, or leave a comment. </div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>