Search Results for “business model” – Page 31

Mike Walker on Business Architecture, Part 2

June 21, 2013 by Mike Walker

In this is Part 2 article, “Walker on Business Architecture” in the Architecture and Governance Magazine , I continue to explore and answer questions in the business and information architecture discipline. In part 2 of this article we switch the…

Business Capability based EA Roadmap

June 16, 2013 by Adrian Campbell

As Business Capabilities are directly derived from the corporate strategic plan and are designed to satisfy the enterprise’s business strategies, goals and objectives, so they provide an excellent basis for the creation of an Enterprise Architecture Roadmap. What are Business Capabilities? A Business Capability represents the ability of an organisation to perform an activity that […]

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>

Webinar: Selling Business Architecture

May 27, 2013 by Jeff Scott

I will be presenting a webinar on Tuesday, June 4th and again on Thursday June 6th on the topic of selling business architecture. This free webinar is sponsored by Accelare and is open for anyone to attend. You can register here: Tuesday, June 4, 2013 – 11:00AM EDT or Thursday, June 6, 2013 – […]

What Happened to the Fine Art of Business Analysis? – Revisited 2013

June 14, 2013May 27, 2013 by Nigel Green

Back in 2008, I wrote a paper on Business Analysis. Recently, I’ve been revisiting this subject in my day-job and this made me realise how little things had changed and inspired me to write this post, which is, basically, the original article re-written, with additional thoughts (in italics).

The role of the Business Analyst has never been more important but needs refocus on Information Systems not the technical solution. Many of us can recall a time when a distinction was made between the hardware and software supporting the business and the information used by the business – there was a clear difference between IT, to describe the former, and IS to describe the latter.

IS stood for Information Systems:

IS: The landscape of business information used by people within an organisation

and how they use information to deliver business outcomes.

IT, in contrast, meant:

IT: The hardware and software technology that automates or otherwise supports

information processing.

This distinction between these two concepts is all but lost, and the disciplines associated with Information Systems (such as Business Analysis and IS Architecture), are have become too obsessed with IT.

Where did the Business Analysts go?

The change of focus was probably, in part, caused by the rise in enterprise software packages and the associated promise that these out-of-the-box solutions could work miracles – magically automating all kinds of business processes and spraying efficiency glitter over all parts of the organisation. Powerful promises!

And to make them even more seductive, they contrasted sharply with often, expensive and unsatisfactory, custom-build software projects. Small wonder then, the new-kids-on-the-block, ERP packages, were seen as being more business relevant: enforcing standardisation and promising to boost efficiency. Business Analysts started to abandon their ‘real job’ to become, in effect, package ‘fit-and-configuration’ specialists. Inevitably, their work began to focus on the features and functions of the software, rather than the realities of the business with its complexities: messy processes and human interactions.

Since then, others with expertise in IS, have gravitated to the world of IT architecture. This discipline has proved increasingly important with the many large organisations who realise that packages – even so called ‘enterprise-wide’ ones, need to coexist the rest of the IT estate. You can’t buy architecture in-a-box!

At the same time, the revolution in Open Source and Web technologies meant that the focus of architecture began to move away from the organisation’s internal IS needs and towards the emerging global IT standards, tools and methods used by its customers, suppliers and partners. The sheer complexity of all aspects of ‘architecture’ meant that areas of technology-focused specialism began to develop within the architecture community.

This article suggests, it’s time to dust-off the concept of Information Systems, and return to business analysis practice that focuses on:

Simplifying [as much as makes-sense], balancing and consolidating requirements across all aspects of the business, but with, the important business outcomes, front-of-mind.

Identifying repeating patterns of business activity and seeking out opportunities for shared competencies and services.

Understanding the behavioural aspects of the business that have been proven to be barriers to adoption of IT solutions.

Studying the elementary aspects of the business’s Information System such as rules and constraints embedded in policies, the business-meaningful, real-world, events of interest and the information content being exchanged between individuals and groups.

Communicating and agreeing upon the business ‘what’ before getting immersed in the technology ‘how’.

What’s in a Word? The Problem with ‘Process’

