IF4IT Home

The International Foundation for Information Technology

IF4IT is International
Glossary Quick Links
Glossary Master Index
Discipline Quick Links
Disciplines Master Index

The IF4IT Enterprise Capability Modeling Framework

Capability Summary


The Enterprise Capability Modeling framework is a loosely defined methodology that exists to help IT professionals and/or their stakeholders define, develop, deliver, and understand, both, Enterprise Capabilities and Enterprise Capability Models (ECMs). Such tools are used to help clearly identify, set strategy for, deliver, and support Enterprise Capabilities, as they pertain to the greater enterprise (i.e. the Enterprise Portfolio). This document will also help introduce the reader to the IF4IT Enterprise Capability Model (IF4IT ECM), which can be used as a reusable foundation for most Enterprise Capability Models, regardless of industry.

Table of Contents

Some Basics About Capabilities and Capability Modeling
Uses and Benefits of an Enterprise Capability Model
Capabilities vs. Features vs. Disciplines
What is Capability Modeling?
Example Model: The IF4IT Enterprise Capability Model
Capability Composition: The Components or Pieces That Make Up a Capability
The IF4IT "Noun-Verb" Modeling Methodology
The IF4IT Linear Taxonomy of Enterprise Capabilities
Organizations That Typically Create, Maintain, and Use Enterprise Capability Models
Enterprise Capability Model Governance
The Politics of Enterprise Capability Management
Enterprise Capability Model Taxonomies and Structures
Enterprise Capability Model Representations and Visualizations
Enterprise Capability Model Metrics
Enterprise Capability Model Strategy Development
Supporting Business Capabilities via Business Architecture
Important Summaries and Conclusions
Learn More


Capability Summary

This document is intended to introduce the reader to two key concepts...

  1. Some best practices, tactics, and strategies associated with modeling Capabilities as they relate to the broader enterprise, which is commonly referred to by IT professionals as an Enterprise Capability Modeling Framework, and
  2. The IF4IT Enterprise Capability Model (ECM), which is an example of an actual Enterprise Capability Model that can be leveraged by the reader to, both, learn more about IT as well as help model his or her own enterprise, regardless of the industry the enterprise competes and operates in.

In other words, the modeling framework is intended to act as a loosely structured means or methodology to help readers get to Enterprise Capabilities, and the IF4IT ECM, which is a result of such a modeling framework, is a functioning and usable model that is intended to act more as a Knowledge Management tool, where the resulting tool helps IT Professionals and their relevant Stakeholders learn about, understand, and communicate key things about a typical "Enterprise."

Some Basics About Capabilities and Capability Modeling

The use of modeling frameworks and their resulting models help IT professionals and enterprises capture, socialize, teach, and understand information like:

Once we know these things about an enterprise, we can get to answers for more advanced and complicated issues, such as but not limited to:

You may ask yourself why it is that this document addresses, both, the modeling framework and the model, together. The reason for covering the modeling framework, in addition to the model itself, is because the modeling framework provides a better understanding of how and why the actual model is structured is structured and represented the way it is, which in turn helps lead to a better understanding of how best to apply the model in order to help get to better representations and, ultimately, better solutions for your own enterprise.

Before reading on, the Foundation recommends that you try to familiarize yourself with:

  1. the definition of a Capability, on which we will elaborate further, below,
  2. the IF4IT Discipline known as Capability Management, which helps readers understand what it means to create, maintain, and socialize Capabilities, and
  3. the Capability Management Glossary, which helps familiarize you with common Capability language.

To provide a bit more color than the glossary entry, a Capability can be described in the following manner. A Capability is:

Defining a Capability

It is important to understand that the Enterprise Capability Model (ECM) provided by the Foundation focuses more on "the What" (i.e. the Enterprise Capabilities and the linkage and representation between them) than any of the other questions that need to be answered to complete the entire model, simply because we're trying to provide the reader with a framework for organizing, collecting, and representing all the other information as it pertains to your own enterprise. Clearly, you and those with whom you work can only provide the details of your own enterprise. However, this being said, the ECM is extremely powerful, even without a specific enterprise's data, because it acts as a template that applies to most enterprises, making it a powerful baseline for getting started and rapidly getting to "the What" an enterprise does.

