How to Lead When Building a Business Capability Model

Topics

Andrew Guitarte, DBA, PMP, CBAP, PMI-ACP, CIP is AVP / Business Architect at Wells Fargo and Management Consultant with more than 20 years of work experience in the financial, IT, government, and small business industries in the US and Asia.
Mr. Guitarte is the founding Chairman of Business Architecture Society based in the San Francisco Bay A...

If you are leading your organization’s business capability model (BCM) development, here are some guidelines that you can follow. First, agree on a definition of a business capability. It’s important that the team nails this down upfront. The distinguished architect Ulrich Homann, while working for Microsoft as a solutions architect in 2006 defined business capability as “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.” He was deep in SOA research and some of his work should be taken with a grain of salt in relation to business architecture. In hindsight, there will be ways to improve this definition but this seems to work for most organizations. The bigger challenge lies in distinguishing a business capability from a business function, for example. Or from a service domain, especially those familiar with the Banking Industry Architecture Network (BIAN) Service Landscape. You may want to refine the characteristics of a business capability to help draw the line. I hear of folks who treat this as some sort of a religious war. As a leader, be wary of getting sucked in. Stay objective at all times. Such debate on nomenclature may seem trivial and frivolous at times. But it can confuse the novice business architect and even the more seasoned among us. What is important is that your organization agrees on a common definition that you can use consistently. Which brings me to the next guideline. Second, agree on rules of engagement. How do you resolve conflict? I am part of a working group of an international standards-making body. We have specific rules on how to promote changes. It goes through a rigorous process of checks-and-balances. It may be arduous but it’s fair. Does your organization have one? Third, agree to disagree. There is no such thing as a smooth BCM session. There will be disagreements. But there is room to iterate later. What’s important is to get something out the door that’s “good enough.” We probably heard of the term “satisficing” coined by Noble-laureate Herbert Simon in 1956. It’s a decision-making technique to come up with a sufficient alternative among many to manage a complex problem. A BCM working session is fraught with arguments, politics, and a lot of bravado. There will only be an optimal solution if this was a simple problem. But it’s not. A satisfactory and sufficient compromise is what we should shoot for. I led a BCM development initiative in my organization. We met weekly every Friday for a couple of hours. The meetings went on for nine months. The “we” here were business architects from all over the company, plus subject matter experts like senior managers in strategic planning, finance, legal, risk, technology, marketing, and operations. The end result was a “good enough” set of more than a hundred business capabilities grouped into categories that made sense for the company. We are now in the second phase of BCM development, inviting more changes and feedback. It is a long journey that we lead but has long lasting impact that will change the company permanently. In summary, you need to agree on the definition of a business capability, rules of engagement, and when in an impasse, agree to disagree. A “good enough” BCM will be your launching pad to greater heights of success for business architecture.