Month: May 2013

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

by

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

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

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

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

 

Some people refer to

· Enterprise traceability which proves alignment to business goals

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

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

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

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

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

· Traceability from the initial design phase through to deployment

· And probably more

 

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

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

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

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

image

 

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

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

 

image

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

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

 

There may be five different ways to build that traceability:

· Manually using an office product

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

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

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

 

1. Manually using an office product

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

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

clip_image006

 

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

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

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

clip_image008

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

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

 

clip_image010

 

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

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

 

image

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

 

4. With an enterprise architecture tool using ArchiMate 2.0

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

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

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

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

clip_image014

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

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

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

 

clip_image016

 

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

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

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

 

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

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

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

 

image

 

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

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

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

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

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

by

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

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

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

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

 

Some people refer to

· Enterprise traceability which proves alignment to business goals

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

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

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

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

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

· Traceability from the initial design phase through to deployment

· And probably more

 

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

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

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

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

image

 

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

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

 

image

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

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

 

There may be five different ways to build that traceability:

· Manually using an office product

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

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

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

 

1. Manually using an office product

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

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

clip_image006

 

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

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

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

clip_image008

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

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

 

clip_image010

 

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

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

 

image

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

 

4. With an enterprise architecture tool using ArchiMate 2.0

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

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

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

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

clip_image014

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

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

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

 

clip_image016

 

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

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

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

 

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

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

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

 

image

 

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

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

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

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

Context Mapping, by Example

by

I will demonstrate a technique for Context Mapping that leverages David Sibbet/The Grove’s work on Context Maps. We will build up the map incrementally, using the comments on this post to gather input to the Context Map which I will … Continue reading →

Categories Uncategorized

Att-e-en-tion! To System Design

by

What we are paying attention to shapes what we perceive and pay attention to. And paying attention, requires attention. The system, thought of, observed and measured, reasoned about, designed as, a system, needs intentional attention. Attention that competes for bandwidth with the order of the day — delivery of working code (with tests, please). We […]

With Smart Process Applications, More is Always Better

by

Assure provides a set of over 70 pre-built services and reports that can be assembled like building blocks to create and deploy high value Smart Process Apps much faster than the “blank slate” approaches found in traditional BPM suites. Once an organization deploys their first Smart Process Application with Assure, they become adept at designing a process, using the building blocks to assemble their solution, and then deploying their apps.

Related posts:

  1. We’re talking Smart Process Apps — and so is Forrester. “Smart Process Apps are a reflection of innovations we have…
  2. OpenText Smart Process Applications: At the Intersection of Social Street and Core Systems Ave Last week, I helped kick off OpenText’s EIM Days in…
  3. OpenText Smart Process Applications: In The Age of the Customer BPMS is not enough We live in “In the Age of the Customer” a…

Related posts brought to you by Yet Another Related Posts Plugin.

Data Management: Introduction

by

<p>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:</p><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><p>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:</p><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><p>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:</p><p><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”/></p><p>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:</p><ul><li><strong>Subject Area &amp; objects</strong>: an overview of how the information landscape can be subdivided into coherent subject areas, which can be decomposed into business entities</li> <li><strong>Realization of Entities in applications</strong>: entities represent business concepts, and may be realized by some IT system. In this post we will show how to model this</li> <li><strong>Stewardship</strong>: a steward is the person responsible for the quality of information, i.e. the entities that are part of a subject area</li> <li><strong>Mastering data</strong>: 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><strong>Meta Data</strong>: 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><strong>Business Intelligence</strong>: 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><strong>We end the series with</strong>: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><p>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.</p>

Categories Uncategorized

Three Decision Model Predictions and The Decision Modeler

by