As mentioned, Enterprise Capability Models represent the functional structure of an enterprise and are not meant to represent organizational structure. While it is far more common to create organizational structures, the benefit of organizing an enterprise according to functional structure is that functional structure is more stable and rarely changes, while organizational structure changes frequently (e.g. constantly disappearing, restructuring, renaming and constantly causing confusion and instability). For anyone who has ever tried it, creating and maintaining stable models that are generated from organizational structure rather than functional structure, especially in large commercial enterprises, is like herding cats. This is where the power of a Capability Model comes in. Capability Models are organized based on functional structure and, therefore, will stay far more stable than models built based on enterprise organizations. This is because, while organizations may come and go, the functions an enterprise performs will rarely disappear and/or change as rapidly. Think about it... Your sales organization may be highly federated, across many different areas of your enterprise, with different organizational structure and leadership, and may be changing constantly in any one area with no regards to consistency with other areas of your enterprise. Believe it or not, this happens often. The simplest example is larger enterprises that exercise acquisitions of other enterprises, regularly, and who are therefore composed of a chaotic mess of legacy organizational structures under the one master enterprise, which presents the perception of a stable and unified brand to the outside world while they try and restructure and optimize, internally. Guess what, the smarter enterprises with the more experienced people who have been through such reorganizations, over and over again, are probably using or know they need to use a functional model, like an Enterprise Capability Model, to help them restructure all those messy organizations, efficiently and effectively.

Disclosure: While a Capability Model, enterprise wide or otherwise, can be a powerful tool, it is imperative to keep in mind that no model is ever perfect and no representation of the information conveyed by a model will be thorough enough to meet the needs of everyone who may be interested in using the model. The IF4IT Enterprise Capability Model (ECM) is no exception to this. However, we do believe our model is very different because, unlike many other models that try and fail, the Foundation has found a way to clearly represent Business Capabilities, Information Technology (IT) Capabilities, and Shared Capabilities, together, in a single and unified model. This is a common challenge that many modelers deal with, regularly.

The IF4IT does its best to convey as much relevant information as possible in it's model and understands and acknowledges that it's model is a constant work in progress, as will be the case with any model that the reader will be involved in creating and maintaining. It is for this reason that the Foundation reminds you that, while you are welcome to leverage our model(s) to your own needs, subject to the terms and conditions of the Foundation, if you do not like what the Foundation offers, you can always choose to spend the time, money, and energy to create and maintain your own model(s). However, this being said, the Foundation believes that it\’s almost always simpler and more effective to leverage what exists than it is to reinvent the wheel and start from scratch. The existence of our model will, hopefully and at a minimum, give you a baseline to start with. To make it more customizable and extensible, the model even provides placeholders for where you can add your own Enterprise Capabilities, should you choose to do so.

NOTE: As is the case with most content published by the Foundation, the material within this document will continue to evolve, over time. Therefore, the IF4IT recommends you check back regularly, to keep up with any changes.

Uses and Benefits of an Enterprise Capability Model

In short, Capability Models tell us "What is being done or needs to be done" (i.e. the functions that are being performed or need to be performed) so that we may address things like "Why we need to do them," "How we will do them," "Who will do them," "When they will be done," and "Where they will be done." Achieving all of the above, in a thorough and an effective manner, is not an easy task for a single Capability, let alone for all Capabilities that make up the entire enterprise. However, there is great value in doing so, both at microscopic (individual Capabilities) and macroscopic (across the enterprise) levels.

Before giving you a longer and more specific list of the many benefits gained by creating and maintaining an Enterprise Capability Model (ECM), it's probably best to first discuss the most important reason of all for doing so. Throughout the world, in almost every enterprise, and in every industry, there are IT leaders who have a very difficult time describing the business and value of IT and their IT organizations and to the Businesses they serve. They can't clearly explain how much work IT performs, how complex IT really is, why certain solutions take so long to deliver, and why it is that IT costs so much. A good ECM helps correct this problem, as it clearly breaks out and represents almost all key functional areas of the enterprise that IT is involved in and provides solutions for, both directly (in Sales, Marketing, Manufacturing, etc.) and indirectly (e.g. Applications, Systems, Software Infrastructure, and Hardware Infrastructure). The end result is that their Business Sponsors, Consumers, and Counterparts don't appreciate IT and the vast expanse of solutions IT needs to be involved in and deliver solutions for.

