Toss the Capability Map and Focus on Organizational Relationships

Posted by Joseph Lail on Monday, May 23, 2011 - 15:46

Rate this:
Total votes: 0

The topic name is meant to be controversial and elicit discussion; the proposal here is not to completely get rid of Capability Maps but rather to assess the merits of the Org Map as a better means to drill down to actionable Business Architecture. Over the last couple years, I've seen multiple research papers declare the value in drilling several levels in Capability Mapping, where Roles and Processes are certainly part of the characterization (and therefore the two approaches aren't orthogonal). The problem I see is one of Level of Effort; the Capability Mapping appears useful if performed very quickly and then providing context for a cross-functional collaboration in the business that then executes improvements through a focus on cross-business roles and key integrated processes. More often, however, it appears that the Capability Mapping is a great use of energy and resources with little business payoff, because it is drilled down multiple levels across the whole business without that focus on finding the 'center of gravity'.

Now look on your own website and you will find a little artifact called the Org chart. It already exists, and usually it can be cross-linked to leadership bios and lower-level Org charts for each part of the business. What it generally lacks, to provide the type of rigor and value an architect cares about, is a taxonomy (at least number the darn thing with a hierarchical outline) and a way to draw relationships, interfaces, functional partnerships, etc. Modeling the latter hardly requires a whole new Capability Mapping construct, it just requires a more dynamic, linked set of artifacts demonstrating (and maintaining) those relationships tied to the exact same Org chart. With this set of maps and a Business Strategy in hand driving key priorities, you have the means to model the roles and metrics for a core integrated business process that will execute that strategy.

Please provide your experience, views, counter-points, and examples.

Comments