There appears to be a problem with how we use the word ‘process’. To support business efficiency goals, many envisage the world as a set of neatly ordered, well planned, predetermined and logically sequenced set of activities – just as Henry Ford did when he introduced the production line. This is hardly surprising as it is a tried and tested approach to manufacturing, and more generally reflects a simple but intelligent goal – to be more efficient at a task through understanding and optimising all the steps. However, optimisation and automation require all the steps and parties involved to be specifically defined, so this approach usually seeks to ‘decompose’ the task into detailed models of all the interacting parts within the end-to-end process. The process being defined is also typically mapped to an organisational framework and financial models which constrain it within central and departmental rules, polices and edicts, which are often inherited from corporate decisions unrelated to the process in-hand. This is Six-Simga-Everything mentality! The most critical problem with this efficency-only focus, is in its poor representation of the softer, more knotty problems associated with differing values, policies, and operational ‘realities’.

To add to this problem, the language of users differs significantly from that of the IT specialist. This difference in language is a reflection of apparently opposing values (value systems) in play. Fundamentally, the users want a system that works the way they do one which is often prone to change and which supports learning. The IT specialist seeks a high degree of functional certainty and actionable rules that can be configured or encoded.

(see note about ‘Agile’ SDLC at little later).

To make matters worse, the gaps and inconsistencies in the expression of business requirements force a high degree of IT ‘engineering rigour’ that attempts to complete the picture. IT engineering relies upon techniques and tools that are designed to convert process and policy into precise rules and constraints. This can result in important behavioural dimensions such as the effect of variance in values and levels of trust – being left unspecified, and tension-points left unresolved. The dialogue between user and the IT specialist becomes focused on the detailed features and functions of the IT ‘solution’. The business outcomes of the sponsoring executive become obscured by this drive towards detail and by the end-users’ individual, and collective, ideas on how the ‘solution’ will work.

C-level ‘Businesss Stakeholder Standardisation Edicts’ or sent out in an attempt to ‘Get Things Back on Track’: ensure that operational efficiency goals are met and key business outcomes are delivered. This can result in an unwitting collusion between the C-level ‘Business Stakeholder’ and the IT specialist: both parties are motivated to build ‘standardised’ behaviour into the IT solution.

The top-down edict approach to driving IT-enabled business change projects suffers from three major problems:

Adoption Barriers

The users are less inclined to adopt the IT solution, claiming that it doesn’t work for them – they continue to use and develop ‘shadow’ IT solutions

Brittle Processes

The top-down specification of process works against flexibility and becomes a barrier to future business change.

Business/IT Misalignment

The organisational and management models of the business are not properly reflected in the IT solution. In, for example, a multinational business with diverse operations, it may be necessary and desirable to allow for local freedom-to-act, in say, Customer-facing processes.

It seems we need a different approach to how we specify requirements for IT: an approach that balances the desired business outcomes of the stakeholder with the needs of the user, yet with the precision needed by the IT specialist.

Significant improvements are being claimed by the ‘Agile’ development community, however, the problem still exists when likes of SCRUM and XP don’t apply, such as the deployment of a package solution or, increasingly, the purchase of SaaS. Not to mention, that ‘Agile’ approaches can be left wanting when in comes to cyber-security and data privacy.

It appears that the language-used, and a premature focus on IT, are at the root of this problem. The language problem starts with how we express the concept of processes. The word ‘process’ can have very different meanings and implications. These can range from the loose collection of unsystematic activities, that might support a contract negotiation, or an HR process, to the highly repetitious, and predetermined behaviour, of say, a production line. Maybe a common language for describing the range of business behaviour, across any type of process, would help?

A premature obsession with the details of the IT solution, seems to drive the analysis of the business problem towards IT engineering methods. Such methods often ignore or, at best, neglect softer, human, aspects. IT engineering methods and techniques are designed to drive completeness and precision for systems and, in doing so, introduce a language that is, by its nature, hard for the business to understand. This creates frustration on both sides of the Business/IT divide: neither party understanding the needs of the other. The sheer volume of information produced during the engineering life-cycle, means the overall business context gets lost in the production of flow diagrams and technical plans. The complexity of the task requires a high degree of technical specialism. This can lead to a lack of focus on the nuances of real-world behaviour and human interaction ‘on-the-ground’. Often the focus is slanted towards engineering ‘How’ rather than the business ‘What’: the business outcome.