Arguably, there is absolutely no single artifact or tool that is stronger and more effective for proving the size, complexity, value, and cost of, both, the enterprise IT organization than the constant plastering of your walls with huge plotter outputs that document the functional representation of the whole enterprise so that everyone can see everything your IT organization is involved in. (If you disagree and have a real example that you believe proves otherwise, please always feel free to contact us at our support email address with your example(s). We'd love to hear about it/them.) Many IT leaders, especially C-Level executives like Chief Information Officers (CIOs), Chief Technology Officers (CTOs), Chief Strategists, Chief Operating Officers (COOs), and Chief Architects are constantly struggling to find and establish such tools to make their lives easier. And, once such leaders are exposed to a thorough Enterprise Capability Model and understand how it helps, they almost always and instantly realize its power and latch onto it.

In addition to helping with painting the picture of how big, complex, costly, and valuable IT is, a solid ECM also helps solve problems and provide benefits in the following ways...

So, you can see from the above that a good Enterprise Capability Model (ECM), when implemented correctly, can be an extremely powerful Knowledge Management tool that facilitates in the solving of many big picture problems faced by enterprises, regularly.

Capabilities vs. Features vs. Disciplines

Capabilities vs. Features vs. Disciplines

When modeling, there will inevitably be conflict about how to name Capabilities. There will always be people who burn tremendous energy trying to name things, some way or another. The IF4IT chooses to use the Discipline name, in the form of "BASE_NAME" Management as a means of:

  1. shortening longer phrases that describe Capabilities,
  2. grouping multiple Capabilities, together, and
  3. creating and promoting naming consistency, throughout the Enterprise Capability Model (or any Capability Model, for that matter).

For example, you will see names like Sales Management, Product Management, Release Management, Stakeholder Management, Incident Management, etc.

When modelers get caught up in naming and representation battles, they invariably lose productivity and run the risk of delayed deliverables. To avoid this, the Foundation recommends agreeing upon and using a consistent naming methodology, before starting your model. As mentioned, the IF4IT specifically uses its own Discipline naming form as a mechanism for naming most Capabilities in our own model. However, sometimes there may be exceptions if it makes sense to do so. Introducing naming consistency provides a means of grouping features within or about a specific Capability or Capability Area into one name. Therefore, saying or using the phrase Sales Management really means anything and everything to do with Sales. Another way of looking at it is that, in the context of Enterprise Capability Modeling, using the Discipline name Sales Management really represents nothing more than the short form of the longer and more cumbersome phrase All Sales Management Related Capabilities. A big benefit of doing so is that the modeler can now avoid having to itemize the many detailed sub-Capabilities or Features that so many people will waste tremendous time arguing over. This doesn't mean that the details shouldn't be itemized at some point. It just means they can be put off for later stages of improving the model's maturity.

NOTE: If getting to the details (i.e. very granular Capabilities) is important to you and your enterprise, then by all means do so and feel free to go down the road of breaking things down to whatever level of granularity makes sense to you and your enterprise. However, you will invariably find that doing so will ensure you miss things and leave important Capabilities out of you model. It happens to the best modelers; as humans always have a tendency to miss things or make mistakes, so don't feel bad if and when it happens to you, too.

NOTE: To assist with consistent representation and naming for very granular sub-Capabilities, the Foundation recommends you familiarize yourself with the material in Capability Management that specifically addresses naming of detailed Capabilities and deriving actionable Roles from your names.

So, given that we now understand the difference between Disciplines and Capabilities, how do Capabilities compare to Features? In short, Capabilities are nothing more than functional features. And, when used in Enterprise Capability Modeling, such functional features represent Enterprise Functions. For example, the ability to process a Sales Order is a function of the enterprise and, therefore, an Enterprise Capability.

To provide some history, Capabilities are a concept that originated in and are rooted in the language of Marketing and Sales people. For generations, Marketing and Sales people used Capabilities to describe key features that help buyers understand the things being sold to sell them. What many people don't understand is that good Marketing and Sales people know how to positively educate their intended targeted audience(s) on their products and services, ultimately doing it well enough to make the buyers want to buy. Doing so is a powerful form of Knowledge Management, where the language used by Marketing and Sales staff exists to efficiently educate and persuade buyers.

Effective IT professionals are smart enough to learn from what works and, hence, the practice of using Capabilities to describe the enterprise was born and fashioned on the habits of effective Sales and Marketing people. Ever since, Enterprise Models have been used as Knowledge Management tools that help professionals teach others about enterprises, such as how they're structured, how they function, where to find things/answers, what's impacted, and much more.

To elaborate, there are Capabilities or Features of a Product, Service, Application or System as well as Capabilities or Features of an Enterprise (i.e. the functional features of an enterprise). The Enterprise Capability Model (or ECM) is a representation of the Capabilities or Features of an Enterprise.

An example of an Enterprise Capability is the ability to or capability of being able to process Sales Orders. Such a Capability is really nothing more than a feature or ability of the enterprise that allows it or requires it to process Sales Orders (whatever that means to you). The ECM places such a Capability in one or more specific locations of the model, providing readers of the model with context by such placement. Therefore, placing the Capability of processing Sales Orders under the general Capability are of Sales Management tells the readers of the model that Sales Order Management is a sub-Capability of Sales Management. For example:

Sales Management is composed of the sub-Capabilities:

As you can see from the above example, Sales Order Management intuitively belongs to Sales Management. Keep in mind that organizing your own ECM may not be so clear, as you'll find that many Enterprise Capabilities need to show up in multiple areas of your model. This is a concept that will often confuse many who have never built multi-dimensional models before and who adamantly believe that model data should be structured in tree form.

To summarize:

What is Capability Modeling

Capability Modeling is a set of activities, tasks, or work that is performed as part of the greater Discipline known as Capability Model Management, which is also a sub-Capability or sub-Discipline of Capability Management. These activities, tasks, or work are performed as a means of identifying, labeling, describing, organizing, and analyzing Capabilities. The parent Discipline Capability Management usually falls under the higher and cross-functional enterprise Discipline or Capability known as Design Management. For example, such a structure would look like:

Capability Management As Part Of Design Management

The Discipline of Capability Model Management represents all functions and features associated with creating, maintaining, socializing, supporting and using a Capability Model. In the case of an Enterprise Capability Model (or an ECM), such a Discipline and its activities are applied, specifically, to create, maintain, socialize, and use a model that represents a functional structuring of the entire enterprise. By enterprise we mean any enterprise, such as but not limited to: private companies, government agencies, non-profit and not-for-profit organizations, educational institutions, and any other enterprise that provides, uses, or supports common Business and/or IT functions.

The output or deliverable that comes from the activities, tasks or work associated with Capability Modeling is called a Capability Model. Such models have a great deal of value for different stakeholders, throughout an enterprise. Such value and benefits are discussed throughout this document.

Example Model: The IF4IT Enterprise Capability Model

A high level example of an output that was generated using this Framework as a baseline includes the IF4IT Enterprise Capability Model (IF4IT ECM).

Enterprise Capability Model Summary

Capability Composition: The Components or Pieces That Make Up a Capability

It's important to understand that a Capability is composed of many things or related items that help describe and define it. The following list represents an example of some of the many possible things that help successfully make up and define a Capability...

The technical name for the above structure is what Capability Modelers call a Capability Structure Taxonomy or a Capability Knowledge Structure (not to be confused with a Capability Type Taxonomy that represents a structuring of many different types of Capabilities). While the above Capability Structure Taxonomy is not intended to be a complete or rigid representation, you can see for yourself that there is a significant amount of work associated with defining, creating, delivering, maintaining, socializing, and supporting just one Capability, let alone hundreds. The problem of the enterprise, as a whole, is to understand and manage a very large set of Capabilities that represent the entire Portfolio of Capabilities (i.e. the Enterprise Portfolio) that are supported by having an Enterprise Capability Model.

Visually (or graphically) such a Capability Structure Taxonomy may look like the following figure...

Capability Structure Taxonomy

It is important to note that how the above information is represented, regardless of tool or format/view, is inconsequential, so long as the information is captured and represented in a manner that makes sense for your enterprise and the stakeholders who use the information. In fact, there will be multiple formats/views and tools that you will probably need to be successful at distributing the model to different targeted audiences.

Also note that there is no one standard, definitive, or de facto way to correctly represent a Capability. The IF4IT provides some basic ideas and examples but, in the end, it's important for you to understand what works best for your enterprise. This being said, starting from scratch is rarely a good idea. It is for this reason that the Foundation provides you with material that you can leverage for your baseline. The goal is to work towards the most complete view that you can to support the needs of your own enterprise stakeholders.

The IF4IT "Noun-Verb" Modeling Methodology

The IF4IT "Noun-Verb" Modeling Methodology is a set of very simple steps and best practices, established by the IF4IT, that help IT Professionals and, specifically, Capability Modelers to rapidly identify and structure Enterprise Capabilities. The methodology consists of four very straightforward steps...

  1. Identify the Nouns, Entities, or Things that are important to you and your enterprise (e.g. Noun = "Change").
  2. Turn those Nouns, Entities, or Things into a Discipline or Capability Category (e.g. the identified "Change" Noun yields Discipline = "Change Management" or Capability Category = "Change Management Capabilities").
  3. Identify the Verbs that need to be applied to those Nouns (e.g. "Create Change" and "Edit Change". Note: This is shorthand for far more verbose Capability descriptions, such as "the ability to create a Change" or "the ability to edit a Change."
  4. Use the Verbs to generate very simple key Roles that describe the Actors who perform such functions on the Nouns (e.g. "Create Change" -> "Change Creator", "Edit Change" -> "Change Editor", etc.).
IF4IT Noun-Verb Methodology

Following these very simple steps allows modelers to simply and rapidly identify what is important to our model, independent of structure or bias. Once these patterns are established, we have a very comprehensive list of our Capability Categories, the detailed Capabilities that can be performed within such Categories, and the Actors or Roles within that Capability Category that perform such Capabilities. NOTE: The Foundation has already gone down the path of identifying many of the Capabilities your enterprise will care about. We call them "Disciplines" and recommend you leverage what you can, when building your own model.

Another positive outcome of this methodology is that it also allows modelers to create a repeatable pattern that consistently allows scaling from just about any Noun of little importance to almost any Noun of significant importance.

We acknowledge that there will always be exceptions to such a methodology or framework. However, exceptions should be just what they're intended to be and should, therefore, be used sparingly

NOTE: The "Noun-Verb" Modeling Methodology is a copyright of the International Foundation for Information Technology (IF4IT) and should be appropriately referenced, when used or communicated.

The IF4IT Linear Taxonomy of Enterprise Capabilities

The model discussed, herein, is intended to address many but not all of the Disciplines or Capabilities that appear at the highest levels of an enterprise. As mentioned earlier in this document, while the IF4IT ECM helps people understand the general structure and Capabilities of most enterprises, is not intended to be a completely encompassing representation of all enterprises and, therefore, does not show and represent all Disciplines or Capabilities. This is especially true of far more detailed or granular Disciplines or Capabilities that would be buried further down in the model. However, having said this, the Foundation is constantly working to improve its inventory of Capabilities and the details about each. For a more complete inventory of Disciplines or Capabilities, we recommend you refer to the following:

  1. The IF4IT Taxonomy of Enterprise Capabilities
  2. The IF4IT Master Inventory of Disciplines

Both of the above examples lead to the same information, through different structures and representations. Feel free to use these tools to help build or customize your own model, so long as you comply with the IF4IT Terms and Agreements of use, which, in short, does not allow you to profit from our material.

Organizations That Typically Create, Maintain, and Use Enterprise Capability Models

While Capability Models originated in IT design and architecture organizations, and are while most models are leveraged by these same organizations, some more advanced Strategy, Human Resources (HR), Organizational Development (OD), and Program Management Offices (PMOs) have been known to attempt to create and leverage their own versions of Capability Models to improve how they operate. How effective their attempts at doing so have been is subject to interpretation, as many of these organizations have very little formal design skills. However, there is no doubt that such organizations did feel that creating and using such models was a useful effort to pursue and maintain. This shows, at least, some insight into the value of such models, even outside Information Technology (IT) Organizations.

Typical creators and owners of Enterprise Capability Models (ECMs) include organizations such as:

In addition to all of the above organizations that use what they create, other consumers and users of Enterprise Capability Models (ECMs) include organizations such as:

Enterprise Capability Model Governance

There are two forms of governance that you'll have to worry about as you create and maintain your model. The first form of governance has to do with the work you will do to create and govern the very first version of your model. The second form of governance has to do with governing changes and evolution to subsequent versions of your model.

Taking the time to implement proper governance while creating the first version of your model is very important because it can make or break whether or not you will even have an opportunity to work on a second and/or subsequent versions. The Foundation recommends...

Something to keep in mind is that the more people you have involved in the creation and maintenance of your model, the longer it will take to generate and publish a model that everyone is happy with. The saying, "Too many cooks in the kitchen spoil the meal," is very valid when it comes to building your model, especially that critical first version. The more people you have involved in generating your model, the more frustration you will experience, as almost everyone involved (all most likely with very little modeling experience) will adamantly and aggressively push to name things and represent things their own ways. It is for this reason that you may want to do your best to create a somewhat comprehensive model with as few people involved as possible, before you go out and socialize the model for improvements and changes.

Once you have an acceptable version 1.0 you will need to keep working on your model to improve areas that have not been fleshed out and apply changes that help improve its quality. Doing so will be an iterative process that, as is the case with any product, will require a great deal of interaction with the consumers of the model. This implies keeping track of, managing, and implementing Requirements, Issues, and Change Requests that come from the model's consumers. And, as is the case with any product, not all consumers will be happy with your decisions on how you implement (and in many cases don't implement) some of their requests.

Caution: Keeping in mind the old saying that "Knowledge is Power", it's very important to note that once the model is thorough enough, it becomes a very powerful knowledge tool. And, as is the case with any powerful knowledge tool in an enterprise, it becomes a political lightening rod for power, as many people who vie for enterprise power will want to influence it, and even own it. This is probably one of the strongest arguments for socializing version 1.0 "after" it's complete. By doing so, you will at least have an asset in hand and the experience of what you’ve put into it, which gives you a leg up on internal competition. Also, it's during its initial creation that your model will be in its most vulnerable state for ownership takeover by other people and organizations.

All of this being said, it's very important to get your model socialized, accepted, and used, by as many people throughout your enterprise as possible. The more support and use you get, the more powerful the model will become as a tool for solving enterprise problems.

At a minimum, it is highly recommended to version control releases of your ECM so that you and your organization can track changes and progress between versions, as well as restore older pieces of your model, should you need to do so.

The Politics of Enterprise Capability Management

As you work on your ECM, you'll start to find that more and more people want to influence the model and, ultimately, own it (or at least what's in it). The reason for this is simple... Knowledge is power and your ECM represents a form of power to many people. This being said, there will be very few enterprise artifacts or solutions that will have as much power or draw as much attention as your ECM, that is assuming you create and operationalize it effectively. One of the few exceptions will be your Enterprise Intranet. However, if you build your ECM correctly, one of the ways you should be attempting to operationalize it is through your Intranet, which is where conflict is sure to show itself.

