24 June 2013
How often do you see customer journeys, customer events and scenarios modelled in an Enterprise Architecture model? Not often, if at all I suspect.
In my opinion, the ‘Enterprise’ in Enterprise Architecture should include all those stakeholders that are engaged with an organisation. This include all those suppliers and service providers to the left hand end of the Value Chain, and the Customers at the right hand end. In this post I’ll be focusing on the Customers that are consuming the products and business services that are the outcomes of the Value Chain.
This is the view that the Customers have from the outside of an organisation looking in. This perspective should drive what a business does.
In most organisations however, the Enterprise Architecture is usually focused on the organisations internal workings, the inside out view of how an organisation can become more efficient, leaner and reduce cost, as a way of making more profits. The focus is on delivering better software faster, improved processes, commoditised infrastructure, reusable IT services, providing a self-service internet to replace face to face contact with the customer and so on.
The business strategy may look at the customer and market segments and the drivers for strategic change, but this is often as far as it goes. The rare organisation models the customers journey and the customers perspective and if they do then its rare to find the customer journey modelled in the Enterprise Architecture.
Organisations often try to reduce the direct interaction they have with their customers by removing phone numbers from their web sites, and providing limited set of services and FAQs. Customers are forced to waste many minutes on the telephone, selecting endless options in an attempt to get a human voice to speak to. Companies are afraid of this because of the costs of complaint handling. To be fair, a number of organisations have implemented a live chat IM service on their web sites and high value customers do often get a live account manager to speak with. But what about the rest of us everyday customers? It still seems like businesses are lacking a good understanding of their customers behaviour.
Digital Businesses and Digital Customers
Every business is now a digital business. It’s the same for customers (i.e. all the consumers, customers, potential customers and contacts) who are also increasingly digital using technologies like smartphones, social networks and broadband. They are using their own devices (such as iPads and other tablets) to research potential products and business services that they wish to purchase from businesses. They browse social networks and conduct searches to determine what product or business service best suits them. They have mass access to huge networks of information such as Google to help them.
Customer behaviours are changing, but does your enterprise architecture model know that? Does it model what the customers’ own processes are? Does it model the events that originate from a customer? Does it model what the various scenarios that there are in the customer journey? In my experience the answer is typically ‘No’ to all these questions. In my experience even when an organisation is modelling the customer journey then it is never included in the future state enterprise architecture.
What is the customers’ processes? Customers will conduct a search and discovery process, engage with the business to select, negotiate and make a purchase. If the business is lucky then the customer will re-engage to make future purchases, but if they screw up the customer will get annoyed and tell all their contacts on social media about why they are no longer buying. Companies are seeing the increasing power of customers but how many are trying to understand them and model their behaviours?
Enterprise Architecture, or more specifically, the Business Architecture within the Enterprise Architecture discipline should cover the customers’ interactions with a business, understand what they are saying on social media.
An initial approach is to speak with customers and use a thinking framework such as VPECT to determine their Values, Policies, Events, Content, Trust Relationships.
They can also use the less engaged PEST analysis for strategic market research.
Results of conducting VPECT analysis and PEST analysis should be recorded in the enterprise architecture models and associated to a representation of the customers journey
How should we model the Customer Journey and the different customer scenarios?
For a start, each scenario in a customer journey will be triggered by one of more of the Events discovered by VPECT analysis and be concluded by something of Value delivered back to the customer (Content).
What does the Event trigger? For me the best representation is a sequence of Business Services, in what might be called a Service Flow diagram.
This is much the same as a Process Flow diagram but from the external perspective. For a customer interacting over the internet, the Business Services might involve a Browse Service, A Product Detail Service, A Product Price Service, A Payment Service and a Fulfilment and Delivery Service. The Outside In service flow view is later mapped to the Inside Out process flow view
It’s easy to see that an organisation may not itself directly provide all these Business Services (for example the Payment Service may be provided by PayPal or similar, and the Fulfilment service may be provided by DHL or similar)
What also need to be modelled are the Customers own goals and objectives and how the scenario of service based interactions supports the customers goals. Key measures should also include:
- How much did the customers have to invest in the interaction (in time, and navigating complex interfaces, breaks in the interaction, confusion) to complete it?
- How much they enjoyed the interaction (customer satisfaction feedback)?
- How many customers abandoned the attempt early?
- How many customers complained to their social media contacts afterwards?
- How many customers complained directly to the business?
Another question that needs to be addressed is what channels and multiple channels do customers use? Customer these days are much more likely to use multiple channels at different times, rather than just a single one:
- Search the internet with their iPad or smartphone at home
- Switch to using their desktop PC at work
- Use the telephone, email, IM message or SMS message for clarification on product details, prices and discounts
- Hand off the desired purchase to their purchasing department to use corporate discounts to make the actual purchase
- Expect an email or letter with their receipt, complemented by an SMS message to their mobile device and copy to the purchaser
Channel strategies don’t often allow for a customers’ use of multiple channels and for account information being passed around during an interaction with the customer. Businesses often manage different channels with different functions and organisation units. This results in confusing and frustrating transfers between departments. How often have you called a business, given your contact and customer account details, only to be handed off to another department who asks you all over again for that same information? It’s extremely annoying and it’s this kind of symptom that undermines the customers’ experience and sends them tweeting negative remarks.
One to One marketing
One-to-one marketing refers to marketing strategies that are designed as if they apply directly to an individual customer. Information is collected about customers’ needs, customer segments that they fall into, their preferred channel, their lifetime value to the business and which products and business services they are likely to purchase.
See the books by Don Pepper and Martha Rogers: The One to One Future and the One to One Field book.
What one-to-one marketing misses is more of an Outside In perspective, going much further in understanding the values that a customer needs and their own processes that customers follow (formally or informally).
The book I recommend is ‘Outside In: The Power of Putting Customers at the Center of Your Business’ by Harley Manning, Kerry Bodine et al.
Total Unified Customer Communication
Typically organisations still tend to communicate with their customers in a disjointed and unconnected way. Invoices, statements, receipts, marketing literature, pricing deals, discounts, marketing campaigns, letters, emails, IM messages, data streams etc.. are all sent from many different departments who have no idea about the incoming or outgoing communications that have already been received or are being made by other departments. The result is customer confusion. To be fair, the situation is not so bleak for business customers, as it is for individual personal customers, but increasingly it’s difficult to tell the difference and negative social media discussion will also impact the business customers.
Instead of just silo based incoming communication with customers we need to get a total view of all the customers interactions both incoming and outgoing to the business, and within social media, centralising all interactions, via multi channels, with a Customer Communication Management (CCM) system. Curiously I’ve never seen a Customer Communication System in any future state Enterprise Architecture model and the recommendation to include one has fallen on deaf ears. One to one marketing should become one to one multi-channel total customer communication.
Companies will want to differentiate their products and business services and to compete with other businesses and therefore they will need to innovate. Understanding their customers’ perspectives and their customer journey scenarios will be a key innovation for any business. This will require that the future target Enterprise Architecture model includes these views and connect them to the rest of the model.
23 March 2013
Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/
Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here.
The questions were:
- How do you define Business Architecture?
- What is the role of the business architect? What real world business problems does Business Architecture solve?
- How is the role of the business architect changing? What are the drivers of this change?
- How does Business Architecture differ from Enterprise Architecture?
- How can business architects and enterprise architects work together?
- What’s in store for Business Architecture in the future?
How do you define Business Architecture?
Business Architecture is one of the primary domains within Enterprise Architecture. It deals with the architecture of the business, ideally from a business perspective and is expressed in business terminology.
It should not really be considered a separate discipline from Enterprise Architecture but often is by those who persist in misunderstanding that Enterprise Architecture is only about IT and not about the whole of the enterprise.
Business Architecture deals with the structure and design of how an enterprise operates, makes money or delivers value, how it organises itself in order to provide products and business services to its customers, clients and consumers. It should be expressed independently of how the business architecture will be mapped to the underlying application architecture and infrastructure architecture, but is more connected to the business/contextual view of the information/data architecture and will include the organisation architecture.
Business Architecture is centred on the business and the business strategy, not on IT or on the IT Strategy and should not be considered just a source of requirements for IT projects (which is the impression that TOGAF gives of Business Architecture).
In general Business Architecture includes the following deliverables:
What is the role of the business architect?
As a specialised type of Enterprise Architect, they are in a leadership role, close to business management working for the CxOs to evaluate and elaborate possible future strategic scenarios.
They have a responsibility to guide, recommend and oversee the realisation of the business strategies identified by the CxOs, but they don’t control the business strategy or make the actual investment and strategic change decisions.
What real world business problems does Business Architecture solve?
As a type of Enterprise Architect, a Business Architect deals with strategic change, business transformation activities concerning topics such as:
- Ecommerce changes
- Cost reduction
- Process improvement and efficiency
- New organisation design
- Mergers & Acquisitions
- Reuse of shared services
- New markets
- Regulatory and legal changes
One should not forget that, by definition, an Enterprise Architecture model covers everything about the enterprise including the environment and market which it operates in, its Business Strategies, its Business Architecture as well as the rest of the Enterprise Architect domains.
How is the role of the business architect changing? What are the drivers of this change?
The role of a Business Architect is becoming much more distinct than it has been. many organisations are maturing their enterprise architecture functions that were previously just centred on IT architecture and are now specifically introducing a Business Architect role.
How the Business Architect role differs from other roles such as a Business Analyst, Business Change manager, Business Transformation Manager etc. is still playing out. I discussed this to some extent in a previous blog post – The difference between a Business Architect and a Business Analyst.
Another current difference is that a Business Architect is often closely associated with the Business units (and perhaps reports to a business line manager of sorts) and therefore is seen as being on the ‘Demand’ side of a business, whereas the rest of the Enterprise Architects (including IT Architects) are often lumped into the IT department and therefore are seen as being on the ‘Supply’ side. In theory, the Enterprise Architects, including Business Architects, should only ever be on the ‘Demand’side and not seen as part of IT. They should report to the CxOs, ideally seen as part of a CEO Office.
How does Business Architecture differ from Enterprise Architecture?
A Business Architect is a type of (a ‘real’) Enterprise Architect. Business Architecture is a sub domain of Enterprise Architecture.
How can business architects and enterprise architects work together?
Of course they can. The distinction in the question is artificial anyway, since a Business Architect is just a type of Enterprise Architect that specialises in the Business Architecture domain.
But in reality many organisations do have an unfortunate tendency to make up their own interpretation of what these roles actually are.
What’s in store for Business Architecture in the future?
We will see more and more Business Architecture roles in the future as organisations mature their enterprise architecture strategy and capabilities, and they realise that they need to get to grips with their business model and how it is realised. They will need Business Architects to help them do that.
For most enterprises embarking on large scale strategic planning and business transformation programmes it is all about staying robust, viable and efficient, continuing to deliver good outcomes and value to their customers/consumers/clients in the future. Enterprises should be wanting to stay competitive and efficient and beat the competition.
If the enterprise is to succeed, it must make strategic decisions and investments in change based on a thorough architectural gap analysis/impact analysis that is only possible with business architecture as a key part of their enterprise architecture function.
11 November 2011
Enterprise Architecture is all about supporting strategic planning and business transformation activities, although many organisations seem to almost wilfully forget that this is one of the main purposes of Enterprise Architecture if not the most important one.
A business strategy is a long-term plan of changes for the whole enterprise which will address things like offering new products an business services, dealing with new customer or market segments, opening up niche opportunities, growth via mergers & acquisitions, cost consolidations and increased efficiencies. See http://en.wikipedia.org/wiki/Strategic_planning and http://en.wikipedia.org/wiki/Business_transformation
Enterprise Architecture primarily focuses on what an enterprise needs to do in order to stay viable, efficient and profitable in the future. In Viable System Model (VSM) terms, Enterprise Architecture is a System 4 type of system. See http://en.wikipedia.org/wiki/Viable_system_model
Enterprise Architecture bridges the gap between new strategy ideas and the execution of those ideas, in the same way that the intelligence corp in the military provide intelligence about current and future capabilities to the generals and ensure that the appropriate planning takes place in order to win the military campaigns.
Many organisations without an Enterprise Architecture function will risk failing to properly implement or deliver the on their business strategy.
It is frequently reported that many strategic ideas and initiatives identified by C-level executives are never properly implemented or seen through to full operation by the business units. That big picture of the business strategy on the white board in the CEO’s office or a high level presentation can look deceptively simple in a board meeting, but as they say ‘the devil is in the detail’. The C-level executives are responsible for seeing that the strategy is implemented, but it will be the Enterprise Architect that works out the detail.
Organisations need to know where they are now and create a baseline Enterprise Architecture model of their current state, then create a future target Enterprise Architecture model and do impact and gap analysis between them. The future state Enterprise Architecture model often needs to contain not just one single future target model but multiple complementary or competing models of the many future scenarios that are likely to have been developed using Scenario Planning techniques. See http://en.wikipedia.org/wiki/Scenario_planning
Strategic business transformation can be hard. Enterprise Architecture makes it far easier to answer questions such as:
- What Strategic initiatives are needed to fill the gaps found and address risks and issues?
- What new or changed business capabilities will be needed?
- What needs to be done when?
- How does one prioritise the different strategic business initiatives on an Enterprise Architecture roadmap?
- When are these investments in change going to be delivered?
- How will the initiatives be funded?
- What are the dependencies between the strategic initiatives?
- How will the business model be changed?
- How will the target Business Operating Model be changed?
- What organisation units and business functions need to be changed?
- What value chain and value streams need to be changed?
- What are the costs and potential revenues?
- How feasible is the business strategy?
- What feedback mechanisms between ‘systems’ will be needed?
- How will change be governed and how will compliance be assured? (i.e. how do we overcome resistance from difficult stakeholders, and the ‘Not invented here’ anti pattern?)
- What controls, KPI’s, CSF’s, incentives, bonus structures will be needed?
- What changes to the principles and standards will be needed?
- How do we align people, processes and technology?
- What other things have we forgotten?
I recommend reading the books:
- ‘Making Strategy Work: Leading Effective Execution and Change’ by Lawrence Hrebiniak and
- ‘Enterprise Architecture As Strategy: Creating a Foundation for Business Execution’ by Jeanne Ross and Peter Weill.
30 December 2010
We are used to the idea of a Programme/Project Management Office (PMO) but often organisations fail to understand (or perhaps deliberately misunderstand) what the Enterprise Architecture function does. I propose that the Enterprise Architecture function is, in effect, an Office of the CEO, or an Office of the CEO and Strategic Change Management.
The book ‘Enterprise Architect as Strategy’ (http://www.architectureasstrategy.com/book/eas/ ) gives us the right way of thinking and talking about what enterprise architecture is for – creating a foundation for the execution of the Business Strategy.
This book is an essential read for senior executives, business leaders and enterprise architects.
Many people within an organisation will understand the big picture view of the business strategy, such as the CEO of course, but perhaps only at a shallow level of detail.
Would the C-level executives understand all the potential nuances and wrinkles that come with that business strategy? Perhaps not unless they were a ‘details’ person.
What does the CEO do? They will spend time in evaluating ideas, formulating the mission and vision of their orgnaisation, innovating the business model to ensure the company remains competive in their market, looks for future opportunities for expansion and carving out a niche market.
It is the Enterprise Architect who has the job of maintaining the big picture on the behalf of the CEO, in sufficient detail to ensure that it becomes a knowledge base to support the executive’s decision making and help them to realise the business strategy and govern the implementation of that strategy.
In this way the Enterprise Architecture function is effectively the Office of the CEO, providing strategic support to the CEO and the other C-level executives. It’s also worth stating here that effective companies focus on enterprise architecture and don’t jump straight into IT architecture. Enterprise Architecture is not the same discipline as IT Architecture.
We can look at the the Enterprise Architecture function in terms of Deming’s Plan-Act-Do-Check process improvement process:
The CEO and other C-level executives will stablish the mission, vision, goals, objectives, principles and metrics to identify the main outcomes of the business strategy.
The Enterprise Architect will help executives, business leaders and strategic planners to develop the business model, operating model, and other enterprise architecture models supporting business model innovation
The CEO and other C-level executives will evolve and innovate the Business Model.
The Enterprise Architect will take the business strategy and business model and support the development of the target operating model, communicate the business strategy, model the target and interim enterprise architecture models, plan an EA roadmap of strategic initiatives, identify and define the required capabilities, define the mandates for the investment programmes and key projects, define standards and process improvements. They will usually define the IT strategy to ensure that it fits with the business strategy rather than being developed in isolation (as unfortunately often happens).
The Enterprise Architect will perform EA governance, compliance and design assurance against those programes & projects implementing the strategic changes and new capabilities. They will perform gap analysis and impact analysis, measuring the performance and compare the results against the expected outcomes.
All the while the Enterprise Architect will report to the CEO and act as their trusted advisor. They will analyze the gaps, risks, costs, issues, assumptions and dynamics to determine their cause and determine where to apply further strategic changes in the next iteration of the cycle and improve the overall maturity level of the enterprise.
The mission of Enterprise Architecture is to improve the implementation and excecution of the business strategy, ensuring that the enterprise will survive, continue to develop and remain profitable in the future.
An interesting example to look at is the US Department of Health and Human Services which has established an Office of Enterprise Architecture as part of the Office of the CIO. http://www.hhs.gov/ocio/ea/index.html
As the the book ‘Enterprise Architect as Strategy’ says – ‘When it comes to executing your Business Strategy your Enterprise Architecture may matter more than your strategy itself… ’
8 December 2010
How does an Enterprise Architecture and a Business Model work together?
Successful organisations are those that improve and innovate their Business Models to find a profitable niche against their competitors.
But a new Business Model alone is not enough. It needs to be implemented and executed. This is where an Enterprise Architecture comes in.
If organisations do not align their Business Model and their Enterprise Architecture then how can they be certain of making it work?
The first step is integrating the Business Model with the Business Architecture part of the Enterprise Architecture. This is described below.
Business Model Canvas
Business Model innovation is rapidly becoming a hot topic and especially with the release of the book ‘Business Model Generation’ by Dr Alexander Oesterwalder. http://www.businessmodelgeneration.com/
This book introduces a standard way of developing a Business Model called the Business Model Canvas. If you are an Enterprise Architect highly recommend you read it.
Up to now most organisations had their own informal and idiosyncratic way of defining a business model that was unique just to themselves. This is the first time a standard for developing a business model has been defined and published.
The Business Model Canvas is a powerful approach for business model design and innovation.
It captures the 9 most essential elements of a business model in a simple way, enabling the design of a ‘business model on a page’.
The 9 different segments are
- Customer Segments
- Customer Relationships
- Value Proposition
- Key Activities
- Key Resources
- Key Partners
- Cost Structures
- Revenue Streams
You can see some example Business Models developed with the business Model Canvas at http://www.businessmodelalchemist.com/ and on an associate web site where you can view a variety of example Business Models and try creating your own can be found at http://bmdesigner.com/ .
So what does all this have to do with Enterprise Architecture?
Enterprise Architecture exists to provide a path between strategy and execution, identifying the current state and the desired future state and plot a roadmap of strategic changes between them.
See book ‘Enterprise Architecture as Strategy’ – http://www.architectureasstrategy.com/book/eas/
Enterprise Architecture provides the organising logic and architectural thinking needed to design the appropriate business capabilities need to implement a Business Model. To get the right outcomes, organisations must focus on Enterprise Architecture and Business Architecture not try and jump straight to IT architecture and solution design.
After setting the overall mission and enterprise vision, the first Enterprise Architecture domain that we need to model and align with the Business Model is the Business Architecture.
Business Architecture Model
A Business Architecture model is used further elaborates the 9 high level concepts segments that have been populated with conceptual themes and business strategies in the Business Model Canvas. A number of techniques and approaches, views and artifacts are used to explore the themes and strategies in each Business model canvas segment.
Create a Porter’s Five Forces model to explore the market and the general business environment in which the organisation exists. Also conduct a SWOT analysis.
Create a VPECT model to explore the Values, Policies, Events, Content (outcomes) and Trust relationships from the perspective of each different customer segment.
For details of VPECT read the book ‘Lost in Translaton’ by Nigel Green and Carl bate – http://www.lithandbook.com/
Create a Business Event model, further elaborating the Business Events identified with the VPECT model.
For each current and especially the future Events, create a Business Scenario. This should explore he what if questions that will effect the business model in the future.
Create a model of the various channels that exist between the organisation and its customer segments as well as between the organisation and its partners and suppliers.
Don’t forget those new social media channels, such as iPhone or Android phones and other devices and applications such as Twitter and Facebook. Partners can also be channels as well.
Create a model of the flow of business information between the organisation and its customers and between the organisation and its partners and suppliers (use the Actor Co-operation Viewpoint in Archimate).
Use VPECT to explore what Value you provide to each customer segment and what problems you solve for them.
Create a Value Proposition Model of the Products, Business Services and associated Values (using the Product Viewpoint in Archimate).
Value Propositions drive Business Strategy, so create a Business Motivation Model to understand all the relationships between Vision, Goals, Objectives, Strategies and Tactics associated with the Value Proposition.
See http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf for details of the Business Rules Group’s Business Motivation Model.
Key activities includes any model of behaviour,
This should include both internal Business (organisational) Services, Business Functions, Business Processes and Activities as well as the external behaviour of your customers, partners and suppliers.
In some cases it is useful to think about behaviour in terms of external services (the what) and the internal behaviour (the how).
Create a Business Function Model (using the Business Function Viewpoint in ArchiMate). A useful approach to use here is the Component Business Model approach from IBM. See http://www-935.ibm.com/services/uk/igs/html/cbm-bizmodel.html
IBM’s Component Business Model provides a good basis for visualising the Target Operating Model in terms of Business Functions or in terms of Business Capabilities (they’re not the same thing…).
Create a Business Process Model (using the Business Process Viewpoint in ArchiMate). Business Process Models are not just Process Hierarchy Models but include Value Chains and Value Streams.
Create Value Stream models for each Event/Outcome pair (use the Business Process Viewpoint in Archimate) identified in the customer relationship segment above.
Create a Value Chain model at a high level for each customer segment (also using the Business Process Viewpoint in Archimate).
See http://www.opengroup.org/archimate/doc/ts_archimate/ for details of modelling the Business Architecture Layer in Archimate.
As they are high level abstract views, Value Chains are often specified more in terms of Business Functions than the more specific Business processes or Activities.
Resources in this segment can be further elaborated by the other Enterprise Architecture domains or Information Architecture, Application Architecture (and Application Service Architecture) and Infrastructure Architecture.
However before jumping to the IT Architecture it is better to start more conceptually and create an Enterprise Vision Model and a Business Capability model.
Enterprise Vision models are those high level one page models described as ‘core’ models in the book ‘Enterprise Architecture as Strategy’ (http://www.architectureasstrategy.com/book/eas/) and also in TOGAF Phase A.
You can also use the Layered Viewpoint in ArchiMate to produce Enterprise Vision Models.
Create a Business Capability model. This is usually a hierarchy model similar to a Business Function Model but remember that a Business Function and a Business Capability are two different concepts.
A Business Function is a high level view of existing internal behaviour from an organisational perspective, where the business functions are closely associated with the organisation units.
A Business Capability is defined by TOGAF9 as ‘A business-focused outcome that is delivered by the completion of one or more work packages’. A Business Capability is defined as the ability to execute a specified course of action, to achieve specific strategic goals and objectives. A Capability is defined in terms of the outcome of the course of action, one that has a business value. The concept of Capability is used in the military context and the MODAF framework where it is described in the abstract. See http://en.wikipedia.org/wiki/Capability_management and http://tinyurl.com/2vge39e
See also my previous post on Modelling Behaviour.
Create an Organisation model (using the Organisation Viewpoint in ArchiMate) to capture the human resources and their roles and responsibilities.
Create a Business Information Model (using the Information Structure Viewpoint in ArchiMate) to understand the knowledge, information and data resources within the organisation. Outcomes identified as Content in the VPECT model and in the Value Stream models are also modelled here as Business Information (represented by Business Object, Meaning and Representation object types in ArchiMate).
Identify your key partners, suppliers as carefully as you do your customer segments and customer relationships.
Don’t forget that Enterprise Architecture includes the extended environment as well as the organisation itself. This extended environment includes the Suppliers and Partners (use the Actor Co-operation Viewpoint in Archimate).
Explore the costs with a Total Cost of Ownership (TCO) model. This can be a spreadsheet.
Create a System Dynamics Models to fully explore and understand the cause and effect relationships between different stocks and flows, and run simulations.
Also explore revenues with a TCO model as with the Cost Structures
Remember that revenue doesn’t always mean profits in terms of money, but can be other non-monetary outcomes of value, (especially relevant for Government departments, non-profit and charity organisations who seek outcomes in terms of benefits to citizens and indirectly, votes).
It is again very useful to produce System Dynamics Models to understand the cause and effect relationships between different stocks and flows.
I think it’s surprising that more organisations don’t use System Dynamics as part of their enterprise architecture modelling. More on that subject in a future post…
Other Enterprise Architecture models
Starting from the Business Model Canvas, the Business Architecture views described above are used to further elaborate the details of the business model and to understand what needs to be realised from a business perspective.
After that the Business Architecture model is aligned to the Information/Data Architecture model, the Application Architecture model and finally the Infrastructure Architecture model pretty much as usual. I mostly develop these models using Archimate combined with other concepts from TOGAF 9 as needed, using tool such as Avolution Abacus and BiZZdesign Architect.
Note that other variations of Oesterwalder’s Business Model Canvas are starting to emerge. This is a sure sign that the concept is an important one that is reaching a tipping point.
These other business model approaches include: