Wardley Mapping in Enterprise Architecture (also, upcoming workshop)

A little while ago, we ran a very well received webinar with Simon Wardley presenting the essentials of his innovative mapping approach.

We have been working to integrate this into our enterprise and business architecture meta models and approach. Early results are encouraging. We have found the following:

• Maps can be thought of as similar to graphical models, but with axes that facilitate placing elements in spatial dimensions (specifically how close to the delivery of value / visibility to client they are (Y axis) VS how evolved they are in terms of how they are delivered (X axis). This means we can easily adapt existing graphical models and tools to also have axes and support maps

• The elements in the maps range from Customers (one subtype of Stakeholder), through Products and Services (Offerings), the elements necessary to deliver these (e.g. Processes, Systems) and those supporting them (e.g. Technology, Data). The good news is that these are already included in our Holistic Architecture Language meta model and have associated visual representation. We can use our existing ones or just dots as preferred

• The idea of evolution fits well with our existing concepts of Maturity Level for various elements and capabilities

Bottom line: Mapping fits very well and provides additional value by allowing identification of trends and potential scenarios. It also allows visual grouping that helps planning in terms of suitable methods, responsibilities and timing.

We are holding an initial one day workshop on leveraging mapping within architectures for those who would like to dig deeper…

See this page for more information on the Wardley Mapping for EA Workshop

Forthcoming: Academic Paper on Integrating Wardley mapping with EA

Image Credit: Simon Wardley

Annotation: Graham McLeod

Positive Risk? Should we take more risk? If so, why?

Watching Rory Sutherland, I saw an example where avoiding a small risk eliminated a major innovation opportunity.

As a one-man plumber, we must do each job well and follow proven best practices to avoid reputational damage and future business harm. The cost of a botched job is significant and may harm our cash flow. We’re likely risk-averse.

As a larger plumbing enterprise, we can spread risk by allowing one plumber to try a new approach. If the job fails, it won’t significantly impact our cash flow since other plumbers are operating normally. Even if we have an unhappy client, the other 19/20 or 95% will still recommend us, so our reputation is high. If we address the issue, we can restore 100% satisfaction.

By spreading risk across the organization, we can make it relatively small. If the new approach is successful, it can save us 20% effort on similar jobs, increasing our margin or profit and recurring over time.

We can divide risk (limited to one job and one client) while multiplying benefits by team size and job frequency. However, we must define success (e.g., client satisfaction and time or resource savings) and measure these. If the innovation fails, we must stop doing it.

If we want to limit the downside further, we can partner with the client where we intend to try it. Many will accept some risk if we pass on the savings or benefit. They’ll also tolerate problems or glitches more happily if they’re informed upfront.

Taking this into account, we need to be more tolerant of taking controlled risks and bringing in innovation, especially in large organizations.

The graphic shows a concept we introduced two decades ago for bringing innovation into an organization in a controlled way. A small number of innovators try out new things that may be beneficial. For those that are, they create proofs of concept and do some organizational learning, distilling how we can usefully use the technology or approach. The methods group translates their learnings into how these would be applied in the organization at scale and trains the operational teams in how to apply them. The operational teams apply what they’re taught and measure the results, feeding back to the methods group. This way, we exploit the effects of innovation - large infrequent gains, sometimes through radical change, while limiting the negative effect of taking the whole organization through a learning exercise and drop in productivity. The cycle of improvement, application, measurement, and improvement between the operational and methods groups exploits the principles of Kaizen, viz. small continuous incremental improvements, leading to high quality and efficiency.

Be a force for good

Give me a place to stand and a lever long enough..

and I will move the world. So said Archimedes, apparently.

When we train you as an architect, particularly a business architect, we are giving you a long lever (= much power). We also hope to give you some solid principles and moral grounding as a place to stand. Architects are change agents.

Be a force for good.

For each change that you propose, ask:

• Which stakeholders will this impact positively? How? To what extent?

• Which stakeholders (and potentially other parties) will this impact negatively? How? To what extent?

• Then try to maximise the good and minimise the harm

• Apply systems thinking to anticipate consequences

• Ensure we are thinking long term and that proposed approach is sustainable

• Try on a small scale (think MVP, prototype, etc. ) to prove concept, benefits, identify negative impacts

• Iterate and improve or pivot before scaling up. Scale when benefits are being realised

• Design and adjust metrics to get desired behaviour

• Involve everyone affected (or at least their representatives) in the design of the future. Those closest often have knowledge that we don’t. They have history of what has been tried. They have ideas to contribute. They need to be on board to help make the change. If roles are affected or eliminated, people need better and significant roles to play going forward.

Dealing with Change

We probably all feel a little battered by the levels of change we are experiencing. Technology, pandemic, business models, social mores, ethics, sustainability, legislation and more. It is hard to retain our sense of perspective and balance and self worth when everything seems to be shifting around us!

As architects we are often the agents of change for the organisation, processes, products, systems and technology. But that does not mean we ourselves are always that happy with change! The threat is that it brings risk: Are we focussing on the right things? Are there new factors we aren’t aware of? Is our “known good solution” still relevant?

I find comfort in Jeff Bezos approach which advocates:

“Find what is not going to change and optimise for that”

He recommended, in the case of Amazon, that the following factors were unlikely to change:

• Customers want cheaper prices

• Customers want fast delivery

• Customers want increased selection

And in the case of Amazon Web Services:

• Customers want reliability

• Customers want low prices

• Customers want rapid innovation in adding APIs (increasing utility of the platform)

Find the things in your business / industry that will not change and optimise for them.