When it comes to building your model, you should understand that organizational structure and enterprise language are the very representation of power and religion to many professionals you work with. The power to own and influence are at the heart of most enterprise power struggles and, as your model becomes mature and well socialized, be prepared for people you work with to want to aggressively influence and/or own it. As your peers argue to get their key organizations represented in the ECM, keep in mind and remind them that organizational structure has nothing to do with effective Capability Modeling and that good Capability Modeling has everything to do with functional structure. If, per chance, you start to see synergies between organizations and functions, this is a good thing because efficient enterprises work hard to structure themselves around Enterprise Functions or Enterprise Services. As mentioned earlier, organizing your own enterprise around Enterprise Functions or Capabilities will also be something that you'll want to use your mature ECM to help facilitate and optimize.

As you build your ECM, you'll run into people who have done very little or no Capability Modeling but who think they are very knowledgeable in doing so and who want, very badly, to be a direct influence on the model. (When in doubt, always feel free to ask them for their modeling credentials and references for their past work.) It's recommended that you use existing models as baselines or examples to keep such people in check, so they don't overtake your efforts to be productive. Remember the old adage... Too many cooks spoil the meal applies here. It's recommended that you try and use the smallest number of competent and experienced resources to build and publish iterations of your model, especially the first iteration, rapidly.

