Capability Based Planning: Kick-start, implement and grow in 10 steps Latest news from (my website): Bizzdesign

Editor’s Note: Business Capabilities are a cornerstone of Business Architecture, and understanding how to implement them is key to success. To guide you through Capability-Based Planning, we’ve created an ultimate eBook, filled with expert insights, strategies, and practical advice to ensure you’re on the right track. This blog post is an excerpt from our eBook.

Introduction: How to kick-start Capability-based Planning

This blog addresses establishing and growing Capability-based Planning in your organization. Some approaches advocate creating a full Capability Map of your organization as a starting point. While we see the benefits of that, for instance, to avoid overlapping capabilities, we think an iterative approach is more practical for most larger organizations, simply because of the scale of the effort. Moreover, such an approach will ease your stakeholders into this approach without forcing them to change their established ways of working overnight and avoid the pitfall of ‘analysis paralysis’.

Our approach consists of the following steps (though you may want to pick and choose which are most relevant to your organization and the resource capacity available):

1. Identify the initial scope: Pick a relevant part of the business for which it is feasible to start with a Capability-based Planning approach. For this scope, you need easy access to the relevant stakeholders and subject matter experts.
2. Lay the groundwork: Ensure stakeholders have a basic understanding of the capability and value stream concepts. Work with subject matter experts to identify the relevant capabilities down to a reasonable depth, say 2 levels. Don’t go too detailed for a first cut: 4 levels or more would typically be too much.
3. Create a draft capability map for the chosen scope, validate it with the stakeholders and SMEs, and refine it as needed.
4. Perform an initial assessment of the strategic importance of these capabilities. For instance, use a typical classification scheme of commodity vs. differentiating vs. innovating, or relate these capabilities to your enterprise’s specific strategic goals.
5. Do a basic analysis of the strategically most relevant capabilities from step 4. For instance, perform a high-level capability maturity assessment or calculate a roll-up of the IT cost related to capabilities. You may want to start with a simple t-shirt sizing metric assessed by a domain expert before going into more detailed assessments.
6. Relate the capabilities you analyzed in the previous step to change initiatives (e.g., projects and programs, agile value streams) that impact these capabilities.
7. Assess the expected impact of those initiatives on the analysis from step 5. Will an initiative, for instance, lower the IT cost or increase the maturity of a capability, and if so, by how much?
8. Using this impact to prioritize these initiatives. Initially, use this as additional information in the investment decision-making process to avoid too much resistance. Once stakeholders see that this approach contributes to better decision-making, this CBP-based information can become leading rather than merely supporting.
9. Use these priorities to identify new or realign existing change initiatives and define capability roadmaps to close the gap between current and desired capability maturity.
10. While implementing these change initiatives, track relevant KPIs and adjust priorities as needed.

Double-loop learning in implementing capability-based planning 

Additional points: how to extend our ten-step approach

Implementing this reusable approach is itself an iterative process. From a specific, confined scope, you can extend and grow in several directions:

Expand the scope 
For example, rolling this out across different business units. Growing your capability map also requires rethinking some parts since the additional scope may overlap in capabilities with the parts you already addressed. Make sure your capability map does not become a substitute for the organization structure since that would negate many of the advantages of capability thinking. Remember, a capability is not equivalent to a team, department, or another organizational unit.

Expand the stakeholders involved 
This could be from IT into the business, and it could be from senior business managers to business executives. Once senior leaders experience how this new way of thinking helps them focus investment decisions on the capabilities that are key to their strategy, they may even become advocates for this approach and convince their peers of its value. But the somewhat abstract nature of the capability concept will require a lot of communication: you will likely need to keep explaining this, and as they say, show, don’t tell: seeing it in action works best. On the other hand, you can emphasize how capabilities are a shorthand for people, process, technology and data, making complex topics easier to understand.

Increase sponsorship 
It should move from being a one-off exercise to being central to the business planning cycle. Business capabilities are generally static over time, so if they are used repeatedly, they become more recognizable and readily understood by stakeholders. It justifies the investment in defining them. Ideally, capability-based planning will move to the most appropriate team, e.g., the Strategy Planning team or equivalent in your organization.

Establish capability ownership 
An average organizational chart does not always lend itself to easily identifying capability owners since capabilities often cross organization functions. However, executives could become responsible for capabilities despite all the resources involved not being in their chain of command. Ideally, with ownership comes responsibility for planning, resourcing and delivery of the capability.

Extend and refine the capability analyses and assessments 
Use more metrics, obtain better/more precise data, involve more subject-matter experts, and integrate systems to pull the ‘official’ data to automate these assessments. By improving the data, decisions on investment in change become more based on facts and figures rather than hunches and intuition. That helps you move away from ‘decibel-driven’ decision-making, where the people with the loudest voices get their projects approved.

Formalize investment prioritization  
Formalize investment prioritization along the lines of capabilities rather than classical projects, typically in concert with other management changes. For example, this approach works well with moving from project to product-focused teams in IT. The key change here is that the strategy is linked to a capability outcome rather than a project scope which can contract easily.

Learn from this process of maturation  
Learn from this maturation process using feedback from the organization to refine your way of working. Capabilities are a new way of thinking, and while they offer numerous benefits that support what organizations are trying to do, you need to listen to the challenges and successes with this approach.

Of course, you need to keep your stakeholders informed and committed, manage resistance when it occurs, and evaluate the return on investment of your Capability-based Planning effort. Don’t overdo it! Not everyone needs to become a champion (but being at least a runner-up is an excellent position to aim for).

Political and emotional aspects of change

This blog series is focused on the rational aspects of Capability-based Planning and not on change management in general. However,  the political and emotional aspects of change are equally important to make Capability-based Planning a success in your organization. This includes:

• Understandability: Make your approach easy to comprehend and assess without detailed knowledge or direct experience for stakeholders.
• Simplicity: Remove the noise of details; the human brain can only take in so much information.
• Granularity: When making a decision, people will have questions; ideally, always be able to answer a stakeholder’s questions by really showing (e.g. by tracing it in your models) rather than just telling these stakeholders what the answer to their question is.
• Collaboration: Any change in the way of working requires persuading, challenging, arguing, agreeing, creating coalitions, and horse-trading.

We also addressed some of these aspects in our blog post on overcoming obstacles and challenges. Especially in organizational politics, architects are often ill at ease and out of their depth. Teaming up with someone more versed in this dimension of change (e.g., an experienced program manager or senior business leader) could be a good way to establish and mature a Capability-based Planning approach.

Most importantly, this should not be a ‘push’ effort from architects. Rather, you should aim to create a ‘pull’ from senior stakeholders by showing the added value of such an approach for their daily work and responsibilities. Once you pique their interest, you may be surprised by the traction you will gain with such an architectural approach to business change.

Schedule time with one of our experts if you need help with Capability-based Planning.

About the authors:

Marc Lankhorst

Managing Consultant & Chief Technology Evangelist at Bizzdesign

Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spreads the word on the Open Group’s ArchiMate® standard for enterprise architecture modeling, of which he has been managing the development. His expertise and interests range from enterprise and IT architecture to business process management.

Jeeps Rekhi

Customer Success Consultant

Jeeps has 25 years of experience in defining and delivering strategic and operational change. He is a senior enterprise-wide business architect who has specialized in data and digital transformation and knows how to harness value across business, operations and technology.

The post Capability Based Planning: Kick-start, implement and grow in 10 steps appeared first on Bizzdesign

Use Capability Based Planning to measure successful change investments Latest news from (my website): Bizzdesign

The previous article in this blog series covered how a Capability based Planning approach informs the Strategic Roadmap. We covered the Plan and Assess phases of Capability-Based Planning. In this blog, we’ll link the Plan and Assess phases to the Control phase of this process.

DOWNLOAD: Get started with Capability based Planning ebook

To measure the effectiveness of change investments, you need a way to control the processes (Map, Assess, Plan, Control) by continuously monitoring the effectiveness of the changes proposed by a Future State Design. For this, we need to know how this Future State Design contributes to the required improvements of key Business Capabilities, which have been identified as priorities for investment in an earlier stage of the process.

Caption: Capability-Based Planning Process

1. ‘SMART-ify’ capability gaps using a Driver Tree approach

In the previous blog post and the whitepaper: ‘From Strategy to Execution with Capability-Based Planning’, we discussed a ‘bottom-up’ approach for Capability Gap Analysis where we assess the current and required performance scores of (strategically important) business capabilities. We call the difference between these scores Capability Gaps. We consider these gaps when prioritizing investment and subsequently when designing a Target Operating Model.

To determine if we realize the required performance, we need a more specific definition of the capability gap and make gaps measurable in terms of their contribution to capability improvement. In other words, we need to ‘SMART-ify’ capability gaps.

The first step is combining the bottom-up approach with a top-down approach using a ‘driver tree’ view. We break down high-level strategic drivers into more specific business challenges in the driver tree view. These business challenges are modeled as (ArchiMate) assessments. We can do this in one or more steps to get to a level where we can define the challenges as concrete business problems that need to be solved. These business problems are a more specific version of a capability gap, and in turn, link into business capabilities. Closing these capability gaps will improve the performance of the capability.

This approach gives us a direct line of sight between strategic goals and drivers and the capability gaps. We can use this to provide additional input for gap prioritization since we can now analyze the relative strategic importance of closing a capability gap. This can be further enhanced by putting ‘weights’ on the leaves of the driver tree. See an example of a driver tree view below.

Caption: Driver tree view for strategic driver: Market Share 

2. Linking KPIs to strategic drivers and goals

