Patterns – More than Mere Stencils
Last Thursday I made a presentation on patterns to the local Canberra Enterprise Architect User Group. The presentation showed what patterns were and how they could be used within Enterprise Architect. The slides aren’t designed to stand on their own, but I thought I’d post them on my blog nonetheless. A quick note of acknowledgement all the slides to do with business architecture come from pictures posted by Tom Graves on his blog.
The Parable of the Soup Spoon – A Practical Example of Capabilities
This post builds on my previous post on capabilities with a parable about a soup spoon. When I was in the middle of composing my last post on capabilities, I attempted to explain some of the concepts to my fiancée as we were having lunch in a Vietnamese restaurant. As I searched around for relateable metaphors, my soup spoon caught my eyes.
Recall how a capability two aspects: possession and realisation, as illustrated below?
| Possessed | Not Possessed | |
|---|---|---|
| Realised | Organisation has capability and is using it to generate value. | Competitor has capability, threat for organisation in focus. |
| Not Realised | Organisation has capability, hasn’t assigned resources to it in order to generate value. | Organisation has identified capability as crucial to generating value in the future. |
Let’s apply these two aspects to the soup spoon. For the sake of this example, we have to set some parameters. Obviously the value to be gained from using a soup spoon is eating. Assume that the only way to get food to the mouth, to eat, is via a soup spoon.
| Possessed | Not Possessed | |
|---|---|---|
| Realised | Own the soup spoon and using it to eat | Competitor using soup spoon to eat. |
| Not Realised | Own the soup spoon and not using it to eat. | Has a need for a soup spoon. Probably because there’s a hot bowl of soup in front of them “Hey waiter, can I have a spoon?”. |
My fiancée brought up a good point as I explained this. You require capabilities to build capabilities. A soup spoon can’t materialise out of thin air, it has to be manufactured and then subsequently brought to you by the wait staff.
Capabilities – The Gap Between Intention and Outcome
There has recently been much debate about the word capability. But, as has been pointed out to me, this isn’t a recent debate, nor is it a recent topic. However the debate has been resurfacing. Paul Harmon wrote a newsletter in BP Trends expressing his confusion on the topic, and his attempt to understand it (Harmon, 2011). Mr Harmon was attempting to understand the term capability as it relates to business process management and business architecture, when in reality the term isn’t limited to these two domains. Nick Malik wrote a very dignified reply acknowledging the lack of clarity that Mr Harmon was experiencing and calling for patience as Business Architecture matures as a profession, and with that maturity articulates some of the key topics more clearly. Capabilities have been popping up on the Twitter stream lately too and in blog posts, sometimes continuing into discussions in the comments. Latching onto this, I made some comments on some of the posts, expressing my opinion. I decided that a blog post of my own would be the best way to document my thoughts coherently. In this post I’m going to define the term capability from a number of sources and then talk about their classification.
Plain English Definition of Capability
Any definition should start with a dictionary definition, and as I’m Australian I’ll reference the Macquarie Dictionary. The first two definitions refer to: “the quality of being capable”, and to “admitting of certain treatment”, both of which are, in my opinion, irrelevant to the context of this post. So I’ll start at definition three.
3. a quality, ability, etc., that can be developed or used.
4. technical capacity, as of a machine, system, piece of equipment, etc.
The Macquarie Dictionary Online
These definitions don’t give any hint of the complexity and debate that this topic engenders. The term capability in and of itself, is a relatively standard English word. What makes it so complex, is its use covers a number of domain and from its plain English origins, it has taken on technical nuances, while mostly still masquerading as a plain English word. Let’s examine where and how the word has taken on that technical nuance. To be clear, when I refer to technical definitions, I’m not speaking exclusively about information technology, but “technical” as in the jargon of a domain.
The Origin of the Word Capability as Jargon
Mr Harmon described how he did a literature search to ascertain the origins of the term capability as it is used in business architecture and process architecture and came to the conclusion that the term was relatively recent, that is less than three years old.
I have tried to find one [definition of capability]—by reading articles and by asking questions in discussion groups. To date, I have to admit that I have no clear idea of what the term “capability” means. There is no one person or article that is commonly credited with an initial use of the term. The rapid rise to popularity of this ordinary language term has resulted in lots of people talking about “capabilities” without any agreement on what the term means.
So, the term itself is recent in regard to business architecture and business process management. However, that doesn’t mean it’s recent in regard to business itself. The word capability has its origins in the field of strategic management, more specifically in the field of competitive advantage. The original use of the concept was Edith Penrose with her 1959 article, The Theory of the Growth of the Firm. Granted she didn’t specifically use the term capabilities, but rather the analogous term, competencies (Weinstein and Azoulay, 1999).
Within the field of competitive advantage there are two main schools of thought: the resource based view, championed by authors such as Edith Penrose and Alfred Chandler; and the positioning view, of which the most well-known proponent is Michael Porter. It is from the resource based school of the thought that the notion of capabilities arise. A firms’ competitiveness they contend, arises from the control of resources and the implicit capabilities that a firm develops in the specific context of their industry. By deploying their resources and capabilities in the best strategic way, they will be able to build a sustainable competitive advantage. Those inherent capabilities give the firm a distinct competitive advantage that enables it to maximise its use of resources (throughput capacity) leading it to outproduce its competitors. As the firm seeks to grow, its capabilities, which are developed in one context, allow it to reach out into other markets, leading to both vertical and horizontal integration (Weinstein and Azoulay, 1999; Acar and Zehir, 2009; Chandler, 1992).
Within the context of the resource view of competitive advantage the term capabilities is often used interchangeably with the term competencies (Weistein and Azoulay, 1999). This may be why there is the misconception that the term capabilities has not been around for long . Capabilities is now becoming the more favoured term. In the literature that refers to these capabilities/competencies, the common elements as described by Weinstein and Azoulay are:
(i) Specific to a firm.
(ii) Difficult or impossible to copy.
(iii) Cannot be acquired on the market.
While the above elements start to make the term capabilities clearer, it still doesn’t give us an exact definition of the term. It appears that Mr Harmon’s contention that there isn’t a clear, agreed definition may be correct; this is corroborated by Dosi, Nelson and Winter, 1999.
Leondard-Barton described the four dimensions in firms’ capabilities:
- Employee knowledge and skills
- Physical technical systems (equipment, software
- Managerial systems (organisational sctructure, regulations, routines, decision procedures)
- Values and norms (system of castes, status, rituals of behaviour etc)
The Gap Between Intention and Outcome
Dosi, Nelson and Winter, 1999, describe very succinctly how a capability fills the gap between an intention and an outcome.
To be capable of some thing is to have a generally reliable capacity to bring that thing about as a result of intended action. Capabilities fill the gap between intention and outcome, and they fill it in such a way that the outcome bears a definite resemblance to what was intended.
However, not all organisations have the capability to bring about the intended outcome. Between forming the intention and reaching the outcome, they know they have to both posses and realise the capability. Possession alone is not enough – think of a teacher writing on a child’s report card. “Stephen possess such a wonderful mathematical ability, if only he would apply it”. I’ve drawn up a simple matrix describing these relationships below.
| Possessed | Not Possessed | |
|---|---|---|
| Realised | Organisation has capability and is using it to generate value. | Competitor has capability, threat for organisation in focus. |
| Not Realised | Organisation has capability, hasn’t assigned resources to it in order to generate value. | Organisation has identified capability as crucial to generating value in the future. |
Conclusion
I want to use this article as a platform to explain some of the misconceptions that Mr Harmon had in his article (Harmon, 2011) where he was trying to understand what a capability was. I have shown in this article that the concept of capabilities has been around for over fifty years. I’ve given some good definitions and shown that the field of business architecture hasn’t just invented this term. I’ve also shown how the term is important to strategic management and therefore to strategic business architecture with the distinction between possession or lack of possession and whether or not a capability is realised.
There’s still a lot more to write about in future articles such as its use in the field of project and programme management and the relationship between capabilities and value. I’d really like some feedback on this article, so if you’re willing to take the time, over to you.
References
Acar, A. and Zehir, C., 2009, Development and Validation of Resource Based Business Capabilities Measurement Instrument.
Chandler, A., 1992, Organizational Capabilities and the Economic History of Enterprise.
Dosi, G., Nelson, G., and Winter, S (Eds.), 1999, The Nature and Dynamics of Organizational Capabilities, Oxford University Press, Oxford.
Harmon, P. 2011, Capabilities and Processes, BPTrends Business Process Trends, Vol9, Num13, available at http://www.bptrends.com/publicationfiles/advisor20110712.pdf.
Weinstein, O and Azoulay, N., 1999, Firms’ Capabilities and Organizational Learning A critical survey of some literature.
Wrong Jungle
This post is in response to Tom Graves‘ earlier post: Analyst, anarchist, architect. The article warranted a longer response than I could put in a comment. It’s also great impetus to get back into writing posts, which I have been somewhat neglectful of lately. I have however, been enjoying some really interesting dialogue with people from the business analyst and enterprise architect communities all around the world, which has been very stimulating.
Tom wrote about the the Hegelian triad and its analogies to analysis, anarchy and architecture. The description of the difference between the analyst and the anarchist reminded me of a story that Steven Covey related in “The 7 Habits of Highly Effective People” on that age old contention – the difference between managers and leaders. I’ll paraphrase it here:
The workers are cutting a path through the jungle. Behind them come the managers: sharpening machetes and writing procedural manuals. Meanwhile, the leader looks around, spies the tallest tree in the vicinity and climbs it. From up the top he shouts, “wrong…jungle”.
I think this could just as easily apply to the analysts and anarchists as it could to mangers and leaders. Tom writes how it is up to architects to then bring things back in the concrete so that, to return to the analogy, we’re in the right jungle, with the best of procedures and the sharpest of machetes.
So what has been my experience of the dynamic tension and the dynamic balance between the triad of the immediate, the mediated and the concrete? Or the analyst, anarchist and the architect? I’ve always felt that tension within myself and I find myself switching often. I’ve increasingly grown uncomfortable with pure business analysis. I’ve found it disconnected from the enterprise objectives and how the enterprise seeks to create value. That disconnect has frustrated me and continues to do so increasingly. Lately, I have felt that there was more value I could give to an organisation, rather than performing siloed analysis.
I have been lucky enough to be mentored by a friend, James Gibson, an enterprise architect. From early on in my career (which is only five years old) I’ve been lucky enough to learn about the shortcomings of conventional IT-centric frameworks. James taught me about concepts such as patterns, metamodeling, SPEM and BMM. Many a time, after a conversation with James, I would have to go and do lots of reading to understand why he said the things he did, but the grounding it gave me was worth it.
Tension often comes in the frustration as you try and explain ideas to people who haven’t the breadth of background to understand where you are coming from. I find tension comes too when you are trying to simultaneously enforce a standard and realise its limitations to one domain. UML is a great example of this. It’s a language for communicating various facets of a system (not necessarily IT-based). However it’s not good for communicating a business model. So while you’re trying to get people to write well formed activity diagrams, rather than randomly arranged boxes on a page with no formality to it, you also have to recognise when UML is no longer useful. I find myself treading this line often.
Increasingly I find myself reading, writing and learning about the domains of enterprise business analysis, business architecture, IT investment management, programme management and enterprise architecture. Those are the domains I would like to do my everyday work in eventually, however I’m not there yet.
The Business Case for the Advanced Generalist Business Analyst (Part I)
There are a number of industry trends that are pointing towards an increased importance for people to be able to contribute and guide enterprises at the more strategic level. The recently released Draft Vision for Australian Government use of ICT signalled a shifting emphasis within the Australian Government from controlling costs to ensuring that Government agencies focus on value. For a long time John Thorp has been stressing the importance of benefit analysis to successful IT-enabled investment. Early in 2011 the OGC published their Management of Portfolios (MoP) framework to tie together the underlying work of the project and programme. MoP is a methodolgy for investing in the right change initiative and balancing the organisation’s appetite for risk. Business analysts often have the right skill set needed to work with key stakeholders to facilitate the setting of direction and priority of enterprises to contribute to the creation of enterprise value more effectively. The International Institute of Business Analysis (IIBA) is starting to recognise the part business analysts can play in this creation of value through the identification of an advanced generalist competency within their third version of the Business Analysis Competency Framework. An advanced generalist business analyst applies their business analyst skills at a more strategic level than a senior business analyst.
This post begins a series that outlines the business case for advanced generalists. This post will concentrate on the objective of programmes – creating business outcomes and what has to be managed to ensure organisations achieve those objectives: benefits, project interdependencies and structured change.
Image adapted from The Information Paradox and John Thorp. This diagram shows the relationship between projects, programmes and portfolios.
I want to emphasise that this post isn’t an attempt to invalidate the valuable work performed by business analysts on projects. Project based business analysis is vital to the success of both projects and programmes of work. I’m not suggesting within this post that this important work is neglected. However there is a need for project work to contribute more than just a capability. The capability needs to be utilised by an enterprise and deliver business objectives.
Business Objectives
There are many names for the intermediate outcomes (intermediate within an enterprise wide perspective) that programmes achieve. From the reading I’ve done, there appears to be a lack of consensus as to what this term is. I’m referring to it as a business objective. This distinguishes the term from a benefit which is important to programme management, but ultimately isn’t the defining end-goal of a programme. It is also aligned to the Business Motivation Model (BMM). The BMM defines an objective as:
An Objective is a statement of an attainable, time-targeted, and measurable target that the enterprise seeks to meet in order to achieve its Goals.
Business Motivation Model Version 1.0, OMG, 2008
It also aligns with the OGC’s Managing Successful Programmes (MSP). MSP defines an objective as:
The result of change, normally affecting real-world behaviour and/or circumstances; the manifestation of part or all of the new state conceived in a programme’s Blueprint.
MSP 2007 Glossary of Terms – English
© Crown copyright 2007. Reproduced with permission from OGC
A Programme’s Relationship to Projects
A successful project is the result of the management of the triple constraint to produce a capability. This is either a new capability for the organisation or a refinement of an existing one. It’s how these capabilities are used that is important. It is the role of the programme to define how the capability is implemented to achieve a business objective. As seen in the diagram above, a capability creates a business objective.
Managing Benefits Realisation, Project Interdependencies and Structured Change
Benefits realisation, project interdpendencies and structured change aren’t constraints that a programme’s team should manage. However they are important to a programme’s success. These aren’t the sole responsibility of a business analyst to define, rather they are the responsibility of the programme team as a whole. When you think that programmes are made up of multiple projects, that programme team becomes rather large. Interdependencies between projects make the information sharing needed amongst the programme team very complex, very quickly.
The Senior Responsible Owner is looking for the programme to deliver benefits. Benefits are also defined in the MSP glossary, “a measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders”. Benefits management – identifying, defining, baselining and realising – forms one of the core aspects of programme management. A business analyst working at the programme level will be integral to liaising with the business and teasing out the benefits. The elicitation skills that at a project level are used to gather requirements, may be used to identify relevant benefits and define them. From here qualitative and quantitative analysis skills are needed to classify benefits as either tangible or intangible and if possible, to baseline them.
Structured change management is a discipline in and unto itself that was pioneered by the organisational psychologist Kurt Lewin. Elements of this discipline are relevant to programme management, which is often about achieving structured change within an enterprise. A programme can also be emergent too, so it’s not always about change management. An emergent programme comes about when multiple separate projects are identified as having interdepencies, and a decision is made to manage them holistically as a programme.
It’s obvious that in an IT-enabled programme of this level of complexity, numerous business analysts would be needed to undertake the requirements analysis. However there would need to be a coordinating business analyst role undertaken by a business analyst. That business analyst should meet the competencies of an advanced generalist business analyst.
The Advanced Generalist Business Analyst
According to the Business Analyst Competency Model 3, the advanced generalist business analyst performs similar tasks to a senior business analyst, however it is generally higher in the organisational heirarchy, interacting with people at a more senior level and dealing with a higher amount of complexity and ambiguity. “These profiles require an advanced demonstration of many Underlying Competencies [Underlying Competencies refers to the corresponding chapter within the BABOK] to effectively perform. Advanced demonstration of an Underlying Competency is seen through the context the competency is used; the behavioural indicators remain the same, while the context in which the indicators are demonstrated becomes challenging for effective performance”.
In this case, the context is working with a team of business analysts, the programme manager, managers of the underlying projects and the senior responsible owner. This requires the person in the role to have mastered most or all business analyst skills and be able to build an effective working relationship with stakeholders internal and external to the programme. As suggested above, this is familiar to a practiced business analyst. However the context and the responsibility may not be familiar to all business analysts. It is as the competency indicates, the next level up from a senior business analyst.
A lot of the tasks that an advanced generalist business analyst working at the programme level may be undertaking are defined in the Enterprise Analysis knowledge area of the BABOK version 2. This section of the BABOK outlines tasks that set the context for the requirements gathering work. Some of the most important tasks are identifying the business need and constructing the business case. Some of the specific tasks that need to be performed by a business analyst within this context aren’t identified within the current version of the BABOK. It would be nice to see future versions expanding on this skill set. Some of the specific tasks that a business analyst might perform are:
- Assisting the programme manager to create and maintain the programme blueprint
- Assisting in the creation and ongoing maintenance of the programme business case
- Responsibility for benefits management. This include benefits diagramming techniques such as benefits mapping, Investment Logic Mapping or Results Chains.
Future posts in this series will expand on the skills needed at the programme level by advanced generalists. The context of advanced generalists working at the portfolio level will also be examined.