In addition to ownership and influence as drivers for conflict, many conflicts will also arise as people try to avoid transparency, usually because they don't want the disruption or questions that comes with attention to their areas and what they do. Your ECM, implemented correctly, will help improve and drive transparency throughout the enterprise and many people won't like or welcome it.

Another thing to keep in mind is model structure. Too many people only understand strict tree structures (i.e. all children can only have one parent). However, experienced modelers know that such strict models never hold, over the long run. Complex models become more like graph structures than they do trees. For those that have little modeling experience, it will become difficult for them to grasp why your model may start as a tree but may ultimately turn into a graph, as you get deeper into your structures. Be patient and stay on the course. Do the right things for the right reasons and it will pay off in, both, the short and long terms.

Enterprise Capability Model Taxonomies and Structures

Identifying and organizing Enterprise Capabilities (or any Capability, for that matter) allows the creator of the Capability Model to organize more than just Capabilities in Parent/Child relationship chains. It also allows you to create consistent Taxonomies for organizing Enterprise Knowledge. This means that, in addition to knowing a Capability's child/sub-Capabilities or parent Capabilities, we can also use a Capability to lead us to other important things about that specific Capability. Examples of such things include but are not limited to:

This leading is what makes the ECM a knowledge tool, leading us from a Capability to other important things associated with that Capability.