With capability gaps linked to strategic drivers and goals, as well as to business capabilities, we can look at the realization of improvements not only in terms of the capability aspects (e.g. people, process, technology, etc. but also in terms of their contributions to strategic goals.

READ: How to assess Business Capabilities and How to Measure Business Capability Aspects 

To measure and monitor these contributions, we need to define Key Performance Indicators (KPIs) and link them to our strategic goals and drivers. C-level executives typically determine these KPIs. Using Bizzdesign Horizzon, architects can add these KPIs to the model repository and link them to strategic goals and drivers modeled in the same repository. In the example below, we see how the driver, Market Share, is supported by KPIs including ‘Revenue from Digital Services (%)’ modeled as a metric object.

Caption: Strategic KPIs for ‘Market Share’ 

3. Enhanced ‘Initiative Formulation’

In our previous blog post, we discussed how work packages can be created and structured to align with one or more business capabilities and how this could subsequently be visualized in a (multi-level) Capability Roadmap.

We take an additional step here to allow a model-driven approach for monitoring the effectiveness of change initiatives represented by the work packages. In the real world, the components supporting a business capability will undergo the actual change. These components include business processes, application components or IT platforms, and are represented in the Target Operating Model, also shown in the article mentioned before.

In this step, specific results of initiatives to close capability gaps are identified and linked to components in the scope of the Target Operating Model. The figure below shows how Initiatives (work packages) and their results (implementation events) are linked to capability gaps.

Initiatives (and desired end states) to fill capability gaps

This way, in addition to the capability roadmaps, we can now generate roadmaps at the component level using Bizzdesign Horizzon. This visualizes how, for example, a business process will be improved over time. In the figure below, we see an example of a process roadmap for improving the Payment Execution business process, which is in the scope of the Target Operating Model of the Payment Execution business capability.

Caption: Process Roadmap for ‘Execute Payment’

4. Baseline, Target, Expected KPI values

The last step of the Control phase in the Capability-Based Planning process is to quantify and analyze the improvement. We do that by setting a target (leading) value for the Strategic KPIs we captured earlier in the process. C-level executives typically determine these targets. Next, architects can work with business teams to identify a baseline (lagging) value for the same strategic KPIs.

The improvements represented by the implementation events on the Process Roadmap are responsible for getting from our baseline to our target in terms of KPI scores. For example, the percentage of Process digitization will go considerably up once the new payment system is operational. At the same time, the percentage of revenue from digital services will improve as well.

Using this approach, architects work with several stakeholders, including business managers, process experts, project management officers and the likes to estimate the contribution of each improvement (implementation event) against the relevant KPIs. The result of this is shown in the table below.

The table shows the relevant KPIs (rows in the table), the baseline value and subsequent improvements, and their expected contribution to KPI improvement. If we add all contributions within this scope’s time frame, we get to an expected KPI value (see the After column).
This answers whether currently planned improvements on the roadmap will bring us the KPI performance we envision.

Caption: KPI table for business process: ‘Execute Payment 

The same data can also be presented as a line chart where the progression of KPI improvement is visualized in alignment with the Process Roadmap. The blue line in the chart represents the Expected KPI value, and we see an increase at each point where we expect to deliver an improvement (implementation event). The green line represents the envisioned target KPI value.

Caption: Roadmap for process Payment Execution, with KPI progression charts 

In our example based on the ‘Payment Execution’ process, we clearly see both in the table view, and the chart views that the current Roadmap overachieves for the Process digitization (%)  KPI, but we fall slightly short for Revenue from digital services (%). These results may be used to reconsider priorities in the next iteration of the Capability-Based Planning process.

5. Conclusion

In this article, we proposed an enhancement to the Capability-based Planning process to support its Control phase and bring a more quantitative view of the Strategic Roadmap(s). By doing this, architects can prove the effectiveness of a Future State Design.
This also provides a very important input into managing the work packages that should implement the Future State Design. In the real world, the management of these work packages is covered by Project Portfolio Management (PPM) processes. Prioritizing and balancing a portfolio of projects becomes much better informed using the input from the Capability-Based Planning process.

The Control phase is the last step in this process. But of course, this isn’t the end since, in the meantime, many things may have changed inside or outside the organization. This requires us to adapt the Strategic Roadmap(s) by going into another iteration of the Capability-Based Planning process, which aligns well with the yearly strategic planning cycle we see in many organizations.

The post Use Capability Based Planning to measure successful change investments appeared first on Bizzdesign

Capability Based Planning: Our Approach to Capability Governance Latest news from (my website): Bizzdesign

Bizzdesign’s approach to capability-based planning and ‘capability governance’ in particular is similar to BIZBOK’s but more pragmatic. Most importantly, it takes into account that many business architecture initiatives start from the IT organization as well as from a lower level of maturity. We often see that the core of a capability mapping team comes from some architecture department or team that reports to the CIO. They, in turn, consult with leaders and experts from the business areas concerned, but these are often at some distance from the mapping effort itself.

DOWNLOAD: Get started with Capablity-based Planning ebook

We distinguish between the following roles:

• Sponsor: Whoever is investing in creating a Capability Map and needs insights from it to improve decision-making. This might be a business leader, but as we’ve argued before, in practice, it is often the CIO, Chief Digital Officer, or someone similar. The sponsor in a sense is the capability map owner (but not the owner of the capabilities on the map!)
• Business capability representative: These are business leaders with roots and reporting responsibility in the business. If the sponsor is located within IT (e.g. the CIO), business leaders are not always as closely involved as the BIZBOK® proposes, but they should at least be consulted and informed. We intentionally avoid terms such as ‘capability owner’, ‘manager’ or ‘accountability’ because that implies ‘being in control of something’. Since a capability model is independent of solution realization and organization structures, there could be too many relationships between capabilities and business leaders managing the organization. Hence, you can’t easily assign this kind of ownership to managers of teams, departments, or business units, since one capability might involve (parts of) many different departments. Moreover, when IT owns the overall Capability Map, subsets of it are unlikely to be owned by business leaders. Nevertheless, business leaders may identify with certain capabilities and therefore be suitable capability representatives.
• Subject matter expert: Someone who knows the day-to-day operations and details of the business in the area the capability describes. This professional is ideally from the business and an expert in a subject matter area. If this isn’t feasible, e.g. because of resource constraints, it could also be someone in IT who is in close contact with the business and has enough business expertise.
• Business architect: Has a good understanding of the business and is in touch with the SMEs. Ideally, business architects report to the business. However, when IT is the owner of the Capability Map, this role often sits in the enterprise architecture team, which may be part of the CIO/ Digitization/ Transformation Office.
• Capability steward: As part of their role, business architects are the stewards of one or more (groups of) capabilities, responsible for a sound structure of the capability model, no overlap, good naming, descriptions, and updated visualizations to support the sponsor’s decision making. These stewards facilitate workshops or meetings to create and update the Capability Map, related visualizations and reports.
• Business contact: Someone in the business domain of the relevant capability area. Contact of the Subject Matter Expert (or Business Architect) to be consulted to get insights and input for the business architecture. This role is typically the second line of support for SMEs, especially when they are not located in the business themselves.
• Benefits manager: A role that originated in project portfolio management. Someone who identifies, plans, measures, and tracks the benefits of business architecture and the business capabilities themselves. This is key to growing the maturity of your business capabilities and your business architecture practice.
• Mentor: As in the BIZBOK, an experienced business architect can guide the team and helps grow their business architecture approach.

The first three roles are must-haves (Sponsor, Subject Matter Expert, Business Architect). The rest of the roles accelerate the usage of a Business Capability Map 

Again, the same individual might play more than one role, as is already apparent from the Capability Steward role, which forms part of what a Business Architect does. Note that we don’t distinguish separate roles for Team Leader and Architecture Mapping Expert. Business architects can often self-organize without needing a formal, hierarchical team leader. Moreover, any Business Architect worth their salt should be well-versed in capability mapping and other description techniques, so this doesn’t need to be a separate role. Nevertheless, in a larger business architecture team, some members might focus more on e.g. stakeholder communication and engagement, and others on managing the architecture knowledge base or creating beautiful architecture artifacts.

We also introduced two specific roles: the Capability Steward and the Benefits Manager. The first is important because you can’t readily assign formal business ownership to capabilities. You’ll need the right architectural expertise to develop a sound capability structure. The second is key because we acknowledge that Capability-based Planning teams often start from a low level of maturity and need to grow their capabilities. To this end, you’ll need to track and measure what you’re doing as a Business Architecture /Capability-based Planning team and apply this to the actual business capabilities themselves. How is your work as a team having an impact and where can you improve your way of working and results?

Pragmatic starting point

As you’ve seen, our approach to Capability Governance intentionally deviates somewhat from the BIZBOK® Guide and other frameworks that state that capabilities should be owned by ‘the business’. Although we agree in principle, we have to be realistic. Our approach reflects what we see in practice and provides a starting point to demonstrate the value of using Capability Maps and Capability-based Planning for investment allocation of IT budgets. It explicitly states that it starts with deviating from best practices but keeps in touch with relevant business roles. That helps you avoid turning a business Capability Map into an IT Capability Map.

Once you have established the value of capability thinking in the context of business-focused IT investment planning, you can evolve this into ‘true’ business architecture, purely focused on the architecture of ‘the business of the business rather than the architecture of the business as IT interacts with it.

The post Capability Based Planning: Our Approach to Capability Governance appeared first on Bizzdesign

Capability Governance: Roles and responsibilities in Capability-based Planning Latest news from (my website): Bizzdesign

Introduction

Capability-based planning is a crucial approach within the realm of Business Architecture that helps organizations align their strategic goals with operational execution. In Capability-Based Planning, defining clear roles and responsibilities is key to successful capability governance. This blog explores how to effectively manage business capabilities, drawing insights from the BIZBOK® Guide’s idealist approach and Bizzdesign’s practical framework for capability governance. Learn how to establish who does what to drive efficient and aligned decision-making within your organization.

Our comprehensive ebook is a must-read for a deeper dive into the world of Capability-Based Planning and how it can drive strategic alignment within your organization. This resource explores the step-by-step approach to implementing Capability-Based Planning, offering valuable insights and practical tools to help you future-proof your enterprise.

Subheadline BIZBOK® Roles in Business Capability Governance

The BIZBOK® Guide distinguishes the following roles in Capability-based Planning:

• Business sponsor: Since the business owns business architecture, sponsorship must be established within the business. Often, a CIO can assist with building sponsorship support within steering committees or transformation teams.
• Team leader: Business architecture teams should be led by business leaders with roots and reporting responsibility.
• Subject matter expert: Business professionals with knowledge of all major aspects of the business, such as major customer-facing capabilities and value streams. They’re expected to participate in drafting level 1 and 2 capabilities in meetings that cross their subject area. They may also facilitate workshops to establish accountability for business ownership and provide expertise.
• Business architects: Their role is to look beyond traditional business concepts and create and socialize business architecture. In larger organizations, multiple subtypes of this role often exist, typically aligned with business subject area expertise.
• Architecture mapping expert: This role involves assembling and organizing capability analysis results into a formal knowledge base and developing the required formal and ad hoc blueprints. It also requires tool expertise to meet blueprint mapping and knowledge-base governance requirements.
• Mentor: Someone well-versed in Capability Mapping and Business Architecture in general, who provides behind-the-scenes guidance for team building, governance, mapping, blueprint creation, and integration into strategies, projects, and related architecture.

Note that the same individual can sometimes play multiple roles. For instance, a senior business architect may also be a mentor or team leader. Typically, these individuals form a virtual team and aren’t hierarchically subordinate to any single senior manager or executive.

Practical considerations

As the BIZBOK® Guide rightly states: ‘Business architecture governance ‘must be based on the premise of business ownership, business sponsorship, and representation from essential business areas’. In practice, however, this approach requires a high level of maturity from the enterprise and its business architecture practice. Organizations that have just started on a business architecture journey may find it difficult to get the level of ownership and participation by business sponsors, management, and experts that this approach advocates.

Additionally, the conceptual thinking used in enterprise, business, and IT architecture is often unfamiliar to business stakeholders. It takes time to convince business leaders of the value of such an approach. The best way to overcome this is to ‘show, don’t tell’. Build business architecture artifacts that provide value to decision-makers, and the demand for business architecture will grow.

Often, this will start in IT before closely involving the business because that’s where this architectural way of thinking originates. Hence it is easier to work with IT stakeholders and build your initial business architecture artifacts there, sharing them with business leaders and experts later.

Moreover, and despite its name, rather than starting directly from ‘the business’ (which is already an IT term for everything non-IT), IT leaders who recognize the value of a business perspective on IT architecture to support their decision-making often initiate a business architecture practice. From this business-oriented IT architecture, an architecture perspective on the enterprise’s business may evolve, and as a result, a true business architecture discipline may be initiated.

For instance, a typical scenario is where a forward-looking CIO wants to base IT investment decisions on the envisaged future capabilities of the enterprise rather than on classical budgeting per department. To this end, a group of business architects is formed from the existing enterprise and IT architecture teams. This group is tasked with creating a Capability Map and other artifacts to support a capability-based planning initiative for IT investments.

The resulting Capability Map may still be quite IT-focused, reflecting subdivisions and functionalities of the application landscape rather than true business capabilities. That may not be all bad, though: if the structure is sound enough to support IT decision-making with a business focus, you have already taken a first step in the right direction. If you restrict your Capability Map to two or three levels deep, you can limit the risk of creating a map that is too IT-focused because you typically think in more general terms at these higher levels. It also makes it easier to maintain and update the Capability Map; use the documentation fields of your Enterprise Architecture tool if you like to capture more details of what happens ‘inside’ these capabilities, rather than creating sub-capabilities for everything. Progressively refactoring and refining the map to become a true business capability map may be a more fruitful approach than trying to get it right the first time, which is nearly impossible for an inexperienced team with limited business involvement.

In any case, we advise that you take an iterative and incremental approach. Too often, we’ve seen capability mapping initiatives that took many months or stalled before delivering any meaningful value simply because of the perceived need to be complete in both breadth and depth.

Instead, we would start with a broad but shallow level 1 map, from which we zoom in on specific areas based on two criteria:

• Business relevance: Are these capabilities strategically relevant or business critical? Avoid spending too much time on commodities and supporting capabilities just to be complete.
• Cooperation between the right people: Can you involve the relevant leaders and experts in the area of interest, and are they willing to spend time on this?

Bizzdesign’s approach to Capability-based Governance

Bizzdesign’s approach to capability-based planning and ‘capability governance’ is similar to BIZBOK’s but more pragmatic. Most importantly, it takes into account that many business architecture initiatives start from the IT organization as well as from a lower level of maturity. We often see that the core of a capability mapping team comes from some architecture department or team that reports to the CIO. They, in turn, consult with leaders and experts from the business areas concerned, but these are often far from the mapping effort itself.

We distinguish between the following roles:

• Sponsor: Whoever is investing in creating a Capability Map needs insights to improve decision-making. This might be a business leader, but as we’ve argued before, it is often the CIO, Chief Digital Officer, or someone similar in practice. The sponsor in a sense is the capability map owner (but not the owner of the capabilities on the map!)
• Business capability representative: These are business leaders with roots and reporting responsibility. If the sponsor is located within IT (e.g. the CIO), business leaders are not always as closely involved as the BIZBOK® proposes, but they should at least be consulted and informed. We intentionally avoid terms such as ‘capability owner’, ‘manager’ or ‘accountability’ because that implies ‘being in control of something’. Since a capability model is independent of solution realization and organization structures, there could be too many relationships between capabilities and business leaders managing the organization. Hence, you can’t easily assign this kind of ownership to managers of teams, departments, or business units, since one capability might involve (parts of) many different departments. Moreover, when IT owns the overall Capability Map, subsets of it are unlikely to be owned by business leaders. Nevertheless, business leaders may identify with certain capabilities and therefore be suitable capability representatives.
• Subject matter expert: Someone who knows the day-to-day operations and details of the business in the area the capability describes. This professional is ideally from the business and an expert in a subject matter area. If this isn’t feasible, e.g. because of resource constraints, it could also be someone in IT who is in close contact with the business and has enough business expertise.
• Business architect: This person has a good understanding of the business and is in touch with the SMEs. Ideally, business architects report to the business. However, when IT owns the Capability Map, this role often falls in the enterprise architecture team, which may be part of the CIO/ Digitization/ Transformation Office.
• Capability steward: As part of their role, business architects are the stewards of one or more (groups of) capabilities. They are responsible for a sound structure of the capability model, no overlap, good naming and descriptions, and updated visualizations to support the sponsor’s decision-making. These stewards facilitate workshops or meetings to create and update the Capability Map, related visualizations, and reports.
• Business contact: Someone in the business domain of the relevant capability area. This is the contact of the Subject Matter Expert (or Business Architect) to be consulted to get insights and input for the business architecture. This role is typically the second line of support for SMEs, especially when they are not located in the business themselves.
• Benefits manager: A role that originated in project portfolio management. Someone who identifies, plans, measures, and tracks the benefits of business architecture and the business capabilities themselves. This is key to growing the maturity of your business capabilities and architecture practice.
• Mentor: As in the BIZBOK, an experienced business architect can guide the team and helps grow their business architecture approach.

The first three roles in the image below are ‘must-haves’ (Sponsor, Subject Matter Expert, Business Architect). The rest of the roles accelerate the usage of a Business Capability Map.

Again, the same individual might play more than one role, as is already apparent from the Capability Steward role, which forms part of what a Business Architect does. Note that we don’t distinguish separate roles for Team Leader and Architecture Mapping Expert. Business architects can often self-organize without needing a formal, hierarchical team leader. Moreover, any Business Architect worth their salt should be well-versed in capability mapping and other description techniques, so this doesn’t need to be a separate role. Nevertheless, in a larger business architecture team, some members might focus more on, e.g., stakeholder communication and engagement, and others on managing the architecture knowledge base or creating beautiful architecture artifacts.

We also introduced two specific roles: the Capability Steward and the Benefits Manager. The first is important because you can’t readily assign formal business ownership to capabilities. You’ll need the right architectural expertise to develop a sound capability structure. The second is key because we acknowledge that Capability-based Planning teams often start from a low level of maturity and need to grow their capabilities. To this end, you’ll need to track and measure what you’re doing as a Business Architecture /Capability-based Planning team and apply this to the actual business capabilities themselves. How is your work as a team impacting, and where can you improve your work and results?

Where to start? A pragmatic starting point

As you’ve seen, our approach to Capability Governance deviates somewhat from the BIZBOK® Guide and other frameworks stating that capabilities should be owned by ‘the business’. Although we agree in principle, we have to be realistic. Our approach reflects what we see in practice. It provides a starting point to demonstrate the value of using Capability Maps and Capability-based Planning for investment allocation of IT budgets. It explicitly states that it starts with deviating from best practices but keeps in touch with relevant business roles. That helps you avoid turning a business Capability Map into an IT Capability Map.

Once you have established the value of capability thinking in the context of business-focused IT investment planning, you can evolve this into ‘true’ business architecture, purely focused on the architecture of ‘the business of the business rather than the architecture of the business as IT interacts with it.

Schedule time with one of our experts if you need help with Capability-based Planning.

About the authors:

Marc Lankhorst

Managing Consultant & Chief Technology Evangelist at Bizzdesign

Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spread the word about the Open Group’s ArchiMate® standard for enterprise architecture modeling, which he has been managing the development of. His expertise and interests range from enterprise and IT architecture to business process management.

Bernd Ihnen

Managing Consultant at Bizzdesign

Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.

The post Capability Governance: Roles and responsibilities in Capability-based Planning appeared first on Bizzdesign

How the Capability-based Planning process drives strategic change Latest news from (my website): Bizzdesign

Editor’s Note: Business Capabilities are a cornerstone of Business Architecture, and understanding how to implement them is key to success. To guide you through Capability-Based Planning, we’ve created an ultimate eBook, filled with expert insights, strategies, and practical advice to ensure you’re on the right track. This blog post is an excerpt from our eBook.

Designing future state architectures

Architects are crucial in driving Capability-Based Change because they provide the strategic vision and technical expertise to align business objectives with operational execution. Through Capability-Based Planning, architects ensure that the organization’s core capabilities—encompassing people, processes, technology, and data—are optimized to support long-term strategic goals. By mapping current capabilities and identifying gaps, architects can prioritize investments and plan initiatives that address critical weaknesses while preparing the organization for future challenges. Their ability to guide capability-based change through future state architecture design helps ensure business transformations are structured, sustainable, and fully aligned with strategic outcomes. In this blog, we show you the planning stages for future state architectures.

Capability-based Planning Process for future state design

1. Gap analysis

Executing your organization’s strategy requires a wide set of business-as-usual processes to work sufficiently to deliver the strategic goals. Where those processes are insufficient, there is a gap—i.e., something needs to be done to raise performance.

Business capabilities are a great language for describing gaps since they’re stable over time, have definitions, and are enterprise-wide. Most importantly, they can map upwards to strategy and map downwards to people, processes, technology, and data, and their maturity can be evaluated by assessing these dimensions. We explain this process in detail in our eBook.

2. Gap prioritization

Having obtained a list of underperforming capabilities, the challenge is to decide which capabilities most need improvement. A scientific/objective approach is needed to quantify each capability so they can be ranked. We recommend the following:

• You need to consider both the current and the future state, with the future state being derived from your enterprise’s goals.
• Strategic Importance and Maturity are common dimensions stakeholders use to decide which capabilities to invest in.
• To put figures against a capability, measure it in terms of its people, process, technology and data components.

3. Investment allocation

With a set of capabilities quantified against your chosen dimensions, you now need to decide where to allocate budget and people. Break this complicated decision into two stages:
Filter your capabilities to consider only the ones worth investing in – which you can do by only considering ‘strategically important’ capabilities that have a maturity below a certain threshold. However, don’t ignore that you’ll need enabling capabilities that aren’t strategic but are nonetheless critical for supporting your strategic capabilities.
Generate a metric for ranking the capabilities.

4. Future state modeling

The Investment Allocation step results in a list of the capabilities that receive investment. The aim is to determine what changes will be made to improve these capabilities. This means that two aspects need to be considered:
Mapping the capabilities of their people, process, technology, and data components to show the tangible impacts.
Creating different scenarios for the changes, e.g., one option could see people significantly changing work practices but keeping the technology the same.

Decision-makers can then review these To-Be options and decide which is best for the organization. The significant advantage of using capabilities is that changes to related parts of the organization can be considered together and aren’t viewed in isolation.

Below is an example of a target operating model where a capability is broken down into processes, applications, and data. In this case, the people dimension is left out because it is quite simple: a single team performs all the payment processes. In other cases, this may be more complicated, involving different roles and the requisite skills, etc.

5. Initiative formulation

Once the future state models have been decided, creating a work package to implement each To-Be model is easy. However, the risk is that a complicated network of dependencies is created and that a large number of overlapping work packages compete for the same resources (e.g., subject matter experts, IT operations staff). This increases the complexity and risk of your deliveries and raises costs and time to market.

To mitigate this, you can restructure your work packages to align with one or more business capabilities. This allows you to focus on changing only specific parts of the organization and minimizing the impacts on key resources. It also doesn’t matter if you’re using agile or waterfall methodologies because alignment to business capabilities improves the efficiency and effectiveness of your transformation.

6. Business Capability roadmap generation

The initiatives provide the means for delivering the capability improvements, and these two dimensions can be laid out against time on a roadmap. The roadmap below shows how the capabilities identified in the Gap Analysis and selected in Investment Allocation are then improved over time by work packages implementing capability increments.

ALSO READ: “Modeling Capability Increments and Capability Instances to Support Roadmapping”

Capability-Based planning timeline 

Conclusion: Focus on Capability-based Planning

Using business capabilities to do planning may seem daunting at first, but it gives you a common language across your organization – a language that remains the same year after year. You can use this language with all your stakeholders, from executives to implementers, and describe the end-to-end process from strategy to execution. Moreover, this analysis is already happening to some degree in every enterprise. So, it’s a case of introducing capabilities to simplify the process and make it more effective.

Try the process described in this blog, and let us know if you need any help. Good luck with getting tighter control over your transformation!

About the authors:

Sven van Dijk

Pre-Sales Consultant at Bizzdesign

Sven has experience in Enterprise Architecture, Business Process Modellng and other business engineering disciplines. He has worked with various international organizations on use cases including Capability-based Planning, Risk and Security, and IT architecture in various projects. He has extensive knowledge on structured methods and tools, including ArchiMate, BPMN, TOGAF etc.

Jeeps Rekhi

Customer Success Consultant

Jeeps has 25 years of experience in defining and delivering strategic and operational change. He is a senior enterprise-wide business architect who has specialized in data and digital transformation and knows how to harness value across business, operations and technology.

The post How the Capability-based Planning process drives strategic change appeared first on Bizzdesign

How to model Business Capability Increments and Instances Latest news from (my website): Bizzdesign

Editor’s Note: Business Capabilities are a cornerstone of Business Architecture, and understanding how to implement them is key to success. To guide you through Capability-Based Planning, we’ve created an ultimate eBook, filled with expert insights, strategies, and practical advice to ensure you’re on the right track. This blog post is an excerpt from our eBook.

Introduction: Modeling Business Capabilities over time

So far in our blog series, the Business Capability models we’ve used are relatively simple in structure. In our previous blog post on capability measurement, we promised to provide more detail on how to model capabilities over time and describe different instances.

The same business capability may be implemented differently across the enterprise in business units or regional organizations in larger organizations. For example, in a multi-national company, local customs and regulations may realize the same Human Resource Management capabilities differently. As shown in the figure below, these specific versions can be modeled as a specialization of the same generic capability.

Regional capability instances specialize in the same generic capability 

Each of these instances, in turn, is realized by various other elements (people, process, information, technology) from each region. Perhaps some of those are again standardized across the entire organization, say an HR application used globally. Others are local, like the individual HR departments of each business unit.

These instances can be assessed separately in the ways described in our previous blogs on capability measurement and maturity assessment. From these assessments, you can calculate an average maturity, but perhaps more importantly, you can analyze which instances perform best and share best practices with other instances. You can increase global maturity by fostering an internal learning process.

Modeling Business Capability Increments and Releases

The evolution of capabilities is often expressed in so-called ‘increments .’Each increment represents a stable state of a capability that exists for a certain time. These increments can also be considered specializations of a generic capability. In this case, they don’t represent local differences like the capability instances discussed above, but differences that occur over time. If you need to use both increments and instances in conjunction, an instance will typically have its increments, not the other way around. For example, each of the regional HR capabilities above might evolve at its own pace.

The figure below shows a simple roadmap where the Customer Management capability is improved in stages by three ArchiMate work packages that model the change activities: to homogenize the information and data on customers across business units, to improve global access to that data, and to harmonize billing processes across different business units. The end date of each of these is when the corresponding capability increment is fully realized, so that’s the start date of the increment. You could mark this as a milestone on your roadmap.

Figure 2. Capability increments and projects realizing these 

If we look at each of these changes in more detail, we would see that those change activities impact specific elements that contribute to the realization of the increment. For instance, ‘Harmonize billing process’ mainly impacts the project dimension of ‘Customer Management increment 3’ by improving the billing process, which underpins this capability dimension. See also our previous blog on capability assessment dimensions.

Organizing business capability increments in releases

We can organize capability increments in releases resulting from a series of sprints (Figure 3). This view shows the release planning and, for Release 1, also the (simplified) sprint planning. This way, you can analyze what happens to the availability of your solution if an agile team decides to move a certain feature to a later sprint, for instance. In the underlying model (but not shown in the figure), all the elements created or changed in the two sprints contribute to the first capability increment. Of course, this is a highly simplified figure for explanatory purposes. The real roadmap is much more extensive and includes improvements to several capabilities.

Figure 3: High-level and detailed roadmap stages

The further you look ahead, the less tangible and specific your roadmap will be. Hence, the ArchiMate concepts for the near-term future are typically the concrete and detailed business, application, and technology layer elements. For the medium-term future, you might use the more abstract, high-level capability and resource concepts, and you might express the longer term using only goals and outcomes.

ArchiMate’s graphical notation for plateaus is mainly useful for mapping such an evolution rather than depicting the architecture itself since many elements in your architecture are part of several plateaus. For example, anything in the baseline that survives through the transitions above is part of all plateaus on the roadmap. That would clutter a figure like the above. For that reason, we often use plateaus in an architecture model but not necessarily in a view.

Highlighting plateaus in architecture

Often, we enter the aggregation relationships between plateaus and their content in a cross-reference table and use this in views and analyses. The image below shows an example of such an analysis, highlighting elements based on the plateaus they’re part of, based on the same scenario shown above. Such a heatmap quickly shows the impact of changes to your architecture.

Figure 4: Highlighting plateaus in the architecture 

Next to the coarse-grained capability-level roadmap outlined above, you can model that some elements in the architecture are improved in more specific ways. Using the same technique as for capability increments, you could, for instance, model the generic application component ‘General CRM System’ with specializations for versions like ‘General CRM System 3.2’, ‘General CRM System 3.3’ and ‘General CRM System 4.0’. Each of these can, in turn, be related to a plateau that starts on the release or deployment date of this version and ends when it is replaced by the next.

The same modeling technique can also model deployed instances of e.g. applications, as we explained in an earlier blog post. But be careful with modeling too much detail and tracking every individual release of an application or instance of a server type as a separate object in your enterprise architecture. This is probably more detail than you need or want to maintain.
Next to the architectural perspective with plateaus, we often see more precise dates being used. To avoid having many plateau objects tied to specific dates and periods, you can enrich your model with attributes. In this way, you can combine detailed release dates with high-level architecture plateau planning.

Schedule time with one of our experts if you need help with Capability-based Planning.

About the authors:

Marc Lankhorst

Managing Consultant & Chief Technology Evangelist at Bizzdesign

Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spreads the word on the Open Group’s ArchiMate® standard for enterprise architecture modeling, of which he has been managing the development. His expertise and interests range from enterprise and IT architecture to business process management.

Bernd Ihnen

Managing Consultant at Bizzdesign

Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.

The post How to model Business Capability Increments and Instances appeared first on Bizzdesign

How To Measure Business Capability Aspects So You Can Execute Your Organization’s Transformation Strategy? Latest news from (my website): Bizzdesign

To effectively assess a business capability and execute Capability-based Planning, we need to define and measure three dimensions: Strategic Importance, Capability Maturity, and Adaptability. Simply put, the first dimension lets you prioritize those capabilities that are most important to your enterprise; the second focuses on where improvement may be needed because the current maturity is too low; and the third looks at how easy or difficult it will be to make that improvement.

Recap: The three dimensions that help us assess Business Capabilities are:

• Strategic Importance: How relevant or critical is a capability for the success of the business? This is determined in terms of its contribution to strategy execution, to the business or operating model, and to the future opportunities it provides.
• Capability Maturity: How good are we at performing this capability? This is measured in the common dimensions of people, process, information and technology.
• Adaptability: How easy or difficult would it be to change this capability? This is assessed by looking at its adaptability to the environment, to the needs of the customer, and to changes in demand.

Read more in our blog: An Approach: How to Assess Business Capabilities?

How do you measure the dimensions?

Most common capability assessment models use a five-level scale, probably under the influence of the CMMI maturity model for software development

1. Performed
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing

Each level has a definition, e.g. level 4 means that your capabilities or processes are measured with quantitative (e.g. statistical) techniques, with quality and performance objectives used as criteria in managing them. A detailed assessment can evaluate various aspects of each capability, and the results can be analyzed quantitatively. This works if you want to assess a relatively small number of capabilities on domain-specific aspects. For instance, in assessing software development capabilities or processes, you can look at software defects, rework, user satisfaction, and many other metrics as input.

Doing a broad, possibly enterprise-wide, capability assessment, such as a detailed analysis, often takes too much effort. Alternatively, you could put experts in a room and ask them to rank each capability on a 1-5 scale. However, this would rely too much on personal opinion and doesn’t give these experts a foundation for their evaluation.

Our approach aims to take the middle ground. We let such a group of experts score their agreement with a number of statements about each capability on a 5-point Likert scale from ‘strongly disagree’ to ‘strongly agree’. By limiting the number of statements per aspect and dimension, we keep the required effort to a manageable level. As an example, the Process dimension of Capability Maturity includes statements such as:

• “Each process has a clear owner who is accountable for performance.”
• “Processes are monitored with success measures that are regularly reported.”
• “Processes for the capability are fully optimized and efficient.”

For each statement, the average score of the experts is entered into the assessment model. Together, the resulting scores for a set of statements are averaged, resulting in a value for that dimension. The values for each dimension can, in turn, be averaged to calculate the overall maturity of the capability.

Capability Assessment in Bizzdesign Horizzon

In Bizzdesign Horizzon, you can use fields in data blocks to enter these assessment scores. With calculated fields, you can define an expression to compute the average across the fields for each statement and another one to calculate the overall average maturity level. You can also make this a weighted average if some dimension is more important than another.

The resulting data can be shown in Bizzdesign Horizzon in several ways, such as a heat map of your Capability Map, helping you pinpoint issues such as below-par capabilities that require management attention and investment priority. In a previous blog post on relating capabilities to your strategy and business model, we already showed an example of such a heat map, depicting the strategic importance of capabilities together with their investment levels. Similar views can, of course, be created for maturity and adaptability.

A capability heat map with IT investment levels (color) vs. strategic importance (label) 

Further Analysis

Analyzing this data helps you pinpoint the pain points, where the difference between where you are and where you want to be is the greatest. Typically, high strategic importance and a low maturity business capability must be investigated first. You want to analyze in-depth those aspects where the difference between current and desired maturity is the largest.

At the same time, you may find that such a capability is not very adaptable. You may first need to invest in improving this adaptability otherwise other changes may be too difficult, time-consuming, and costly. This is the typical worst-case scenario: a capability that’s very rigid because it heavily depends on legacy software that’s difficult to change but which is core to the operation of your enterprise, and needs urgent uplifting to keep up with competitors and customer demands.

This data can be used in many ways to support business decision-making. For instance, in Capability-based Planning you want to plan capability improvements in the most effective way, investing where it counts and when it counts. Change initiatives could be scored by the capability improvements they provide and the concrete contribution of those improvements to strategic goals and other KPIs. Based on this, they could be compared and ranked. One way of doing this is using the Cost of Delay of each initiative, which in turn is input for Weighted Shortest Job First prioritization of change initiatives.

Assessing and improving capabilities can become more complicated in large, geographically dispersed enterprises with multiple instances (implementations) of the same capability. Moreover, to describe the evolution of your capabilities (or rather these instances), you would typically model capability increments.

The post How To Measure Business Capability Aspects So You Can Execute Your Organization’s Transformation Strategy? appeared first on Bizzdesign

Capability-based Planning: How to assess Business Capabilities Latest news from (my website): Bizzdesign

Capability-Based Planning activities are structured in a cycle: Map, assess, plan, and control. It shows us where to begin and the next steps to gradually increase the impact on the organization. In the “Map” phase, we define and create the Capability Map, which we can use to analyze the organization, assessing the strategic and architectural alignment of the capability framework. In earlier installments of this blog series, we provided guidance on achieving this.

This blog explores the “Assess” phase, where Capabilities are measured based on their contribution to our business strategy and identifying opportunities to improve maturity. This is visualized on the Capability Map, e.g. using heatmapping techniques.

Capability-Based Planning Approach

Capability Assessment Approach

Our approach to assessing Business Capabilities includes defining three dimensions. To effectively assess Capabilities and execute Capability-Based Planning, we need to combine these three dimensions because there are clear relationships and dependence between them. These three dimensions are:

1. Strategic Importance
   As explained before, Business Capabilities link to the strategic objectives of an enterprise. From this, we can derive their relative strategic importance to the organization. Executives must prioritize and focus investment on the right Capabilities and for managers to understand which Capabilities are critical to success. The key question answered here is: “Which Capabilities are required to successfully deliver a strategy?” For this dimension, we’ve identified three key metrics relevant for an assessment of the Strategic Importance of a Business Capability:
   – Strategy Execution: Is the Capability required in the context of a strategic goal?
   – Business/ Operating Model: Does the Capability provide critical support or resource for a key value proposition?
   – Future Opportunity: Does the Capability provide critical support or resources for future enhanced or new value propositions?

   
   Strategic Importance Dimensions

2. Maturity
   In a Capability Map, we define the set of Capabilities that an organization requires to be successful against its formulated strategy. However, just having the Capability in place isn’t enough because we also need to be very good at it, especially those Capabilities with high strategic importance. For managers, an assessment of Capabilities based on maturity identifies where improvement and development are required. It shows both change leaders and change experts where the key problems lie.

   
   Maturity dimensions

   The key question answered here is: “Which Capabilities are currently performing below expected or required performance levels?”. These are the Capabilities that may require investing in various improvements. You would typically prioritize those dimensions where the highest difference between current and target levels is.

   The maturity of a Business Capability is determined based on its maturity in the common dimensions of People, Processes, Technology, and Information.

   

3. Adaptability
   Capability-based Planning is not a one-off exercise: an organization needs to align strategic goals with the required Capability, and continuously retain this alignment as strategic goals may shift. As we have argued in the past, adaptability is essential for the modern enterprise. Any organization needs the flexibility to respond to changes in the environment and the ecosystem. An assessment of adaptability gives executives insights into how easy it is to change Capabilities, and for managers on which Capabilities need to be more flexible or resilient.The key question answered here is: “Which Capabilities are problematic to improve?”In our vision, there are three key metrics important to determine the level of adaptability of a Business Capability:
   – Adaptability to the environment: What’s the role of the Capability for the response to external (e.g. law or regulation) and internal (e.g. business interruption) dynamics?
   – Adaptability to the customer: What’s the role of the Capability for the response to changing customer needs?
   – Capacity: Can the Capability respond to changing demand?

   
   Adaptability dimensions

What’s next?

In the next installment in our Blog Series: Business Architecture and Capability-Based Planning, we’ll look at how you can assess Capabilities with Bizzdesign Horizzon.

You’ll learn how:

• To determine a meaningful score on the key metrics relevant for an assessment of the Strategic Importance of a Business Capability
• The maturity of a Business Capability is determined in relation to people, processes, technology, and information
• Bizzdesign Horizzon supports the assessment of Capabilities

The post Capability-based Planning: How to assess Business Capabilities appeared first on Bizzdesign

Business Capability Maps design principles: Part 2 – decomposition and how to start Latest news from (my website): Bizzdesign

Quick links:

• Introduction: What are Business Capabilities?
• Defining Business Capabilities in business terms
• Business Capability decomposition
• How to start your Business Architecture journey
• About the authors

Editor’s note:
Capabilities are fundamental to Business Architecture, making it essential to understand how to implement them effectively. To help you navigate Capability-Based Planning, we’ve created the ultimate eBook, packed with insights, strategies, and practical guidance to set you on the right path. This blog post focuses on Business Capability Maps, and is an excerpt from the eBook, providing a glimpse into the valuable content you’ll find inside.

Introduction: What are Business Capabilities?

Value is delivered to the enterprise when Business Capability Maps are readily accepted and adopted as a strategic planning tool. Business stakeholders can make data-driven decisions and align and prioritize investment decisions, among other things. In part 1 of our blog series on Business Capability Maps, we’ve identified design principles focusing on the stakeholders consuming the Capability Maps, the general structure of a map, and its visual appeal.

In this post, we share principles for the definition/ decomposition of a Business Capability Map and the first steps of how to start.

There are two general principles that you need to follow when you define Capabilities:

1. Business capabilities are represented and defined by the business: it’s not an ‘IT thing’!
2. Business capabilities are unique, mutually exclusive and collectively exhaustive: ensure that there are no duplicates, overlaps or gaps

Try to avoid duplicate or overlapping capability definitions, although this may be difficult in your first version of the Capability Map. You won’t know whether you have duplicates until you have created the first map! Business capabilities should be unique and mutually exclusive, and together they should cover your entire business. However, you may have variants of capability names such as Performance Measuring for financial performance, production, sales, etc. Always keep in mind the main stakeholder and the intended usage of your Capability Maps.

Defining Business Capabilities in business terms

The name of a capability needs to be clear for business leaders because they often don’t understand techspeak. Use business language that resonates with senior managers and other stakeholders instead of rigid naming conventions.
The name of a capability should emphasize ‘what we do’ rather than ‘how we do it’. It’s important to adopt names that resonate with senior managers and stakeholders. Typically expressed as a compound noun or gerund (-ing form of a verb). E.g. ‘Project Management’, ‘Market Development’, and ‘Product Engineering’. Capabilities are often based on a business object, e.g. ‘Product Design’, ‘Risk Assessment’, ‘Materials Procurement’, but don’t make this a naming convention restriction to avoid turning your capability map into a business object map.

Add short descriptions to your capabilities to make the definition of it clear. This will steer the stakeholders’ thinking process in the direction you intended. When you’re adding short descriptions, be:

•  Precise: Explain – don’t simply repeat the name of the capability in the description. For example, use the following wording: ‘the ability to…’.
•  Concise: Provide just enough details to indicate what is / what isn’t included.
• Informal: Focus on getting the message across by using phrases or single words and not grammatically correct sentences, which could take a lot of time to read.

Business capabilities are stable and implementation-neutral
Judy Goldberg, former Executive Director at Sony and founder of Wondershift rightly mentioned: “You don´t need a digital strategy. You need a business strategy for the digital age“. When describing a Business Capability Map, don’t distinguish between business and IT capabilities.

A case in point is that an enterprise that produces fruits has been doing the “same” over decades. Techniques and technologies for producing fruit may have changed over the years, but what the company does has remained the same provided that they haven’t changed their business model.

An automated capability is still a business and not an IT capability. The description of how you realize a capability is important, but this should be part of the operating model description that you design in ArchiMate with core concepts, such as functions, processes, application components and other business/ application/ technology concepts. These differences are described in the blog: “Capabilities vs. Business Functions: Same Difference?”

Business Capability decomposition

Important and challenging questions are: “Which capability elements do you ‘bundle’ together, and how do you decompose a Capability Map?”

Identify the capability resources with the highest cohesion. This is a general architecture design principle and will guide you on the path to designing an adaptive enterprise. Aim for high cohesion inside of a capability and loose coupling between capabilities. Cohesion is defined by strong relations between resources. These resources form a business capability and usually consist of people and their roles and skills, process, technology, information, infrastructure, and natural resources. Questions you need to discuss include:

• Which resource type has the highest cohesion?
•  Do we need to center a capability around information, buildings, machines…?

WATCH: For in-depth information on Business Capabilities, watch the webinar: Capability Maps the Next Generation presented by Wolfgang Goebl

Tip!: Keep the depth of the Business Capability Map similar. Use 2-3 or 3-4 levels, and not 1-3 or 2-4 levels. This will make your mapping and analysis efforts easier.

How to start your Business Architecture journey

Now that we’ve shared the design principles, you may wonder where to start. You need to have a mandate to architect a business capability map! Without proper sponsoring, you’ll have difficulty getting engagement from the required subject matter experts to resolve the inevitable issues/ conflicts. You also won’t have any customers for your Capability Map. Creating a Capability Map without a sponsor is, therefore, futile.

You’ll also need to know which analysis and decisions the sponsor wants to make based on the Business Capability Map. What’s the purpose? For a quick start, reuse existing internal and external information (e.g., previous Capability Maps, consultant findings), industry references (e.g., sector capability models), organizational charts, and process models. Use the design principles to define, refine, and test the Business Capability Map through socialization and validation cycles. Ensure that all the relevant business functions are included, not only IT.

If you have questions, please do not hesitate to contact us. We can give you a presentation that demonstrates the design principles described in this blog firsthand.

About the authors

Bernd Ihnen

Managing Consultant at Bizzdesign

Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.

Jeeps Rekhi

Customer Success Consultant at Bizzdesign

Jeeps has 25 years of experience in defining and delivering strategic and operational change. He is a senior enterprise-wide business architect who has specialized in data and digital transformation and knows how to harness value across business, operations and technology.

The post Business Capability Maps design principles: Part 2 – decomposition and how to start appeared first on Bizzdesign

Business Architecture becomes mainstream in the boardroom Latest news from (my website): Bizzdesign

Quick links

• Introduction: What is Business Architecture
• Why you need a composable architecture
• How to create a Business Capability Map
• Where to start?
• About the authors

Introduction: What is Business Architecture?

Business Architecture is gaining more traction among executives because it plays a key role in enabling organizations to transform into a composable enterprise, a term coined by research and advisory firm Gartner, Inc. Business Architecture is used by architects as a form of business analysis to identify business value that’s focused on what the business needs and exactly when it wants it. In this blog post, we give practical examples of how Business Architects leverage this discipline to enable executives to create a composable enterprise.

The idea behind the composable enterprise isn’t new. In 2006, the seminal book Enterprise Architecture as Strategy by Jeanne Ross et al. described it as’ business modularity’. The book provides an example of applying key architecture principles at the business level.

Gartner, Inc. defines a composable enterprise as an organization made from interchangeable building blocks. The firm researched how organizations build resilience in the face of great disruption and learned that “organizations that win the future are those that assemble and re-assemble their component parts at will. These organizations retain what works and shed what doesn’t.” The organization achieves this through the assembly and combination of packaged business capabilities.

Gartner, Inc predicts that “by 2023, 60% of mainstream organizations will list composable enterprise as a strategic objective and will use an increasing number of packaged business capabilities.”

Business Architecture is a key enabler for transforming organizations into composable businesses.

This discipline articulates business capabilities, value streams, organizational functions and boundaries, strategic drivers, and their links to business processes, projects, or programs. Essentially, Business Architecture maps the business strategy against real-world activities, such as business processes executed at the frontline. It provides executives with a holistic perspective of what the business does, where the problems are (such as gaps or areas of underperformance), and identifies opportunities for innovation.

Why you need a composable architecture

How can you create a composable architecture that delivers business outcomes and adapts to the pace of business change? A composable architecture is a foundation upon which a resilient enterprise is built. To ensure success, you must partner with executives who often don’t understand techspeak. You, therefore, need to help non-architects think like an architect. The only way you can do this is to ensure that you create content relevant to a non-IT audience and drill down into this content to provide evidence, in layman’s terms, to describe the organization’s operating models and where the problems lie.

Using a modern tool, such as Bizzdesign Horizon, you can design and model the different ‘architectures.’ At Bizzdesign, we focus on the use of Capabilities. These capabilities underpin the people, process, and technology operating model. Hence, Capabilities act as the central point through which scenarios can be planned and their impact traced through the business.

A Business Capability Map aims to support business executives’ strategic discussions and decisions. With such a map, you’ll be able to analyze your organization by looking at it holistically, through a business perspective lens. A Capability Map is drawn up in business language (it doesn’t include technology jargon) so that non-IT stakeholders can understand it easily. A well-understood Capability Map quickly becomes the backdrop for many different discussions.

Ideally, each capability is a self-contained unit or module, so you can exchange and compose them at will. In practice, things are less rosy, and capabilities may depend on each other in complex ways (e.g., via the resources they rely on). A key role of architects is to reduce those dependencies to support this notion of modularity/ composability.

How to create a Business Capability Map

For example, the Business Capability Map can add value to your decision-making in creating a composable enterprise by answering the following questions:

Q: How do I reduce team communication overheads by smartly partitioning them? E.g., using Conway’s Law.

Organizing your teams according to the capabilities they support can help in improving internal communications and reducing communication overhead.

Q: How can I quickly identify which parts of our business are at risk from a disruptive event?

This can be shown as a heatmap of the Capability Map in the above image, based on an analysis of the underlying resources. Examples include office buildings (e.g., a power outage), IT resources (e.g., cyber risk), or people (e.g., a pandemic). The heatmap below shows the health of the technology that underpins each of these capabilities based on data about the end-of-life of applications and the number of incidents reported. The orange ones are at risk.

Q: How can I invest smartly where it truly counts?

Classifying your capabilities according to their strategic importance and comparing this with their maturity helps you decide on investments in uplifting capabilities. The example below uses colors to show relative investment levels (green = low, red = high) and labels capabilities with their classification into Foundational, Distinctive, or Competitive. This helps you pinpoint strategically important capabilities that are underfunded. For example, several of the sub-capabilities in Customer Management are distinctive or competitive but receive little investment.

Where to start?

As business architects, our role is to spur value and innovation in our enterprises. We’ll do just that by using a business architecture model to design a composable enterprise! Executives will value the business perspectives from our modeling, and we’ll show them just how quickly and easily it is to adapt to change and build and deploy faster.

If you’d like to learn more about using Business Architecture to create a composable enterprise, please don’t hesitate to request a demo. BiZZdesign also offers a range of training courses to enhance your skills and ensure you become a master of Business Architecture. Check out our training courses here.

About the authors:

Marc Lankhorst

Managing Consultant & Chief Technology Evangelist at Bizzdesign

Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spreads the word on the Open Group’s ArchiMate® standard for enterprise architecture modeling, of which he has been managing the development. His expertise and interests range from enterprise and IT architecture to business process management.

Jeeps Rekhi

Customer Success Consultant at Bizzdesign

Jeeps has 25 years of experience in defining and delivering strategic and operational change. He is a senior enterprise-wide business architect who has specialized in data and digital transformation and knows how to harness value across business, operations and technology.

The post Business Architecture becomes mainstream in the boardroom appeared first on Bizzdesign

Business Capability Maps design principles: Part 1 – general structure and visual appeal Latest news from (my website): Bizzdesign

Editor’s note:
Capabilities are fundamental to Business Architecture, making it essential to understand how to implement them effectively. To help you navigate Capability-Based Planning, we’ve created the ultimate eBook, packed with insights, strategies, and practical guidance to set you on the right path. This blog post focuses on Business Capability Maps, and is an excerpt from the eBook, providing a glimpse into the valuable content you’ll find inside.

Introduction: What is a Business Capability Map?

Business Capability Maps are used for a variety of strategic change purposes to align business leaders and other stakeholders on investment decisions. Business Capabilities are not IT concepts but are used to describe the abilities of an enterprise, i.e. what activities it can do, either now or in the future, rather than how a business performs these activities. To successfully design business capabilities and business capability maps, it’s important to consider design principles for business stakeholders to accept and adopt Capability Maps as a strategic planning tool that conveys meaningful information.

In this blog, we’ll provide practical business capability design principles focusing on the stakeholder and the maps’ general structure and visual appeal (please refer to the image below). We’ll focus on capability definition and decomposition in part 2 of this blog series.

Design principles for Business Capability Maps

The stakeholder
Business Capability Maps enable C-level and senior management to look at the enterprise through the lens of capabilities to see what it does instead of seeing how it is done in the organizational structure, business processes, or from another perspective. Leadership uses capabilities to advance their strategy and guide investment plans. This has implications for the design of the Capability Map. What do you need to consider?

In practice, IT often drives Business Capability maps and this can have an effect on how capabilities are described, e.g. having technical wording. It’s essential to keep in mind that the Capability Map is used by business leaders. Therefore, the design description needs to match wording these leaders can understand in a technology-neutral manner. Suppose the Capability Map is not regarded as an accurate and meaningful description of the enterprise’s business activities (as perceived by senior business leadership), it will not gain traction as a collaboration tool for planning and business design.

Another important aspect to remember in terms of stakeholders is the positioning of other planning and design frameworks. Think of a Business Process Map or Application and Technology Portfolio categorizations. Will the Capability Map replace all those maps and frameworks? Certainly not, because these frameworks provide stakeholder-specific viewpoints. The Business Process Map looks at the enterprise through the lens of operational processes, and the application framework is a way to look at the IT landscape through the lens of Application Portfolios.

However, different maps and frameworks can be related. For instance, we have seen in practice that it’s useful to analyze which applications are related to which business capabilities, as well as which application portfolio category they belong to. This helps to connect different stakeholders, especially in the early stages of introducing the Business Capability Map to an organization.

ALSO READ: Get insights on Enterprise Architecture Management

Capability Map structure

A complete Business Capability Map typically includes many capabilities which need to be structured in a meaningful way. There are different approaches to categorizing business capabilities. For inspirational purposes, we’d like to give a few common approaches:

• Strategic vs. Operational vs. Supporting Capabilities
• Customer-facing vs. Operational vs. Shared vs. Change Capabilities
• Core vs. Non-core Capabilities
• Customer-facing vs. Internal Capabilities
• Innovative vs. Differentiating vs. Commodity Capabilities

In practice, we often see the first approach used to differentiate capabilities into strategic, operational, or supporting – for instance in the manufacturing sector, where the main focus is often on the operational capabilities relating to the production and delivery of the products.

Note that the classification of a Capability can vary depending on the industry or strategy of a company. For example, an HR capability in manufacturing is often classified as supporting capability, while in (consulting) services, it may have a more prominent role – depending on the company’s strategy. A customer-facing classification makes sense when looking at client-facing capabilities. The classification in innovative, differentiating, and commodity capabilities is inspired by the Gartner pace layering concept.

An ArchiSurance Capability Map that combines the following categories: Strategic vs. Operational vs. Support; and Innovative vs. Differentiating vs. Commodity as a heat map.

Visual appeal of a Capability Map

C-level and business leaders are typically very busy and they need to form an opinion quickly. Keep in mind that you only have 50 milliseconds to make a good first impression! It’s therefore advisable to give your Capability Model the necessary visual appeal to show its value clearly.

A first impression depends on different factors. Take into account the age, gender, and education of your audience to determine how colorful and complex your Capability Map will be. Someone with a technical background consumes information differently than someone with a background in finance or law (also common among senior business leaders). Design an engaging Capability Map with a clear structure, graphical structuring elements, corporate colors, and icons. Ensure that you align all the boxes to make a good impression. Although these suggestions may sound simple, it’s not applied by everyone, often because of tool limitations to model a Capability Map. For an example of a Capability Map that includes visually appealing corporate colors and graphical elements, refer to the ArchiSurance Capability Map above.

About the authors:

Nick Reed

Chief Strategy Officer at Bizzdesign

Nick is responsible for value proposition development, building strategic partnerships, and driving innovation topics, including executing Bizzdesign’s ‘buy & build’ acquisition strategy. He has over 25 years of experience in B2B enterprise software and SaaS, dedicating 15 years to enterprise architecture and portfolio management.

Bernd Ihnen

Managing Consultant at Bizzdesign

Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.

The post Business Capability Maps design principles: Part 1 – general structure and visual appeal appeared first on Bizzdesign

How to link Business Capabilities to the operating model in Business Architecture Latest news from (my website): Bizzdesign

Quick links:

• How they all relate: Capabilities, Business Functions and the Organization
• Using Capabilities and Business Functions together
• Summary: Word of advice for Business Architects
• Need help? Contact us
• About the authors

Editor’s Note: Business Capabilities are fundamental to Business Architecture, making it essential to understand how to implement them effectively. To help you navigate Capability-Based Planning, we’ve created the ultimate eBook, packed with insights, strategies, and practical guidance to set you on the right path. This blog post is an excerpt from the eBook, providing a glimpse into the valuable content you’ll find inside.

How they relate: Capabilities, Business Functions, the Organization

In this blog, we want specifically to answer the question: How does the enterprise’s operating model deliver capabilities? Let’s start by clearing up an important misunderstanding: a Capability Map is not a functional decomposition of the enterprise! We have written about this confusion in our blog: Capabilities vs Business Functions: Same difference?

Many Business Capability Maps are full of business functions or, even worse, resemble organizational charts. Business functions describe the day-to-day operations of the enterprise. Now, anything you do is something you can do. So, you could define a 1-to-1 related capability for each business function. But that isn’t a great way to use the concept since there are many things your enterprise could do that it doesn’t do on a day-to-day basis: it has capabilities beyond mere business functions.

As an example, we can use the military, which uses the expression ‘Boots on the ground’ to describe its potential to deploy troops anywhere in the world in 24 hours. However, it doesn’t have a business function, let alone a ‘Boots on the ground department.’ But ‘Boots on the ground’ is a capability.

Business functions express the concrete activities performed to deliver capabilities. In an ArchiMate model, you express this using a realization relationship: one or more business functions realize a capability. Next, you can define which departments perform these functions and which information and technology use them. That provides a line of sight between a capability and its realization.

The next figure provides an example: The capabilities “Money Management,” “Asset Management,” and “Policy and Claim Management” are realized by three business functions, with the “Investment Management” function involved in two capabilities. These functions are, in turn, performed by two responsible organizational units. This is the basis for your enterprise’s operating model.

Figure 1 Capability realization by business functions (and actors)

A similar mapping can be made between value streams, which describe your enterprise’s high-level value creation steps and the business processes that realize them. But we will leave that for another blog post.

Essentials of Business Architecture: Using Business Capabilities and Business Functions

In Business Architecture, the capability concept supports the collaboration of people from different disciplines. People’s ways of thinking vary depending on their background. We would like to share some observations from our practical experiences.

Managers often think about groups of people and their work (e.g., span of control, ownership, and responsibility). They, therefore, tend to interpret such a map as an organizational or functional structure. Similarly, people with an engineering background (especially in IT) think of functional decomposition. Both management and engineering have a design perspective where “this bit” of the enterprise or system (e.g., a department or component) needs to do “that piece of work” (e.g., perform a function or execute a business process). Neither of these worlds is natively familiar with the potentiality and dispositional nature of capabilities. The military are more advanced in their capability thinking. However, we have observed a tendency for them to mix up capabilities and resources, e.g. calling an aircraft carrier a capability (perhaps betraying the military’s obsession with hardware), rather than a resource (or collection of resources) that supports a capability like “Power Projection”.

Nevertheless, even if a capability map is too ‘functional,’ it can still be useful and offer a way for people to adapt to and adopt the concept. Just make sure it does not depend on any specific technology implementations or organization structures and stays focused on the ‘what’ rather than the ‘how’.

Summary: Word of advice for Business Architects

Our advice is to go back to the roots of Business Architecture and the capability concept and use it as you originally intended: Describe what the enterprise does or can do, in other words, its potential. That’s what gives it strategic relevance. Business functions performed by the various parts of the organization can contribute to realizing these capabilities but don’t create both a detailed capability map and an equally detailed business function map that covers the same ground. It is advisable to use them at their abstraction levels within a joined-up structure, e.g., using capabilities at the topmost two or three levels to express the high-level abilities of the enterprise.

Use business functions for more detailed levels, closer to implementation, to express the concrete activities you perform to deliver these higher-level abilities. In this way, different parts of the organization may also have their own distinct business function structure to deliver the same capabilities. If you then relate the various other operating model elements, such as the people (e.g., departments, teams, roles), processes, technology, and information to these business functions, you create traceability between capabilities and their realization(s).

Now you know how to relate a Capability Map to the operating model and which pitfalls to avoid when collaborating with different stakeholder groups. This was just one of the blogs in our series, which aims to show you how Business Architecture and Capability-based Planning help you support strategic planning and decision-making in your enterprise.

Need help? Contact us

Please schedule time with one of our experts if you want to learn more about how capabilities relate to your operating model. We have a wealth of experience in enterprise and business architecture and are happy to demonstrate the powerful features of our Bizzdesign Horizzon platform, which supports these disciplines.

About the authors:

Marc Lankhorst

Managing Consultant & Chief Technology Evangelist at Bizzdesign

Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spreads the word on the Open Group’s ArchiMate® standard for enterprise architecture modeling, of which he has been managing the development. His expertise and interests range from enterprise and IT architecture to business process management.

Bernd Ihnen

Managing Consultant at Bizzdesign

Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.

The post How to link Business Capabilities to the operating model in Business Architecture appeared first on Bizzdesign

Relating Capabilities to ‘Strategy’ and ‘Business Model’ Latest news from (my website): Bizzdesign

In our ongoing blog series on Capabilities and Capability-based Planning, we’ve mainly concentrated on the capability concept itself. We’ve discussed why capabilities are useful as a concept, how to define them, and how to structure Capability Maps. We’ve also looked at how you can use Capability Maps to support business challenges such as investment decision-making, to name a few.

In this blog, we want to cast a wider net and look at the relationships between capabilities, and share best practices for your business and strategic planning.

Relating Business Strategy and Capabilities

The relationship between business strategy and capabilities is a two-way street. On the one hand, the strategy of an enterprise is a way of configuring its capabilities and resources to achieve certain goals. This may entail improving some capabilities, developing or acquiring completely new ones, or even divesting some non-core, non-strategic capabilities.

On the other hand, your existing capabilities may lead you to pursue entirely new ventures. As several manufacturing companies learned at the start of the Covid pandemic, their existing capabilities allowed them to shift focus to the production of personal protective equipment or even more specialized products like ventilators. This is exactly what Demcon did, the company next door to BiZZdesign’s head office in Enschede: They developed, produced, tested, and delivered complete ventilation systems within the space of one month, using their pre-existing capabilities in producing related technology.

Mapping the strategic relevance of your capabilities and combining this with information on cost and investment, is a great way to support management decision making. Below, you can see an example based on views used by one of our customers. The example shows with different colors the total IT cost for each capability (dark blue = high, light blue = low), calculated as a roll-up of the operational cost of existing systems (run) and the investment in new IT (change). This cost is distributed across the capabilities according to the use the customer makes of these systems. Line width depicts the strategic importance of each capability, which is calculated as a weighted average of a capability’s relevance in terms of the company’s 5 strategic, long-term goals.

The company’s program portfolio board uses these heat maps in IT investment planning. In the figure, you can see that most of the IT investment goes towards Sales, Customer Management, and Payment, which include some highly strategic sub-capabilities such as Payment Execution. You can also see strategically important capabilities with low IT investment levels, e.g. Customer Bulling, possibly because these are not IT-intensive but maybe also because of a misallocation of budgets. Conversely, some capabilities receive substantial investment, e.g. Communication Management, without being very strategic to the company.

Does your strategic management have this insight without capability-based investment planning?

Figure 1. A capability heat map with IT investment levels (color) vs. strategic importance (label)

From Business Model to Capabilities

You may be familiar with the Business Model Canvas, which is a great way to depict the business model of an enterprise. Within this structure (see the figure below), there’s a box called “(Key) Activities”. Rather than describing operational activities here, we would use this to list the key capabilities needed for this business model. In the example below, we focus on a specific aspect of the business model of our example company, concerning a customer-centric banking application.

Figure 2. Business Model Canvas

Reusing the same capabilities in the Business Model Canvas is a great example of how you can connect different best practices for business analysis and architecture. You can even highlight in the canvas the strategic and investment analysis we have described earlier. That would show, for instance, that the strategic importance and investment level of Payment Execution match its role in this business model.

From Capabilities to Resources

For the “Asset Management” capability mentioned above, an insurance company needs personnel with the right skills, information on the financial markets. Perhaps even high-speed transactional systems, and much more. Of course, you want to define a capability in an implementation-neutral manner, but without such an implementation you don’t have that capability.

Moreover, resources often have a strategic value by themselves: for example, in a copper mining company, the copper mine will be paramount in your strategy. You won’t think about your company in terms of an abstract “Ore Extraction” capability but in terms of how you extract ore from this specific mine with all its geological and other peculiarities. At the same time, you don’t want to lose yourself in all the details of an operating model, when you’re working on your strategies. Therefore, the ArchiMate language provides the concept ‘Resource’ (defined as any asset that is owned or controlled by an individual or organization), which allows you to do strategy planning at a higher level. See also our blog on ArchiMate 3.0 – Capability Realization as an example.

Relating Capabilities and Value Streams

Where capabilities represent the enterprise “at rest”, i.e., its abilities and potential, value streams describe the enterprise “in motion” (e.g. sequences of activities to create value for customers, stakeholders, and others). These two concepts are like potential and kinetic energy in physics, they’re two sides of the same coin. To describe their relationship, cross-mapping can be done between capabilities and value streams. This shows how capabilities will support the stages in a value stream.

This can be done at a very high level, where you capture the entire value chain of the enterprise. The stages in this value chain can be cross-mapped to the top-level capabilities in the Capability Map. At a more detailed level, a value stream captures how a specific result of value is created for a specific stakeholder or group (e.g. a customer segment). The stages of such a more detailed value stream are in turn supported by capabilities from a more detailed level of your Capability Map.

One way to represent this is in the form of a Business Outcome Journey Map. This is similar to a Customer Journey Map but at a higher level. Rather than describing the specific steps that an individual customer takes (with all the possible exceptions and variants), it shows the stages in a value stream, the goals and value propositions of each stage, and the capabilities supporting it. This can link back to your investment planning or Business Model Canvas mentioned above, where you also find these value propositions, for instance. An ArchiMate Model provides great value in the backend, as it captures the concepts and relationships of both the Business Model Canvas and the Capability Map, tying everything together.

Figure 3. Business Outcome Journey Map

Where to Start?

In this blog, we’ve demonstrated best practices to analyze and get new insights on why you (should) invest in certain capabilities. We’ve also looked at how you can provide more context information with Business Model Canvas, resources and value stream views for your strategic and business planning.

In the next installment in this series, we will address how capabilities are realized by the operating model of the enterprise. Stay tuned!

The post Relating Capabilities to ‘Strategy’ and ‘Business Model’ appeared first on Bizzdesign

How to use Business Capability Maps to make investment decisions Latest news from (my website): Bizzdesign

Editor’s Note:
Capabilities are fundamental to Business Architecture, making it essential to understand how to implement them effectively. To help you navigate Capability-Based Planning, we’ve created the ultimate eBook, packed with insights, strategies, and practical guidance to set you on the right path.. This blog post is an excerpt from the eBook, providing a glimpse into the valuable content you’ll find inside.

Introduction: What is a Business Capability Map?

Today, we live in a rapidly changing world. Senior management is faced with various change initiatives to improve an enterprise’s different functions. Well-informed arguments back these change initiatives and compete for budgets. Although strategic management has access to vast information and tools to support strategic, tactical, and operational decision-making, they often lack a holistic view of budget allocation to track how investments create value for the enterprise.

Using a Business Capability Map as a framework for investment decisions and change designs has received increased traction over the last decade. With a ‘Business Capability Map,’ senior management can analyze an enterprise holistically, through a business perspective lens.

A Business Capability Map describes what the enterprise may be able to do, independent from how those things are done, by people, processes, technology, information, or physical resources. Senior management can now make more effective investment decisions while empowering enterprise and business architects to support them more efficiently.

In this blog post, we show how C-level and Business Leaders can make effective investment decisions by using Business Capability Maps. Additionally, we discuss how architects can increase the efficiency of future operating model designs and analyze business capability improvements.

Stakeholders that Benefit from a Business Capability Map

Who are the primary enterprise stakeholders benefiting from a Business Capability Map? A stakeholder is an individual or organization that has substantive impact on the business of an enterprise and can be internal (for example an employee) or external (for example a customer or a partner). Stakeholders typically utilize capability maps for decision making while architects support them in this function. Therefore, the primary stakeholders for a Business Capability Map are C-level executive management and their direct reports, and senior business leadership with titles such as Vice President or Director. They sponsor the design and use of capability maps to improve the business.

However, many other individuals working “within” this framework (for example, strategists, business analysts, managers/ owners of the processes, technology, information, and resources) may also benefit from utilizing a Business Capability Map. Designing a holistic and sound capability map usually is the responsibility of enterprise and/ or business architects. Capability maps communicate in business terms what a company is capable of, regardless of how it is currently doing it.

Purpose of a Business Capability Map

Senior management’s top priority is making better decisions while ensuring that investment budgets are allocated effectively. Digital businesses today are becoming a source of competitive advantage. The ability to quickly steer the organization towards its strategic goals and adapt faster and more effectively to changes in this competitive landscape is becoming a critical success factor for enterprise leadership. A capability map provides executives with an enterprise-wide perspective of the impact of their investments and, most importantly, indicates which capabilities will be improved.

Indicating the capabilities that will be improved is crucial when assessing competing demands for investment budgets on a “level playing field,” independent of the specific details of each demand. In other words, it provides a way of comparing “apples with apples” when evaluating the benefits of multiple initiatives regarding which capabilities are improved and how much. This enables visibility and transparency of alignment with strategic priorities, ensuring there aren’t gaps in the investment portfolio where key capabilities aren’t addressed.

A Business Capability Map also helps senior management determine whether their investments are moving in a strategic direction. This is done by assessing business capabilities for strategic relevance. For example, see the map below, which shows how Bizzdesign supports customers in making effective investment decisions by connecting business capabilities with strategic relevance. The map shows in which areas there is a gap between planned investments and the enterprise’s strategic direction.

Efficient Business Capability transformation design

While Business Capability Maps allow stakeholders to make effective decisions, the next step is to realize the change. A capability touches many aspects in an enterprise and typically includes people, processes, technology, information, and physical resources. How can senior management ensure that everyone and everything operates in the context of a business capability? Additionally, analyzing the ‘as-is’ state and designing the future operation model of a capability is often complex.

ArchiMate and other standards provide a common language that helps architects and business analysts address complexity and improve the efficiency of analysis and future design. ArchiMate provides high-level overviews for heat mapping and detailed designs of processes, applications, technology, data, and security architectures.

Feedback from customers indicates that by utilizing ArchiMate, they were able to decrease the time it takes to create and analyze future designs by 20-30%. However, it’s more than just drawing a diagram. When a common language is used, communication and collaboration between stakeholders improve when designing the future of the enterprise. The view below shows an example of a target operating model design. It highlights the changes in green.

How to track improvements in Business Capabilities

Another important benefit, apart from enabling assessment of the strategic relevance of capabilities, is that Business Capability Maps enable stakeholders to assess and track the maturity of capabilities. A map provides insights on where senior management needs to improve the capabilities of their enterprise. However, can they measure the maturity of current and future business capabilities?

The diagram below indicates how senior management can use spider charts to visualize a capability assessment. Six dimensions are defined for the “Claim management” capability, and it shows how the process dimension is broken down into more details. The baseline analysis for this capability results in values for the different dimensions linked using the red line. The required maturity, broken down into values for the individual dimensions, is indicated with a green line.

Where to Start?

If you want to learn more about how Business Capability Maps support the strategic change an enterprise requires, please contact us.

About the authors:

Nick Reed

Chief Strategy Officer at Bizzdesign

Nick is responsible for value proposition development, building strategic partnerships, and driving innovation topics, including executing Bizzdesign’s ‘buy & build’ acquisition strategy. He has over 25 years of experience in B2B enterprise software and SaaS, dedicating 15 years to enterprise architecture and portfolio management.

Bernd Ihnen

Managing Consultant at Bizzdesign

Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.

The post How to use Business Capability Maps to make investment decisions appeared first on Bizzdesign

Business Architecture redefined: Mapping BIZBOK® to ArchiMate® Latest news from (my website): Bizzdesign

What is BIZBOK?

Since the foundation of the Business Architecture Guild a little over a decade ago, its Business Architecture Body of Knowledge (BIZBOK®), as expressed in the BIZBOK® Guide, has become a popular set of guidelines and techniques for practicing business architects. More recently, it has also defined its metamodel, which you can read about in this whitepaper. This metamodel provides a core set of concepts for expressing business architecture in the sense that BIZBOK® defines it.

The ArchiMate® modeling language for enterprise architecture, first published in 2004 and established as an Open Group standard in 2009, also covers business architecture but has a wider scope. Moreover, it offers a notation as well as a metamodel, so you can write down your architecture models in a standardized way that your fellow architects understand.

Now, wouldn’t it be great if you could express BIZBOK®-based business architecture in ArchiMate? That would allow business architects to benefit from the well-established tool support for the language in expressing their business architecture artifacts. Moreover, it would let business architects easily connect these architectures to this broader and deeper scope of enterprise architecture.

The ArchiMate language was explicitly designed with such relations to other languages and metamodels in mind. It therefore provides a bridge to languages like UML and BPMN, with equivalent concepts. For instance, the ArchiMate ‘Application Component’ concept equates with the UML ‘Component’ concept.

Conversely, if we don’t link business architecture with the rest of enterprise architecture, it risks being a stand-alone discipline that cannot truly show value. Already, we see Business Architects sometimes struggle because ‘the business’ fails to understand their abstract concepts like ‘capability.’  By showing how those concepts are underpinned by more concrete elements like those mentioned above, they become much more tangible and understandable for non-architects.

Concept mapping: BIZBOK and ArchiMate

We have created the mapping in the figure below to support this integration. The background shows the BIZBOK® metamodel, overlaid with applicable ArchiMate concepts and relationships. From the ArchiMate language, we use motivation, strategy, business, implementation, and migration elements.

The mapping between two conceptual universes is seldom 1:1. Some of the BIZBOK® concepts could be expressed with different ArchiMate elements. For example, the ‘Stakeholder’ concept in BIZBOK® can be used to express someone with an interest or concern, just like in ArchiMate. Still, it can also have an operational role, e.g., triggering a value stream. In ArchiMate, you can better express such operational roles using the ‘Business Role’ concept. Although there are a few different mapping options, the mapping above works well in practice and is a good starting point for your business architecture modeling efforts.

Hierarchical levels in concept mapping

In this mapping, you may notice that ArchiMate uses a single concept at different hierarchy levels. For instance, the BIZBOK® ‘Organization’ and ‘Business Unit’ concepts are both expressed with an ArchiMate ‘Business Actor’ in the second mapping, one composed of the other. As you can imagine, an organization structure may have, e.g., Departments with Business Units, Teams within Departments, etc.

The same pattern is shown by BIZBOK’s ‘Value Proposition’ and ‘Value Item’, both mapped to ArchiMate’s ‘Value’ concept, and by ‘Value Stream’ and ‘Value Stream Stage’, both expressed as ‘Value Stream’ in ArchiMate. Moreover, unlike the more strictly defined BIZBOK® concept, you can even use an ArchiMate ‘Value Stream’ to model an entire value chain, thus linking your business architecture to your business model in the economic sense.

Such hierarchical levels occur in many other areas too, e.g. business process decomposition or application structure. For this reason, ArchiMate does not have any built-in, fixed hierarchies. Rather, it allows arbitrary composition and aggregation levels between elements of the same type. That flexibility provides you with yet another way to drill down from high-level, strategic views of the enterprise into progressively more detailed operational models. However, if you want to map the BIZBOK® concepts more closely to ArchiMate, you can use the language customization mechanisms outlined in Chap. 15 of the ArchiMate specification to create custom specializations for these different hierarchical levels. These could even have a custom notation.

From Business Architecture to operating model

From the concepts in this mapping, you can drill down into your enterprise’s operating model. More concrete concepts for that operational level can be linked with a Realization relationship to their more abstract counterparts in a business architecture model. For instance, ArchiMate Business Processes can realize a Value Stream stage, and Business Functions can realize a Capability. From this operating model, we can drill down deeper towards the implementation, for instance, to express that a Business Process is automated, modeling its realization by an Application Process performed by some Application Component.

That way, you can drill down from high-level business drivers and motivation via your business architecture into the underlying operating model as expressed in elements like business services and processes, applications, IT infrastructure, and physical technology. Such a line of sight provides essential business insights, helping you set investment priorities, analyze operational risks, assess regulatory compliance, foster innovation, and much more.

As you can see from the above, the ArchiMate language is an excellent way to express your BIZBOK® business architectures and relate them to other architecture and design domains. See also our eBook on Capability-based Planning for this. Of course, excellent tool support for modeling, analysis, and collaboration is vital. That way, business architecture truly becomes an actionable discipline!

About the authors:

Bernd Ihnen

Managing Consultant at Bizzdesign

Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.

Marc Lankhorst

Managing Consultant & Chief Technology Evangelist at Bizzdesign

Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spreads the word on the Open Group’s ArchiMate® standard for enterprise architecture modeling, of which he has been managing the development. His expertise and interests range from enterprise and IT architecture to business process management.

The post Business Architecture redefined: Mapping BIZBOK® to ArchiMate® appeared first on Bizzdesign