The reality is that many business scenarios are more organic, and unpredictable, than pre-determinable, and mechanistic. In today’s connected world, many business scenarios encounter tensions between corporate and local functions, between customer and supplier, and between partners. No one is in control of the end end processes; rather, a combination of interacting service agreements make up the overall value delivered to the customer.

In contrast to usual business/IT dialogues, what’s needed is a natural-language that moves the focus away from any technologies and towards business behaviour – as expressed in values, policies, real-world events and any type of information [Content] being exchanged.

The original article bangs-on about VPEC-T and, our then, current, book ‘Lost In Translation‘, which I’ll skip now [sigh of relief for many!]. I would end the article differently now. In hindsight, it missed-out some more fundamental (and frankly, more broadly applicable techniques) such as SWOT, Risk-Radar, Hypothesis-led and PESTLE analysis. Perhaps more importantly, I would emphasise the value of; ‘abstraction’ (conceptual and logical ‘What’ before ‘How’ thinking), an understanding of ‘Complex Systems’ – The Cynefin Model (Dave Snowden) would be a good starting point – and workshop techniques such as those described in ‘Gamestorming‘ (Dave Gray, Sunni Brown and James Macanufo).

I recently came across the ‘Brown Cow Model‘ (Suzanne & James Robertson) when wrestling with a culture of ‘How’ before ‘What’ behaviour – aka ‘I have the solution, so what’s the problem’ ! I love the simplicity of ‘Brown Cow’:

I’ve found this simple model a great way to keep project teams focused on understanding the ‘What’ before the ‘How’ and the importance of knowing the AS-IS situation before leaping to the TO-BE. This, for example, has opened-up the requirements discussion to include the, often-overlooked, business requirements of the transition between ‘Now’ and ‘Future’ states. Maybe, this is more of a problem here in Asia, but given some experiences I had in the UK over the past five years, I suspect not!

I about to run out of battery on my iPad now – so that’s all for now. As always, I ask for your comments! Thx.

What Happened to the Fine Art of Business Analysis? – Revisited 2013

June 14, 2013May 27, 2013 by Nigel Green

IS stood for Information Systems:

IS: The landscape of business information used by people within an organisation

and how they use information to deliver business outcomes.

IT, in contrast, meant:

IT: The hardware and software technology that automates or otherwise supports

information processing.

Where did the Business Analysts go?

This article suggests, it’s time to dust-off the concept of Information Systems, and return to business analysis practice that focuses on:

Simplifying [as much as makes-sense], balancing and consolidating requirements across all aspects of the business, but with, the important business outcomes, front-of-mind.

Identifying repeating patterns of business activity and seeking out opportunities for shared competencies and services.

Understanding the behavioural aspects of the business that have been proven to be barriers to adoption of IT solutions.

Communicating and agreeing upon the business ‘what’ before getting immersed in the technology ‘how’.

What’s in a Word? The Problem with ‘Process’

(see note about ‘Agile’ SDLC at little later).

The top-down edict approach to driving IT-enabled business change projects suffers from three major problems:

Adoption Barriers

The users are less inclined to adopt the IT solution, claiming that it doesn’t work for them – they continue to use and develop ‘shadow’ IT solutions

Brittle Processes

The top-down specification of process works against flexibility and becomes a barrier to future business change.

Business/IT Misalignment

I about to run out of battery on my iPad now – so that’s all for now. As always, I ask for your comments! Thx.

Understanding business activity – a key to achieving success.

May 21, 2013 by Kim Parker

Business Activity is absolutely central to how a business operates: supporting what a business does by delivering on business capability. It is imperative that the business has a real understanding of how activities are structured; what information they require; what … Continue reading →

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.

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!

One Picture For All: Visualising Business-Technology Strategy

July 18, 2013May 10, 2013 by Nigel Green

In the process of developing a Business-Technology Strategy, I wanted to create Gamestorming-like approach to help position business drivers, technology trends and IT responses. I’ve been reading ‘The Agile Architecture Revolution’ by Jason Bloomberg (…

One Picture For All: Visualising Business-Technology Strategy

July 18, 2013May 10, 2013 by Nigel Green

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>