For example, we could use the Taxonomical Structure, shown in the following figure, to represent the Enterprise Capability we commonly refer to as Sales Management:

Example Structure of Sales Capabilities

After analyzing and understanding the above pattern, the point should be clear... Capability Taxonomies can be used as very valuable and powerful Knowledge organization and discovery tools. When used properly, they can help enterprise resources, such as Employees and Consultants quickly and simply find what they need, when they need it, without any real assistance from anyone else.

Now, think of tying such a structure to your enterprise Intranet or your Service Catalog to control traversal! These are topics that we'll discuss, further, as we get into the different ways that you can operationalize your ECM in order to realize its true potential.

Enterprise Capability Model Representations and Visualizations

There are, fundamentally, two broader visual formats for Capability representation that are used by Capability Modelers, when trying to convey key Capability data and information to users or consumers of the model. These two formats are:

  1. Text Only Formats
  2. Graphical Visualization Formats

Text Only Formats usually come in one of two representations, which are:

An example of the Denormalized Linear Form would look something like:

An example of the Denormalized Path Form (or Hierarchical Path Form) would look something like:

An example of the Normalized Linear Form would look something like:

Note that both examples, above, represent Parent/Child Relationships differently and that they both do so using text only and no pictures. In both examples, Capability C is a child of Capability B, and Capability B is a child of Capability A, where Capability A represents the root Capability. While the former example explicitly identifies parent Capabilities for each child Capability, the latter example implies Parent/Child Relationships through indentation and depth identification. Neither is more right or more wrong than the other. Different representations may be needed for different circumstances or contexts.

