components

Wardley Maps

Peter Cripps architecture , , ,

A Wardley map (invented by Simon Wardley who works for the Leading Edge Forum, a global research and thought leadership community within CSC) is a model which helps companies understand and communicate their business/IT value chains.

The basic premise of value chain mapping is that pretty much every product and service can be viewed in terms of a lifecycle which starts from an early genesis stage and proceeds through to eventually being standardised and becoming a commodity.

From a system perspective – when the system is made up from a number of loosely coupled components which have one or more dependencies – it is interesting and informative to show where those components are in terms of their individual lifecycle or evolution. Some components will be new and leading edge and therefore in the genesis stage whilst other components will be more mature and therefore commoditised.

At the same time, some components will be of higher value in that they are closer to what the customer actually sees and interacts with whereas others will be ‘hidden’ and part of the infrastructure that a customer does not see but nonetheless are important because they are the ‘plumbing’ which makes the system actually work.

A Wardley map is a neat way of visualising these two aspects of a system (i.e. their ‘value’ and their ‘evolutionary stage’). An example Wardley map is shown below. This comes from Simon Wardley’s blog Bits or pieces?; in particular this blog post.

Wardley Map 2

The above map is actually for the proposed High Speed 2 (HS2) rail system which will run from London to Birmingham. Mapping components according to their value and their stage of evolution allows a number of useful questions to be asked which might help avoid future project issues (if the map is produced early enough). For example:

  1.  Are we making good and proper use of commoditised components and procuring or outsourcing them in the right way?
  2. Where components are new or first of a kind have we put into place the right development techniques to build them?
  3. Where a component has lots of dependencies (i.e. lines going in and out) have we put into place the right risk management techniques to ensure that component is delivered in time and does not delay the whole project?
  4. Are the user needs properly identified and are we devoting enough time and energy to build what could be the important differentiating components for the company.

Wardley has captured an extensive list of the advantages of building value chain maps which can be found here. He also captures a simple and straight forward process for creating them which can be found here. Finally a more detailed account of value chain maps can be found in the workbook The Future is More Predictable Than You Think written by Simon Wardley and David Moschella.

The power of Wardley maps seems to be that although they are relatively simple to produce they convey a lot of useful information. Once created they allow ‘what if’ questions to be asked by moving components around and asking, for example, what would happen if we built this component from scratch rather than try to use an existing product – would it give us any business advantage?

Finally, Wardley suggests that post-it notes and white boards are the best tool for building a map. The act of creating the map therefore becomes a collaborative process and encourages discussion and debate early on. As Wardley says:

With a map, it becomes possible to learn how to play the game, what techniques work and what failed – the map itself is a vehicle for learning.

Is “Architect” a Job or a Role?

Peter Cripps architecture , ,

This is one of the questions posed in the SATURN 2011 Keynote called The Intimate Relationship Between Architecture and Code: Architecture Experiences of a Playing Coach by Dave Thomas. The article is a series of observations, presumably made by the author and colleagues, on the view of architects as seen by developers on agile projects and is fairly damning of architects and what they do. I’d urge you to read the complete list but a few highlights are:

  • Part of the problem is us [architects] disparate views from ivory tower, dismissal of new approaches, faith in models not in code.
  • Enterprise architect = an oxymoron? Takes up so much time.
  • Models are useful, but they’re not the architecture. Diagrams usually have no semantics, no language, and therefore tell us almost nothing.
  • Components are a good idea. Frameworks aren’t. They are components that were not finished.
  • The identification of high-value innovation opportunities is a key architect responsibility.
  • Is “architect” a job or a role? It’s not a job, it’s a role. They need to be able to understand the environment, act as playing coaches, and read code.

Addressing each of these comments probably justifies a blog post in its own right however I believe the final comment, and the title of this post, gets to the heart of the problem here. Being an architect is not, or should not, be a job but a role. Whatever type of architect you are (enterprise, application, infrastructure) it is important, actually vital, to have an understanding of technology that is beyond the words and pictures we use to describe that technology. You occasionally need to roll up your sleeves and “get down and dirty” whether that be in speaking to users to understand their business needs, designing web sites, writing code or installing and configuring hardware. In other words you should be adept at other roles that support and reinforce your role as an architect.

Unfortunately, in many organisations, treating ‘architect’ as a role rather than a job title is difficult. Architects are seen as occupying more senior positions which bring higher salaries and therefore cannot justify the time it takes to practice, with technology rather than just talking about it or drawing pretty pictures using fancy modeling tools. As discussed elsewhere there is no easy path to mastering any subject, rather it takes regular and continued practice. If you are passionate about what you do you need to carve out time in your day to practice as well as keep up to date with what is new and what is current. The danger we all face is that we can spend too much time oiling the machine rather than using the finite number of brain cycles we have each day making a difference and making real change that matters.