<p><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.</p><p><span style=”font-size: 11px; line-height: 19px;”><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 </span><a href=”http://www.linkedin.com/in/larrygoldbergkpi” style=”font-size: 11px; line-height: 19px;”>Larry Goldberg</a><span style=”font-size: 11px; line-height: 19px;”> and </span><a href=”http://www.linkedin.com/pub/barb-von-halle/1/7ab/130″ style=”font-size: 11px; line-height: 19px;”>Barbara von Halle</a><span style=”font-size: 11px; line-height: 19px;”>, who are the co-authors of the seminal book </span><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> <span style=”font-size: 11px; line-height: 19px;”>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.</span></p><p>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></p><h2><span style=”font-size: 11px; line-height: 19px;”><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</span></h2><p>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.</p><p>My reasons for an entry-level low cost TDM modelling tool are:</p><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><span style=”font-size: 11px; line-height: 19px;”>My Original Decision Model Prediction 2</span></h2><p>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.</p><p><em>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.</em></p><h2><span style=”font-size: 11px; line-height: 19px;”>My Original Decision Model Prediction 3</span></h2><p>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. <span style=”font-size: 11px; line-height: 19px;”>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></span></p><h2><span style=”font-size: 11px; line-height: 19px;”>The Three Predictions and The Decision Modeler</span></h2><p>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.</p><p>So how does BizzDesign’s The Decision Modeler compare with the three TDM predictions?</p><ul><li><strong>TDM Prediction 1 and The Decision Modeler </strong>– 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><strong>TDM Prediction 2 and The Decision Modeler</strong> – 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><strong>TDM Prediction 3 and The Decision Modeler</strong> –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><p><span style=”font-size: 11px; line-height: 19px;”>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.</span></p><p>I can therefore confirm that The Decision Modeller meets all the three TDM Predictions.</p><p>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.</p><h2>Future Predictions for Decision Modeler</h2><p>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.</p><p>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.</p><p>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!</p><p>By <a href=”http://suleiman.shehu@azinta.com”>Suleiman Shehu</a></p><p><span style=”font-size: 11px; line-height: 19px;”>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).</span></p><p><span style=”font-size: 11px; line-height: 19px;”>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.</span></p><p><span style=”font-size: 11px; line-height: 19px;”>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></span></p>

Categories Uncategorized

The value of lenses

by

image

TOGAF

Zachman

Agile

Scrum

Kanban

XP

User centred design

Lean

Lean startup

Service design

Design thinking

Behavioural economics

What do these things have in common? These are all things I’m either interested in, read a lot about, studied/got certified in, or use/have used in my work.

The other thing that they have in common? None of these things are The answer.

I like to think of each of the list above as lenses that help you view problems in a different way, using them individually or in combination can help inform your view of the problem space and give you greater options when looking for solutions.

It is very tempting for us to find a methodology or framework that resonates with us at a point in time (for me back in 2006, it was Scrum) and start to see everything through that particular lense.

There is a danger in relying on one lense too much and that in focusing on the use of one lense we become myopic, concentrating on using our chosen methodology/framework/process without understanding its application in the context of the wider problem space.

Example:

A few months ago I attended the excellent @SyncNorwich monthly conference. One speaker gave a talk about using Kanban on a software development project. It was a really informative talk about using Kanban on a project, the team seemed to work really well, the ‘product owner’ seemed happy and they shipped early and often. It all sounded great until the speaker put up a slide showing the tiny amount of usage/sales of the product.

I was left with the conclusion that using the lense of Kanban had enabled the team to deliver the wrong thing really really well. The weak link in the chain was whatever design process the Product Owner (and his team) used to feed into the development process.

I raised this conclusion with the speaker, he didn’t seem to think it was his problem (or Kanban’s). The fact that the organisation he worked for had ploughed (i’d estimate) several hundred thousand pounds into developing products that customers didn’t use, didn’t seem to register as a problem. His team had delivered what his customer (the Product Owner) required using Kanban, worrying about what the real customer actually wanted wasn’t even on his radar. The net result was the customer’s needs weren’t met. Whatever lense we decide to use the needs of the customer should always be in plain sight.