In my previous posting on Business Capability Modeling, I synthesized some of the leading perspectives from the analyst community. Since that posting we have also released a podcast with Frank Malta from Merck on their approach to business capability modeling.
I’ve also heard from our community by email and have seen several interesting threads in the blogosphere that I want to share today:
A note from Jan Nilsson Manager EA, RGDS
Business Capabilities is the only way to get the business and IT to understand each other, focusing on the WHAT and don't bother about HOW. The HOW will always differ. I'm responsible for EA in a multinational company, so the HOW will always differ over our entire global organization represented in some + 100 countries.
We have found that first, the capabilities (ESA) should be well documented, with ownership, and business capabilities should be documented as common/shared/unique.
Second, we found it is important to understand the information flows (EIA) between the capabilities. This will then give us the understanding of the required methods for the business services implemented as services in the ESA area.
For us it's now a lot easier to get the different units around the globe to share capabilities (the HOW is not there) and to use common solutions. Breaking it down to lower levels of capabilities, also gives us information on whether a capability delivers any value to the customers. If not, we just eliminate the capability. Our biggest challenge is in raising the maturity on the business side, moving from processes thinking to a capability approach.
A note from Ian Robinson from his blog posting on Business Capability Modeling at: http://iansrobinson.com/2009/03/25/business-capability-modeling/
It’s difficult to escape the entity trap and focus instead on high-level capabilities. It’s partly about getting the right people around at the right time. I prefer to target some initial analysis activities at strategic decision makers, at the people who set big goals and targets, but who don’t involve themselves with the day-to-day how of execution. Follow-up sessions can then better frame the conversation for those responsible for execution – you’re already furnished with descriptions of some significant goals and outcomes, and you can use these to test and challenge the results of the ongoing analysis.
More often than not, however, we do end up in the weeds, focused on low-level, contingent capabilities – process atoms. As a facilitator or guide, I’ll try then to look up and out to the high-level capabilities. Keep asking “And what do you do?” (”And why?”), until you feel you’re getting the “big” answer.
And of course, it’s not always possible to start in the ideal position of engaging with strategic business stakeholders. How many times have I been engaged by an IT function that wants to “get its ducks in a row” before speaking to the business? This sometimes requires you to rehearse “one more time” the Folk IT and business process disorder representations of the problems at hand until, exasperated, someone cries: “Surely it’s simpler than this? There must be a better way!”
And one more thought from Ulrich Homann at Microsoft from his blog on SOA: http://msdn.microsoft.com/en-us/library/aa479368.aspx
One of the most important aspects of capabilities is how they relate to other capabilities; thinking about capabilities in context of the ecosystem is really thinking about their connections. Thus, early detection of their connections to other capabilities, or essentially defining the interrelated ecosystem, is also a crucial step in understanding which boundaries can be traversed and which cannot, a crucial step for maximizing any re-architectural efforts. In fact, discovering these connections may be as valuable as defining the capabilities, because you manipulate and manage the connections, while the capabilities remain essentially unchanged black boxes. A connector could be as simple as the means that transitions the output of one capability to the input of another, an activity for instance that takes a customer request from a phone call (Take Order capability) and sends that to another department to place the order (Place Order capability). In addition, there may be a connector that controls another capability, such as a connection to the Place Order capability that requires notification of a new customer event so that pending orders may be combined.
At a business level, service level expectations (SLEs) strongly influence connections. So, the capability model is also based on the specific analysis of service levels and the notion that if changes in service levels can be achieved by changing who does the work (that is, evaluating different options of sourcing, among them outsourcing) the decision is made on an equal basis across all capabilities in the company. This allows businesses to exchange services without getting mired in the details of how the process is performed. For example, the company ADP can be used for the Pay Employees capability but there is no need to know all the details of how ADP processes the payroll—the only thing that matters is that defined service levels are met or exceeded.
Simply by knowing the differences in a capability's service levels, management can make decisions on the configuration of capabilities needed to improve business performance. Thus, interchangeability becomes a function of comparability. By knowing the rules for encapsulating a business capability (the rules for invoking and completing the services in a trusted fashion) you can complete the technical integration of the capability much more efficiently.
Please continue to send me your own thoughts and comments on this topic at jlamis@architectureandgovernance.com.