Another set of representations that will be very useful to modelers are those that fall into the category of Graphical Visualization Formats. Graphical Visualization Formats can come in many forms. Examples include but are not limited to:

Again, no one visualization is or will ever be perfect and, depending on your own circumstances and contexts, you may need different representations to properly meet the needs of your Stakeholders. The Foundation recommends always starting simple, such as with a Denormalized Text Form in a spreadsheet, and going from there as your model matures and the needs of your enterprise become more complex and elaborate.

Enterprise Capability Model Metrics

What metrics an enterprise views as important, for measuring different aspects of a Capability, is often subjective to that enterprise. However, the categories for such metrics are usually pretty common and objective. Given this point, some of the metrics categories for measuring Capabilities include but are not limited to:

Given such metrics, enterprises usually compare the results, as applied to their own Capabilities, to the results for one or more of the following:

Enterprise Capability Model Strategy Development

Done correctly, every Enterprise Capability will, at some point or another, require a strategy that identifies how things will need to change for that Capability, over time. A Capability Strategy is an artifact or set of artifacts that depicts what needs to change and how such changes will be implemented in order to achieve greater Capability Maturity, over a planned period of time. In short, such strategies decompose and contrast Current State solutions for existing Capabilities (or lack there of) against Future State Capability needs and the solutions that are required to help improve and deliver such Capabilities.

