Some More Burlton Business

12th of August 2016

The BPTrends blogs are a long time favorite of mine to follow for their wealth of information shared by experts on the discipline of BPM. However the digest of July 2016 which dropped in my mailbox last week has been a veritable bonanza. No need for a secret password Ali Baba style to open up this treasure trove, you just need the time to go through all the blogs and absorb as much as you can handle. My personal favorites were the post of Roger Tregear on the role of process owners and the post of Shiva Nadarajah and Atul Sapkal on the capability map. However, the recurring blog about business architecture by Roger Burlton will be the focus of this post.

As indicated in a previous thought, I love how by writing it down, he is revisiting his ideas on how to tackle business architecture and the models associated with it. Compared to the previous diagram, the positions of Business performance indicators and Business Capabilities have been switched around in order to stress with more force the tight alignment between the Capabilities and Business Processes.

Before diving into his blog on stakeholder needs and expectations, I will make the same slight detour he made in his series of blogs and do a quick perusing of his blog on the Business Architecture Landscape. This article is a general frame in which to place the other articles he will write during the series, but does highlight some interesting points for my understanding, with the statement “Associate, do not Integrate” (reminiscing of Hammer’s famous statement). With this catchphrase he emphasizes that there is no inherent hierarchy between architectural domains, giving the example that processes, capabilities and rules are associations and not subcomponents of each other. This is a refreshing point of view considering architects (and other IT disciplines) are often plagued by the “centre of the world” sentiment.

The second part of the blog takes his views (and principal statements) on Business Architecture and puts them to the test within several popular models: Osterwalder’s Business Model Canvas, Zachman’s Enterprise Ontology, the Business Architecture Guild BIZBOK, and his own Burlton Hexagon. An interesting read, but it does trigger my pet peeve with the Zachman Ontology again. I find it a more than decent way of thinking, but I have issues with the “Where” and “When” columns, which to me are always concrete, and don’t quite fit with the rows introducing levels of abstraction.

Coming back to stakeholder inspection, Roger Burlton defines the stakeholder section of his model to encompass the responsabilities of the stakeholders first and foremost:

  1. They influence the formation of the Strategy
  2. They establish the basis for the Strategic Goals
  3. They provide the interactions with the outside world and structure of the business processes
  4. They provide the Value Performance Indicators and Targets

To me, the underlined statement of the third point is a critical of any stakeholder analysis. We must draw up a representation of the ecosystem in which our organization is situated (customer segments, suppliers, regulatory organs…) in order to have a check on the exhaustiveness of our stakeholder list. Each of the components in this ecosystem diagram is a potential (and more than likely) stakeholder for the processes and business architecture to be modeled. In fact, the blog post clearly states a similar phrase: “The first thing to do is to structure the stakeholder types that we serve”.

The questions that govern stakeholder analysis according to Burlton are the following:

  • Who are the stakeholders of note? Who cares and who do we care about?
  • What tangible or virtual exchanges do we have with them?
  • What expectations do we have of them and them of us? What value and experience is expected by both parties?
  • What measurement indicators can be used to evaluate performance, and what are the gaps between current state and future objectives?
  • What aspects of the relationship are unhealthy?
  • What are the required capabilities for relationship success?

For the first question he proposes to start from a list of the generic stakeholder types, most of them are to be expected. I do like the Overlaps and Oddballs type for those stakeholders with conflicting roles. The type “competitors” is a bit narrow for my tastes. I usually define a broader category named negative stakeholders, as they can oppose the success of the project for different reasons, not just for competition’s sake. I’ll post here an excerpt of my white paper on Solution Architecture detailing my view on stakeholder modeling:

To model the stakeholders and their interaction with the project, one can write large texts of prose as to how they would impact the project. However, a visual representation says so much more than thousand words, so we need to come up with a taxonomy to describe these groups of people and their goals for the project, be they either beneficial or hindering. A way to describe this, is to make use of the Onion Model. Stakeholders are attributed to a circle in the model of which these are the default circles:

  1. ‘The Product’ or ‘The Kit’: the item under development, e.g. a software program, a consumer electronics device, an aircraft, a communications network.
  2. ‘Our System’: ‘The Product’ plus its human users and the standard operating procedures or rules governing its operation.
  3. ‘The Containing System’: ‘Our System’ plus any human Beneficiaries of Our System (whether they are involved in operations or not).
  4. ‘The Wider Environment’: ‘The Containing System’ plus any other Stakeholders.

Other circles may be introduced as necessary. The different influences that the stakeholders exert on the project, can also be mapped onto the onion model, as shown on the model to the right, which is an example for the development of a computer game. This way, the lifespan of stakeholder involvement can also be taken into account, giving an indication to when and why a certain set of requirements (linked to an emerging or leaving stakeholder group) will diminish or heighten in importance.

  

The next question about the exchanges is already partly answered in my onion diagram above (arrows indicating the pressure lines). Here we elaborate on the different exchanges in the context of the value chain (products, services, information exchange, knowledge exchanges…) . Burlton proposes doing this per process in the scope of the current exercise. However, for me, this starts once again from an organization’s ecosystem where these exchanges are first mapped to those stakeholders outside of the organization before doing the analysis per exchange. This gives us a clear checklist for analyzing needed processes and services in order to check for completeness of the current exercise.

The question about expectations adds a deeper level of detail to the already mapped exchanges, and the question of measurement indicators plays to the adage of “what you can’t measure, you can’t manage” and gives a way to measure success and the links to strategic initiatives and goals. The health aspect of the exchanges can be color coded into your chosen way of modeling, and the author even suggests that you might employ Ishikawa diagrams to detect and flesh out this indicator per exchange or group of exchanges.

Last point for the exchanges: Once we have the requirements for these exchanges and how to monitor their health, a fit/gap analysis needs to happen in order to determine which capabilities are still needed within the organization to support these findings.

Once again, a very interesting blog post of Roger Burlton, and still a series I will follow up closely.

Thought BPM Business Architecture