There is a strong current interest in Business Architecture that has been brewing in the last little. To deal with it at Process Renewal group we have been developing methods and frameworks that professionals can use for inspiration. Our overall approach to the challenge has been to practice and teach the practices as shown in the following.
Roger Burlton, President, Process Renewal Group; roger.burlton@processrenewal.com
Roger will be teaching multiple courses in London on the subjects; Business Architecture Best Practices: Practical Methods to Enable Business Change 3-5 June 2019, and Digital Process Analysis and Design: Optimizing the Customer Experience through Digital Innovation 6-7 June 2019
All of these models are absolutely essential to establish a relevant architecture that makes business sense. In this article I will tackle a topic that has both intrigued me and driven me crazy at times. There is a well-established Enterprise Architecture camp, often associated with IT groups and its need to understand the business requirements for technology planning, prioritization and implementation that sees ‘capability’ as the central concept of Business Architecture. There are other points of view that see it a little differently. All have merit. I will get into some of the various perspectives that are out there and try to make sense some of the thinking to keep our approach business oriented and not just about IT.
The capababilty aspect of business architecture is still emerging and at this point there are no real agreed standards in place although several groups are advocating their views and working on proposals. Several large consulting and technology firms are pushing their own views with the apparent aim to land large projects down the line.
Within the methodology the exchange of knowledge looks like the following:
The most comprehensive work performed to define a number of business architecture views and the main promoter of capabilities is The Business Architecture Guild in its Business Architecture Body of Knowledge (BIZBOK). Although I do not agree with every perspective and classification taken in it, on the whole, I find it a very useful guide that is updated regularly as experiences are gained. This is a good reference since it has a strong value delivery orientation, consistent with our approach at Process Renewal Group. It includes a large section on capabilities and the value streams required to define them.
What is a business capability?
The challenge with the term ‘capability’ as used by Information Technologists and Enterprise Architects especially, is that it is often used in a specific and uni-dimensional way that may not be apparent or make sense to everyone. As used in the common vernacular, it typically is associated with an implied assessment of the ability of something or someone to achieve some purpose. When used alone in an architectural setting it can be confusing unless it has a defining context associated with it; capability of what? It is typically applied to something; some physical object such as a car or a toaster; some human resource such as the CEO or the call center agent; some piece of information technology. The list goes on. It can also be associated with something more conceptual such as a company, enterprise or department or even an innovation. In business architecture circles several groups are using it to describe some attribute of work that gets performed at some level of detail and usage from conceptual value chain level to value stream to day to day detailed work activities. The nature of the term in the English language is that it is structured as needing context to always modify or describe another concept. In business, any of the structural work domains can be described as requiring or having one or more capabilities. In natural language it works best as an adjective and not as a noun in that it does not stand alone. Just saying ‘capability’ is not sufficient since the word always needs a frame of reference. Is it the capability of a person, an organization, a value chain, value stream, a process, a piece of software, a facility or piece of equipment that we are talking about? The term ‘capable’ as defined by Merriam-Webster’s dictionary means ‘having attributes (as physical or mental power) required for performance or accomplishment’. Therefore, for practical usage, it is essential to know the purpose of your organization, your business processes and each of the attributes your enabling assets need to have in order to know whether to assess it as a suitable capability or one that is lacking relative to what would be ideal. A hammer in the right hands is very capable of enabling you to put a nail into a piece of wood if that is your purpose but not so capable in any hands if sawing that piece of wood in half if that’s what’s needed. ‘Capability’ then needs both a business context as well as a set of criteria (purpose) for assessment. Again, in everyday parlance the word should never be used without clear criteria and a frame of reference.
In a business architecture domain, the term is used differently. It is used as a characteristic of business concept (aka business object) in its own right without regard to the level of its ability to perform. It is used as a name for something which may have or may need a low level of ability or a high level of ability. Performance ability is not a requisite and regardless, the name is the same. The assessment is not implicit in the name itself. ‘Credit worthiness assessment’ does not say how good you have to be at it only that you need that capability in your business at some level of ability to perform.
The Business Context
Capability in a business architecture sense has come to mean what is required to enable or contribute to the creation of value, directly or indirectly, towards the intent of the organization or value chain stakeholders who receive our goods and services. As such, there is a strong alignment of ‘capabilities’ with ‘business processes’ although many business architects have lost sight of that critical connection and focus almost exclusively on capability maps to the exclusion of process architecture maps which incorporate value creation – value streams. It is important, however, to not build them into one another or ignore one perspective since both are key concepts required to operate and redesign a business. The figure on the right shows a common misconception as to how the two are interrelated. It is simply not correct since good architectural principles, as re-iterated by John Zachman, simply state that you cannot decompose one concept (architectural domain – aka Zachman column) into another type. You have to maintain the integrity of each domain individually and primitively and associate them with a meaningful set of relationship semantics. In architecture we should be representing processes and capabilities in a many-to-many relationship as shown below. Both are needed.
In a recent personal experience of renewing a passport from another country (I am Canadian) I experienced the difference. The passport office processed the application and handed it off to a courier to ship internationally. A business architect I know from the courier company had told me earlier that international shipping was a key capability of the company. When they failed to deliver the envelope as promised and lost my passport for several days my conclusion was that there may have been a capability on the capability map but the process of using such capabilities failed to connect the dots and provide value to me. We need both!
Some Principles
Key Traits of a Robust Business Architecture
In my meetings recently at Huawei Technologies in China with Bill Ulrich of the Business Architecture Guild and Giovanni Traverso, Chief Architect at Huawei and active participant in The Open Group standards activities, we established a simple conceptual model for the interplay among business strategy, Value streams, business processes and capabilities. This is part of a bigger model but I will focus on this aspect for now and we will use this to frame the remainder of this article. I will expose other aspects of an extended view of this model in later articles.
In order to manage capabilities as reusable and easy to change assets, organizations need to establish a robust capability architecture that leverages ‘no redundancy thinking’. A sound enterprise level view of all capabilities will exhibit some key traits as defined in the Business Architecture Guild’s BIZBOK.
Capabilities:
• Provide business centric views of an organization
• Are defined in business terms
• Define what a business does
• Are stable
• Are defined once for an enterprise (or component thereof)
• Decompose into more capabilities
• There is one capability map for a business (a business may have more than one enterprise or be a part of one)
• Map to other views of the business
• An automated capability is still a business capability not an IT one
• If the mapping team cannot define a capability it probably is not one
There is a very strong alignment of these with the principles outlined in an earlier article for a value creating process architecture and definition. The main difference is that capabilities are expressed as nouns or gerunds not verbs and business processes and value streams are expressed as verb-noun constructs. Just like processes the capability map should be:
• Organizationally Agnostic
• Technologically Agnostic
• Share a consistent classification structure of Core, Guiding and Enabling
• Initially keep to a Limited Depth of Structure (typically 3 to 4 levels deep)
• Describe ‘what we do’ and not so much the variations in ‘how we do it’
• Should be stable over time unless the business model itself is changed
• Their impact should be measurable
• Be traceable to higher level capabilities and aligned with others at the same level
Good Capabilities Start with Business Concepts / Objects
The BIZBOK defines a capability as “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome”. A capability map should contain ‘a concise, non-redundant, complete, business-centric view of the business’.
Value streams and business processes are about defining actions to create ultimate value for a recipient but just using these models alone may not sufficiently pinpoint the gaps, needed improvements or investment required and can lead to redundant development of resources to do work. However, looking from a capability map perspective alone also does not provide a context for the importance or effectiveness of a given capability, especially in how it and other capabilities in concert can impact and propel stakeholder value delivery through the processes within which it is applied. Both views are required to work together to make the right changes happen. If there is both a good capability architecture and process architecture in place then the mapping of one to the other will be straight forward. If not, value stream assessment may be a useful tool to figure out what capabilities are needed.
The context for identifying capabilities is best (most simply) served by taking a unique business concept / object orientation. Business objects built around all aspects of specific types of relationship (customer, etc.) and around other particular objects of interest (assets and intangible business concepts) that have to be managed by the business. To find a comprehensive list of possible relevant business objects we can identify all relationships and all items that must be managed. This is not as simple as it sounds since many business objects are used in companion with others and it is hard to see them separated. In effect we are striving to ‘normalize’ them. For a consumer bank example we could find a number of relationships to be managed and place them into our three categories as we did for business processes in a prior article. Some of these could be:
Guiding
• Bank Board
• Bank Regulators
Core
• Consumers
• Bank Partners
Enabling
• Suppliers
• Technology Partners
• Employees
• Facility Service Providers
Each of these can have several sub-types which would be shown as a next level and can be shown as a decomposition but only if we deal with them in a different manner. For example, a consumer may be broken down into high wealth consumer versus and transactional consumer types. Each may have unique needs and value requirements but some will be in common. There are also patterns that become apparent across multiple types of relationships. Are there attributes of a customer relationship that are similar to a partner one? You will have to determine if they can be satisfied by a common set of capabilities or if each is truly unique. How much of the customer cycle is similar to the partner one and where are the differences?
Other business objects can be discovered by looking at the concept model of all information items that have to be managed by the business (if you have one) Each object will follow a lifecycle and different capabilities will be needed depending where you are in it..
For the consumer bank some potential high level business objects (there will be sub types as well), in addition to relationships, may be:
Guiding
• Business Strategy
• Budgets
• Policies
• Business Rules
• Regulations
• Risk
• Brand
• Intellectual Property
Core
• Financial Products and Services
• Financial Resources
Enabling
• Technology
• Facilities
• Business Processes
• Equipment
• Supplies
• Information
• Knowledge
• Agreements
Again some of these may have distinctions as sub types and you will have to determine how deep to go.
Let’s examine some illustrations of stakeholder centric capabilities. The consumer set will be relevant to the management of the relationship with the consumer but will not include the capabilities of managing the financial products and services that they are sold and use. The regulator set will deal with the management of the regulator relationship but will not deal with a regulation or the policy needed to mitigate it per se. The facility provider (supplier sub type) relationship will be the subject of a set of capabilities but the facility itself will be a different set. It is important not to mix these as capabilities otherwise a change in one will change everything and the goal of capability normalization will be lost and change will be more complex than necessary. They will be connected through the vehicle of the value stream or the business process that uses them.
At the top level of the capability for our consumer banking example expect to see something like:
By looking at this map it is easy to see why, at a high level, capability advocates and process advocates may not see the need for one another’s perspective since both approaches are based on making relationships work well for end to end value delivery and on ensuring all the business objects are at their best. Diving deeper, however, lets us see the benefits for separating the two and coupling them in a many to many combination. Let’s look at some decomposition of a few high-level capabilities from the map by asking ‘what are the things that have to be managed at a more detailed level?’. I have picked several illustrations of capabilities to the second and third level. These are not exhaustive and possibly wrong but the pattern can be seen.
From this illustration it is obvious that there can easily be hundreds of level 3 and thousands of level 4 capabilities and it is tempting to go even deeper so it may be more appropriate to do a top level skeleton covering all the macro items as we did with the process architecture and only drill into the ones that we deem priority.
Good Capabilities Associate with Good Value Streams
Capabilities should ultimate be associated with value streams and business processes.
The term ‘value stream’ is another one that is used in varying contexts by different communities and is thus potentially confusing. For those from the process world it is typically seen as the scope of the end-to-end work to be improved in a Lean or Lean Six Sigma (LSS) initiative. Wikipedia states that ‘value stream mapping is a lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer. At Toyota, it is known as “material and information flow mapping”’. It is the detailed flow of product and information that leads to meeting customer expectations (i.e. value). It is used as the basis for the elimination of non-value added work (waste) for the benefit of the customer and thereby the business. It is a key to framing process improvement. There are some similarities and differences in meanings when the term is used in business architecture. Similarities include a focus on value as seen by the recipient of the results of the stream and there is a strong likelihood of a similar logic at major state changes from start to end. The common architectural usage is to stay higher and define the concept of the work stages but not to define the details of a work and information flow for analysis and redesign of specific activities and artifacts as required by LSS. Its purpose is to keep the architecture focused on value creation. It is more of a means to inspire the right ends in both the process architecture and in capability maps. The BIZBOK states that ‘Value Maps provide a context for and are enabled by business capabilities’. In this sense a value stream, as used by business architects, is a stakeholder triggered, end-to-end depiction of what a business conceptually does to deliver value to that stakeholder. There is no assignment or evaluation of ‘state‘, as in ‘current’ or ‘future’. Value Maps are conceptual and logical only. A value stream exhibits the same verb-noun nomenclature that we have described for business processes in an earlier article. Within the stream there are logical value creation points that a process practitioner may call an activity but a business architect may call a ‘stage’. The Business Architecture Guild would claim that value streams are perspectives on the business not processes per se although they can provide a basis for them. A value oriented conceptual process architecture, as we advocate, as opposed to a functional or activity oriented one, would look very similar to a set of value streams so it is easy to understand the potential confusion.
So how can we find and define our value streams? The best way to discover these is to re-examine and reuse some of the concepts used in the process architecture article that preceded this one. There is absolute consistency with the object basis that business architects would use and complete alignment with our view that the objects of interest are either relationships with stakeholders or business objects that must be managed throughout a lifecycle from concept to termination. Within those we can find our value streams and the stages within them.
These are identified at a very high level in the process skeleton shown.
Following the relationship value lifecycle approach, we may come up with component stream stages or activities for a bank core consumer within the larger value stream ‘Provide Consumer Services’ and likewise for a business object cycle we may also come up with stages for ‘Make consumer products and services available’. Each of these can have a next level of value creation within it and can be shown as a decomposition.
Each value stream description will have a name, definition, opening event / criteria, closing event / criteria and will identify the participating stakeholders. It will also identify any sub levels of value creation stages / activities.
Cross Mapping Processes and Capabilities
Once we have a Process / Value Stream Architecture we can connect the dots so that once any of these are found to be lacking or a new strategy for it becomes apparent, we are in a position to determine all of the impacts of the changes. This includes aspects of the process and operational impacts due to capability adjustments and also capability changes due to process improvement or innovations. The diagram below shows a sub set of the capability and process architecture maps and some of the connectivity between them. Note that a capability at any given level may affect a number of processes also at any given level in the hierarchy. There is a many to many relationship among capabilities and processes and discovering the connection is a key to ongoing adaptability / easy of change.
This diagram is obviously not simple when shown graphically and I only show it to help the reader gain an understanding of the concept. Matrix views or queries may be a better way to show the connections. The use of repository tools based on an appropriate meta-model is essential once these types of architectures are being built to ensure integrity and to keep your sanity. Visio and the like cannot handle this integrity requirement.
The Burlton Hexagon
We have discussed capabilities as a concept in this article and as we all gain more and more experience with them the body of knowledge will become richer. Realizing a new capability in terms of making a difference in value creation of the business, however, may require many other architectural components to be changed. The Burlton hexagon shows the relationships among these resources that are critical to bring the capability to a higher state of ability.
That’s the way I see it.
Roger T Burlton, P. Eng., CMC, is the President of Process Renewal Group and co-founder of BPTrends Associates, the services arm of the BPM knowledge portal BPTrends.com. He is the author of the thought leading book ‘Business Process Management: Profiting from Process’. He is considered the industry leader in the introduction of realistic ways of implementing enterprise BPM programs as well as innovative approaches for organizational and process change. He is the editor of the ‘Business Process Manifesto’ which is now available in fourteen languages. He is actively involved with the Business Architecture Guild to define how processes and business architecture work best together. He has helped over one hundred organizations implement BPM as a corporate strategy in many different industries, countries and cultures. An exceptional speaker, he has chaired over fifty high profile conferences on Advanced Business Architecture and Process Management around the world. To date, he has conducted over seven hundred seminars and has presented to over sixty thousand professionals. His seminars have been translated for diverse audiences around the globe.
Copyright Roger Burlton, President, Process Renewal Group