Search Results for “infrastructure reference model”

Integrated Information Infrastructure – Reference Model – Free Poster

December 23, 2013 by Roger Evernden

The Integrated Information Infrastructure Reference Model (III-RM) is one of the two reference models provided by TOGAF. Get this free poster from Good e-Learning which summarizes the key features.

TOGAF Poster 18 – Deliverables, Artifacts and Building Blocks TOGAF uses a very specific language to describe the outputs…
TOGAF Poster 17 – The Architecture Repository The Architecture Repository is where architects store work outputs. This…
The Architecture Continuum Free Poster to DownloadDownload this free poster from Good e-learning…

Premises and principles for business system modelling (Part 5)

May 29, 2016 by Advisor

From the Editor: Graham Berrisford from Avancier Ltd has provided…

Modelling processes in ArchiMate

March 22, 2016 by Gerben Wierda

ArchiMate is not a process modelling language. It has only limited support for process modelling. That is why I personally prefer to combine BPMN with ArchiMate, but that is not trivial (as explained here and here). In the book there … Continue reading →

European Interoperability Reference Architecture

July 24, 2015 by John Gøtze

European Interoperability Reference Architecture The European Interoperability Reference Architecture (EIRA) is an architecture content metamodel defining the most salient architectural building blocks (ABBs) needed to build interoperable e-Government systems. On 8 June 2015, release 0.9.0 beta of the EIRA entered an eight-week public review period. Stakeholders working for public administrations in the field of architecture […]

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>

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

April 28, 2013April 15, 2013 by BizzDesign Staff

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

Time to Rain on the “Cloud Service Model” Parade

December 10, 2012June 27, 2012 by David Sprott

The Cloud community have been talking recently about Everything is a Service; they call it EaaS. At first hearing it’s an interesting idea, another acronym to complement IaaS, PaaS and SaaS. Unfortunately it’s rather like the tail wagging the dog! The Cloud community use the term Service liberally but with minimal consistency.

It must be said that the NIST reference architecture document has been incredibly helpful in sorting out the three Cloud service models of IaaS, PaaS and SaaS. However in order to read the document you have to suspend all your knowledge and belief of services and read the document interpreting all references to service as “provision or access to some capability”. In other words as a generic IS service of some sort.

Actually most Cloud infrastructure resources are provisioned as well formed services governed by interface and SLA contracts. There are a few SaaS providers that have implemented an SOA – in compliance with generally accepted principles of loose coupling, separation etc. However most Cloud services are multi-tenant application resources with integration capabilities delivered as Web services. Yet perceived wisdom generally says that SOA is essential for Cloud!

I noted an interesting paper from Intel recently[i]; the thing that really struck me was the way the paper describes how Cloud development as the Wild West (my words), and the author is advocating ideas that amount to rediscovering the SOA wheel!

SaaS and PaaS providers are circumventing traditional enterprise architecture. Compliance and visibility has decreased. Simply put, your enterprise is likely already part of the app economy. The question is, how are you managing your API traffic? Do you have a control point to manage that participation? Enterprise APIs are not science projects; they’re conducting enterprise-class business and require enterprise class visibility and control. What path can enterprises take to prepare for secure use of APIs? Dan Woods, Chief Analyst, CITO Research and Colleagues, May 2012

And the author goes on to describe how Cloud needs to move beyond point to point integration to introduce something that sounds very much like an ESB! So the notion that de facto Cloud practices should form the basis for EaaS sounds fanciful.

Yet despite this, I believe we should look closely at the idea of Everything as a Service. It’s the vision that CBDI and other pioneers painted years ago. What’s really required is a convergence of business and IT service concepts that would provide consistent views for all the various stakeholders in both IT and business domains including the service owner, business service designer, IT service architect, IT service designer, service security architect, provider, IT service manager, service broker, service consumer and so on and so forth. Today we have disparate service models in both business and IT that positively encourage silo disciplines.

To produce some form of unified service model wouldn’t be just an academic exercise. First it might just facilitate better understanding of service architecture across business and IT stakeholders. Second it might assist in better service design, delivered services that are fully integrated with people, product, process and technology and engineered to deliver individualized services to customers that are architected to be responsive to business change!

But the place to start is to understand the needs and opportunities in a unified service model. This will leverage the Cloud, and hopefully cause more service owners to demand their services are first class software services in order to deliver better customer service. Maybe this will encourage NIST to revisit its reference architecture and give the service perspective a little more integrity.

In this month’s CBDI Journal we publish an article exploring how such a unified model might look, and the business value that it might deliver. We welcome feedback and comments.

CBDI Journal Report: Everything is a Service?

Abstract: The Cloud movement is discussing the term Everything as a Service (EaaS or XaaS). In principle this is a welcome development, encouraging business and IT participants to adopt services and service oriented concepts everywhere. However it appears that the E/XaaS initiative may be more about marketing than reality. In this article we suggest how this very promising idea might be developed to clarify Cloud Service taxonomy and deliver convergence of business and IT perspectives in a Unified Service Model.

[i] Enterprise-class API Patterns for Cloud & Mobile

From business-model to enterprise-architecture

July 26, 2011 by Tom Graves

Okay, I think I’m finally getting somewhere, on looking for a way to connect a business-model to enterprise-architecture, to provide a full link between top-down intent and bottom-up real-world constraints.
This specific part goes from the business-model downwards, from Business Model Canvas to Archimate, and thence to BPMN, UML and other detail-layer models. (There’s another part […]

Modelling people in enterprise-architecture

January 31, 2011 by Tom Graves

As mentioned in the previous post, one of the key characteristics of ‘crossing the chasm’ to a viable whole-of-enterprise architecture is the explicit inclusion of people. In short, we need to be able to model and map where people fit in relation to the architecture.
But there’s a catch. A big catch. People should not be […]

The Retail Reference Architecture

January 26, 2011 by Amitabh Apte

The concept of “reference architecture” is often misunderstood and gets associated with IT. While the implementation may very well be IT, the reference architecture essentially is a business and operational artefact. As RUP defines, “the referenc…

Search Results for: infrastructure reference model