Login or register below to comment on this discussion.
Fahmy Al-Amoody
, Head of Business Architecture & Analysis, Abu Dhabi Judicial Department
posted 1 year 52 weeks ago
Indeed, it could be very frustrating if you were to spend a lot of effort producing architecture models without assurance you will achieve expected outcomes; I faced this challenge before and very well recall the pain I had to go through; the only difference in my case was that I was blueprinting the processes instead of capabilities. Anyway, aren't all these models useful? I guess you should chosen one or a combination that best addresses a business challenge at hand. You drill down to levels that only make sense to your situation. I see no value in wasting too much effort producing so many models or drilling down to levels that don't help in addressing the challenge at hand but rather end up confusing your stakeholders. So your choice should be based on context and purpose. There are 3 important yet related "centre of gravity" spots in any business architecture i.e. people, processes and tools and all these deserve attention because they jointly exist in a "business system".
Joseph Lail
, Chief Architect, Raytheon
posted 3 years 13 weeks ago
OK, so let's kick it up a notch to more specific guidance. Let's assume the group engaged in this discussion understands and uses multiple frameworks and methods (TOGAF Phase B, Zachman Business Model, DoDAF/MoDAF Capabilities/Operational Views, SEI ATAM, FEAF, BPMN), holds multiple certifications, has published papers on Business Architecture concepts, and has suitably impressive IQs. Let's further posit that the skilled, experienced architect will certainly adjust standard methods and artifacts based on a business value stream, where each layer builds on the last and creates a powerful blueprint for the business that goes beyond what individual roles have ever seen before. Now let's answer some questions: 1. How much of your total effort for one full cycle through a blueprint is worth spending on broader or deeper Capability Mapping alone? 2. Can a dynamic Organizational Blueprint, with live relationships and workflow tied to roles on cross-functional processes, play a more central role than shown in the current business architecture body of knowledge and the business layer of standard frameworks? 3. Will one of these mechanisms, or some other method altogether, provide the fastest route down to that center of gravity, the integrated business process and metrics that actually make a big difference for the business, line up with culture/behavioral changes, and drive wise technology investments?
Tony Phillips
, Consultant, E-Loan
posted 3 years 13 weeks ago
I follow the Bauhaus school of Enterprise Architecture where “Form Follows Function” So for me: step 1 is define your Business Objectives, step 2 is define the Functions (or Capabilities) that will enable meeting these objectives, step 3 is define the architecture needed to provide the Functions and meet the Objectives. This last step includes Zachman’s Data, Processes, Business Rules, Locations and the Organization structure - each of these should trace to your Capabilities and your Capabilities should in turn trace to your Objectives - this is your Capability Map
Adrian Grigoriu
, Enterprise Architect, Own
posted 3 years 13 weeks ago
We should use both capability maps and organisational charts. The first is functional, the second is about the real people organization. Business (and EA) architects should align them for optimal operation of the enterprise. An EA typically describes the business, technology and people layers of an Enterprise. The organisation architecture belongs to the people layer (of EA) while the capablity architecture belongs to the business layer. See more at http://www.enterprise-architecture-matters.co.uk/home
james beckingham
, enterprise architect, self
posted 3 years 13 weeks ago
Depends on the situation. Every business architecture should answer 3 fundamental questions: What do we do? How do we do it? and How are we organized? Capabilities, Processes, and Structure.
Joseph Lail
, Chief Architect, Raytheon
posted 3 years 14 weeks ago
Great discussion so far, but it still hasn't quite scratched the itch on the relative merits of the artifacts and where to spend the most energy first. Tied to some of the points posted: 1. Drilling to the right business focus with an Org Map doesn't constrain you to the "As Is" any more than starting with the current state for a Capability Map or Process Model; in fact it may better describe the hardest change that has to occur for any major business initiative to succeed, which is cultural shift and required changes to the Org model. 2. The new Business Architecture text does a great job in the first two chapters of describing why businesses fail in these strategic initiatives without a blueprint (I could swear Bill was talking about my company), and I'm already using that clear description of the problem. The later chapters, however, just like the link provided, show more of the abstract theory and artifacts without providing concrete examples and hard world lessons of what is actually worth spending 80% of your effort on vs. 2%. 3. Using the Org chart with real additional relationship mapping and linkages doesn't have to include people's names, it's more valuable for roles and authority tied to ensuring a business initiative is assigned top down, leading to which roles execute which actions on a future, more collaborative and measured business process. A dynamic model would allow you to click on a role or Org. element and see who is in that role right now, but loosely coupled since the names change and the new person in that role should still be responsible for their part of a collaborative process that improves the business. Completely agree that where the rubber meets the road is when you obtain buy-in cross-functionally and then throw all the energy into modeling, deploying, and monitoring the end-to-end process with known value metrics. 4. The point about deriving a business model out of the Annual Report is very insightful, and I suppose it argues for putting more energy into the fully linked Org. Map as a means to drive collaboration and accountability down into a game-changing cross-functional business process, since you're unlikely to directly map a Business Model into a Capability Model.
Andrew Guitarte...
, AVP / Business Architect, Wells Fargo & Company
posted 3 years 14 weeks ago
Good point! We cannot ignore the importance of the People dimension in our triage of People, Process, & Tools that are encapsulated in a business capability. An org chart (functional or informal, etc.) is a recommended starting point when creating capability maps. Another good starting point is the Annual Report when you want to reverse engineer the Business Model using the company Financial Model. But don't stop there! Keep going and drilling and eliciting until you arrive at an "adequate" level of detail for your capability map. But keep going! Map this model with your other entities such as Process Model, Organization Model, Strategy Model, Project Portfolio Model, etc. until you come up with the perspective that your customers have been dying to see (and probably never saw before). Iterate often until you arrive at an "Aha" moment with the C-level exec for example. The work may seem never ending but the rewards are worth it. As you can tell, Business Architecture is real work.
Fabian J. Dohmes
, Director, Business Analysis, Dell, Inc.
posted 3 years 14 weeks ago
I suppose it depends on the size of your company and how it is structured. But in my experience it is a good idea to stay away from the org chart, at most using it as a secondary source of information. Org structures come and go, people build their little empires, get fired, their areas get absorbed by multiple people... Especially in the large corporate world, I've often found considerble mis-alignment of the executive level with the fundamental value streams in the company. But I agree with the statement that one should not spend too much effort on the capability model, and not drill down too far into the more detailed levels where things become very company-specific. The value derived from any accuracy there is not proportional to the time you need to invest. Instead, for that level I find it's better to focus on key cross-functional processes and end-to-end value-add processes (as defined from the customer's perspective).
William Ulrich
, President, TSG, Inc.
posted 3 years 14 weeks ago
J. Bryan -- The organization view is one leg of the business architecture stool along with capability map, value streams and information assets. It is often overlooked so it is useful to bring up the topic. But Ken is right. (Good comments Ken.) Organizational structures are often a problem and the way to disentangle the redundancies that are common across the business is through capability-organizational mapping. So if you pop over to page 8 in the presentation posted to the business architecture institute link - https://www.bpminstitute.org/uploads/media/Ulrich-11-8-07.pdf - you will find a social networking diagram that maps to business capabilities. This is a very old version of this content and there are other versions posted - but this reflects the fact that the organization-capability mapping concept has been around business architecture for some time. For more updated views go to more recent articles or presentations, or check out "Business Architecture: The Art and Practice of Business Transformation" MK Press-2010. Using these views one can begin to reconcile the severe redundancies inherent in most organizational structures. WMU
Ken Mullins
, Senior Principal , MITRE Corporation
posted 3 years 14 weeks ago
I believe that Business Architecture should be developed and maintained without being constrained by the "As Is" organizational construct -- for more than one reason: a) Organizations are seldom structured in a manner that streamlines business operations; b) Many business domains extend beyond organizational boundaries (to include, for example, business partners, suppliers, regulators, customers, interest groups, etc.); and, c) to be more certain that all stakeholders are consciously aware of the need to interact on a "global" scale -- and not be blinded by their more comfortable (i.e., parochial) views of the world.

Already a Member? Login Here:

Shopping cart

View your shopping cart.

Business Process Management Jobs

Editorial Directors

Gregg Rock
Editor & Founder
BPMInstitute.org
Tom Dwyer
BPM Editorial Director
BPMInstitute.org
James Taylor
BDM Editorial Director
BPMInstitute.org
William Ulrich
BA Editorial Director
BAInstitute.org
Mike Rosen
SOA Editorial Director
SOAInstitute.org