A complete Capability Strategy answers the questions What, Why, Who, When, Where, and How for, both, the Current State and the Future State.

  1. The What: Details what functions need to be performed and what requirements need to be satisfied.
  2. The Why: Details why things are done or need to be done in a specific manner. This helps clarify justification for such Capabilities.
  3. The Who: Details who is and who will be accountable for performing such functions; Who will deliver them; Who will support and perform them; Etc.
  4. The When: Details when functions are performed, will need to be performed, and when solutions need to be delivered.
  5. The Where: Details where functions are performed and where they will need to be performed, in the future. The where can be as coarse as a regional area of the world or as granular as where to locate a specific feature in a specific Application or System.
  6. The How: Details how things are done and will need to be done, for example: Processes, Procedures, Tools, Technologies, Products, Services, Data, how things are governed, and much, much more.

The following is a depiction of the IF4IT Capability Strategy Framework, which summarizes how to methodically achieve such strategies...

IF4IT Capability Strategy Framework

In order to develop a strategy that shows multiple iterations of evolution and improvement, over time, the right column of the above framework would be repeated, outward and to the right. This would be repeated, as necessary, for the delivery of every new iterative version or set of changes. Such an iterative version is commonly associated with or referred to as a Capability Release and often represents an intended (future) or delivered (past) level of maturity, along with all things necessary to support that level of maturity.

IF4IT Capability Release Strategy

Developing a complete Enterprise Capability Strategy (also referred to as an Enterprise Strategy) involves performing the above, for each and every Enterprise Capability. Such strategies usually span multiple years for many enterprises. The following figure shows a simplistic representation of how such information might look...

IF4IT Enterprise Capability Strategy Framework

The above figure is also a very high level representation of what is commonly considered to be an Enterprise Capability Roadmap.

A good Enterprise Strategy is very detailed, very complicated to create and maintain, and should never be underestimated. Such strategies represent the foundation for how good IT leaders (such as CIOs, CTOs and Chief Architects) manage the business of IT and maintain alignment between their IT organizations and the businesses such organizations support and deliver solutions for.

Supporting Business Capabilities via Business Architecture

Often, enterprises will set up Business Architecture roles to help facilitate the collection and organization of Business Capabilities. These Business Architects often work with Business Stakeholders to identify and map out Capabilities that tie, directly, to things like Business Strategies, Mandates, and/or Initiatives.

Often, Business Architects will talk about things like Business Architecture Blueprints, which represent a set of views that are used to support Business Capabilities. These views include but are not limited to things like:

Important Summaries and Conclusions

The following represents what the Foundation believes to be a minimum set of summaries and conclusions that an IT Professional should take away, after reading about Enterprise Capability Modeling and the IF4IT Enterprise Capability Model...

Capability Summary

Learn More

IT Learning Framework
Discipline: Capability Management

Copyright 2009 - Present by The International Foundation for Information Technology (IF4IT) : Privacy Policy and Terms of Use