It’s like building the foundation for your home. When planning your enterprise architecture, a clear blueprint mapping the basic infrastructure of an organization can mean the difference between a chaotic mess or a beautiful support system.
Business capability maps provide a clear vision for future state of an organization’s applications, processes and business objects. But creating this map and understanding the impact of each capability is a daunting task, especially if your application landscape has not been well maintained over time.
During EA Connect Day in New York City this Spring, we welcomed one of EA’s biggest influencers, Mike Rosen, founder of the Business Architecture Guild. During his presentation, he explored strategic business capability mapping. He weighed in on the challenges of mapping, sharing best practices for today’s EAs when aligning strategic objectives and tactics in the enterprise. Check out his full talk, Best Practices for Business Capabilities Maps and continue below for a quick summary.
Best Practices for Business Capabilities Mapping
When defining capabilities, a critical factor in building a map is defining what the business does. Traditionally, the concept of a capability was established to solve for how a business achieved an outcome. Business capabilities have evolved and the traditional theory of business capability modeling needs to be overhauled. Today, capabilities must be clearly and concisely defined -- describing self-contained business objectives, not procedures.
This is often the biggest challenge for EA’s when modeling. This level of clarity takes time and careful consideration to develop. However, it’s is one of most critical steps in the process. In capability mapping, what’s important is understanding the relationship and value of each capability, and how impactful they are on the organization. Once you can clearly identify what each capability does, pinpointing redundancies, gaps, and overlaps in the business.
For example - use nouns to define a capability and verbs to describe it. Here’s a simple formula to follow:
- Formula: “Customer Management” is a good name versus “manage customer”, a bad name because it describes a process. The ability to do (verb, verb, verb…(child capabilities)) on / with (business object, concept, entity information… (with clarification)) in order to goal, goal…
- Example: “Customer Management”: The ability to control, predict, process, organize, present and analyze all information, documents, preferences, experiences and history related to an individual or organization that has, plans to have, or has had an agreement in place with the company
Once capabilities have been defined, breaking down and prioritizing helps refine the overall understanding of what the business does and the value of each capability against business goals and the IT portfolio. When structuring a capability map, segregate and order each capability based on a hierarchy -- reserving level 1 capabilities for strategic and disectable objects or concepts. Then, drop down to level 2 capabilities -- those of which cannot exist without the level 1 capability and serve as the next level of detail in an initiative. Finally, level 3 capabilities and those after are for the instances that support the projects.
Ultimately, the goal of slicing and categorizing each capability in a model is to show the relationship between each initiative and application. Rosen’s key takeaway for EA’s: “Creating an architecture delivers zero value. You only get value from architecture when you use it to influence decisions.”
Business capability maps help leaders visualize the roadmap, understand what capabilities require what information, and see how one little change can impact everything else. The combination of the capability and its relationships to others make capabilities valuable.