Recently, Paul Harmon published an article in BPTrends that discusses his views on the notion of Business Capability, and whether it is a useful concept.  He was not particularly kind to the field of Business Architecture in his article.  While I encourage my readers to take a few minutes to read the original, I have included a few excerpts to give perspective to those with a little less time on their hands:

    • To date, I have to admit that I have no clear idea of what the term "capability" means.
    • In other words, as far as I can see, according to this definition, a "capability" is just a way of talking about being able to produce what processes produce.
    • I don’t see a real difference between WHAT an organization can do and HOW the organization will do it.
    • I might prefer to call it a Business Process Architecture, but I can certainly live with the term Business Architecture, if that’s what most people come to prefer.
    • the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.
    • If former IT architects want to become business architects, I’m all for it, but they are going to find that there are BPM practitioners who are already functioning in that role, and I believe they will be well advised to work with us rather than trying to create a new body of knowledge with a new vocabulary.
    • I believe that we ought to resist any urge to quickly redefine terms and practices that we have been using for many years.


My attention was called to this article by a reader of my blog who was interested in my response.  This is particularly apropos because, as a member of the OMG Business Architecture Working Group (or BAWG), I am one of the folks that Mr. Harmon is talking about. 

First let me say that his criticisms are fair.  As any new methodology appears, it runs the risk of creating confusion in the minds of business stakeholders.  We are not immune to that criticism.  In fact, within my own organization, BPM practitioners have been dismayed by the discussion of business capabilities and have asked many of the same questions that Mr. Harmon asks.  In our organization, we have worked to address those concerns and I believe we have been successful.  I will be sharing some of those discussions with readers in upcoming posts.  In addition, I welcome Mr. Harmon’s questions and would love to work with him, and any other member of the BPM community, to amicably answer these concerns as best I can.  I hope that the efforts of the BAWG will produce fruit by providing the consistent basis that Mr. Harmon so clearly calls for.

I don’t agree with Mr. Harmon’s conclusion: business architecture is a ‘redefinition’ of Business Process Management terms and practices.  That said, my belief is based on my own practice.  I recognize that Mr. Harmon may have been speaking with practitioners who have been using Business Architecture concepts in confusing and inconsistent ways. 

Just as business process management did not coalesce as a profession until some key voices published books that entered general business practice, I ask only that Mr. Harmon consider the possibility that Business Architects have not found a small set of clear voices just yet.  Our field is younger.  Just as the folks who believe that “functional groupings” were a reasonable way to organize a company may have found confusion in the introduction of BPM concepts 20 years ago, I believe that business and BPM professionals are finding confusion in the introduction of BA concepts today.  We are not less legitimate as the result of our youth… but we are less coherent.

His confusion is healthy, and through his expression, he provides further demand for the outputs of the BAWG and other BA thinkers who want to resolve his dilemmas and create clarity. 

I ask for patience. 

I will attempt to answer specific questions in later blog posts.  I wanted to start with this message to make it clear that I do not view Mr. Harmon, or any other business professional, as opposed to the ideas that I profess.  Rather I view his views as the necessary result of our own poor consistency, in words and practices.  I am confident that, as our profession matures and we find our voice, we will demonstrate clearly the ways in which BPM professionals and EA professionals can support each other’s efforts and build a shared model of success.

We can, we should, we must, be united in our shared goal: to improve the ability of our organizations to fulfill their missions. 

We want the same things.  We are using different tools, at different points in different processes, to achieve them.  By working together, and not apart, we will both succeed in a better way.  I seek to find that common ground.  I beg all who want the same things to help me to find it.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 thoughts on “Finding Common Ground: in response to a BPTrends article on Process and Capability”
  1. Nick

    Somehow I feel that both the capabilities world and the business processes world consider analysis as the objective as opposed to the "ability of our organizations to fulfill their missions". I have been through numerous projects at this time where I have seen folks continuously modeling away without much thought to why the model in the first place

    I have not looked at BAWG so I cannot comment on it, but I did take a read the sally and joe example. While, I am with you on the hammer analogy, the analogy is right because I have seen someone use it successfully, you cannot apply it directly to capability modeling

    Is there anything quantifiable out there which will help model and prove some of these things than aesthetically appealing wall-charts ?



Leave a Reply

Your email address will not be published. Required fields are marked *

eight + five =

This site uses Akismet to reduce spam. Learn how your comment data is processed.