EBA and the Program Office

I recently had a chance to look into the detail of the P3O work being done by the Office for Government Commerce here in the UK. Now, while I don’t agree with everything they propose as best practice (more on that in another post) it did clarify something that I’ve instinctively felt for some time – architecture is a sub-set of the program office (PO) function.

That isn’t really the point behind this post though; the point behind this post is to explore why, when I mentioned this to some fellow architects, I got so much negative reaction:

  • You’re kidding, right? Architecture is about long-term planning, PO is about day-to-day reporting and delivery
  • No way. Architecture is about functions and capabilities, PO is about schedules and resources and stuff like that

Well, I’m sorry, but if you don’t believe that architecture is about delivery and if you believe that PO is only short-term then you’re doing at least one, and probably both of them, wrong!

Let’s take a look at what P3O aims to achieve (from their website):

  • Informed senior management decision making on strategic alignment, prioritisation, risk management, optimisation of resource etc to successfully deliver their business objectives (portfolio management)
  • Identification and realisation of business outcomes and benefits via programmes
  • Successful delivery of project outputs that enable benefits within time, cost and quality restraints.

Now, as a manifesto goes, I can sign up to that without much disagreement, but let’s break it down a bit. The first bullet cannot be achieved without a strong architecture function, especially as regards strategic alignment and business objectives. The second bullet also has strong links to the road-map and, therefore, strong links to the architecture function. The third bullet has perhaps weaker connections to the architecture function but still has links to selecting the right scope and the right solution.

But, and this is the clincher for me, look at how many times there is reference to “delivery”, “outcomes”, “benefits” and “objectives”. If our role as architects is to ensure the delivery of the right thing at the right time for the right cost – and if the best way of doing that is to plan, monitor and control the change road-map – then how can we not be part of the PO? How can we not be part of shaping and delivering the change agenda?

Maybe this is just my particular philosophy on things. Maybe it shows through in my post about process and people elements of an EBA function. But I truly believe that unless you are getting your hands dirty and are actively plugged into the mechanics of delivery you are not doing your whole job.

Posted in Controversial, Philosophy of EBA | Leave a comment

Functional Dependency Map

Edit: We’re currently reviewing our FDM to see if it can be improved.


How can you ensure that your road-map of projects stays robust and on target to deliver against your strategy? The one thing we can be certain about is that our road-map is in a constant state of flux. Schedules change, scope flexes, new projects are added and existing projects stopped. How do you help ensure delivery against your target architecture?

A good starting point is your knitting pattern but that only tells you that there is a potential dependency between two projects – it doesn’t tell you the nature of the dependency. A Functional Dependency Map (FDM) expands on the knitting pattern to give you more information about the links between your projects.

What does an FDM look like?

In this example, we already have two projects on our road-map: project 2 is enhancing your customer data store to provide support for corporate customers; project 1 is building some automation to create a customer record on demand. You’ve already established that there is a dependency between these two using your knitting pattern and the functional dependency map makes that explicit. Project 1 has a dependency on project 2 if your automation is going to be able to create corporate as well as retail customers.

Functional Dependency Map image

Project 3 has just been initiated to provide online support for retail customers and part of that is to allow retail customers to sign up for an account online. Project 3 is dependent on the automated account creation being built by project 1 and, therefore indirectly, on the corporate customer build in project 2. You probably could have seen the first dependency quite easily, but the FDM also exposes these chains of dependencies. You can know see that any delay to the corporate customer build could affect your online retail customer build.

So, if that’s what an FDM looks like how do you use it?

Use case 1 – Get your projects talking to each other

If there are cross-project dependencies, then your analysts need to be talking to each other to ensure that their requirements and design are consistent and build towards the end goal. Also, your project managers need to be talking to each other about schedule – does the later delivery need to wait until the earlier delivery is in production or is a firm design enough to start with? Your test and deployment guys also need to be thinking. Should these be tested and deployed separately or can they be done together to accelerate value delivery for the business?

Use case 2 – Adjusting your road-map

Road-maps change for three reasons: addition of a new project; stopping an existing project; or change to an existing project (e.g. scope or schedule). Any one of these changes can have knock-on impacts to other projects on your road-map. The FDM allows you to quickly identify those knock-on impacts. If you’re stopping an existing project was that project delivering something that another project is dependent on? If an existing project is slipping what does that do to the schedule of dependent projects? If you’re adding a new project, what new dependencies are you creating?

Use case 3 – Program level risk and issue management

Most change delivery teams are pretty good at managing risks and issues at the project level. Where things start to get a little flakier is at the program level. We’re all aware of the concept of a critical path for projects but how often have you seen a critical path for a program? An FDM is not strictly a critical path for a program since it doesn’t include schedule, however, it’s quite close to one; and if you do find yourself using it for that purpose there is nothing to stop you adding schedule information to the FDM provided you’ve got a mechanism for keeping it up to date.

Clearly, there are other dimensions to all these decisions – not least code, environment and resource contention – but unless you have a clear picture of the functional dependencies on your road-map, you don’t have a robust road-map.

Posted in Delivery Mode, Techniques | 2 Comments

Processes are NOT part of a business architecture

Well, there you go. I promised you some controversial views on this blog and here’s one of them. I believe that processes are NOT part of a business architecture model and here’s why.

I strongly believe that business architecture models need to be as light weight as you can possibly make them while still achieving the objectives assigned to the business architecture team. There are two reasons for this belief:

  • A lighter weight model facilitates faster responses to questions from the top table – almost by definition the fewer artifacts you have to impact the faster your response can be;
  • A lighter weight model provides business architecture benefits at a lower TCO (Total Cost of Ownership) – the more detailed your architecture models are the more they cost to maintain their currency.

Including processes within your architecture adds disproportionate weight to your architecture models in comparison to the architectural value you gain, while at the same time slowing your response to questions from the top table. What causes the added “weight”?

  1. Processes are low level – they deal with all the sub-activities and all the decision points
  2. Processes are physical – they have multiple physical implementations in order to achieve a single logical outcome
  3. Processes change often – most businesses are achieving small incremental productivity improvements by changing processes almost continually

Dealing with the first point, do you need to know the detail of “how” the business does something or are you more focused on what it needs to do and the parameters within which it needs to operate? As an example, which question has the higher architectural value: how do we take orders? or, can we handle taking 1,000 orders per month per operator at a cost of less than 5 cents an order? In both cases we need to understand something of the process but we don’t need a full process flow to understand the second question.

The second point really compounds the problem of the first point. You will find multiple physical implementations of the same logical process  for valid reasons – identifying a customer logging on to a web app will use a different process to identifying a customer who’s called you on the phone. Sometimes it’s valuable to recognise these differences in your architecture; sometimes not so much. If you are including processes in your architecture, you don’t have a choice – they all have to be recognised and modelled.

The final point comes back to the maintenance overheads of dealing with changing processes. I have seen one company whose philosophy is “If it can’t be done with SAP then we don’t do it” but I think this is the exception that proves the rule. In practice, most companies are continuously tweaking their processes to gain small incremental advantages and you will be hard-pressed even to keep a track of all these changes let alone maintain your models currency. By the way, this is also ignoring shadow organisation effects where the documented process may not change but the actual process sure does!

Convinced yet? “Well, sort of. But surely we still need to know what the business needs to be able to do?”. Sure we do, and this is the crucial distinction. As architects, we need to know what the business needs to be able to do, but we are less interested in how the business actually does it. This to me is one of the key benefits of business capabilities.

A business capability sets out, at various levels of granularity, what a business needs to be able to do. Some of those capabilities may be decomposed into sub-capabilities e.g. Send Communication may be comprised of Compose Communication and Fulfill Communication. For some of those capabilities it may also be useful to distinguish different physical implementations of the same logical capability, for some capabilities not so much. Some capabilities need to have parameters, goals or targets which map back to the strategic goals and each capability can be associated with target parameters.

However, at no time do these capabilities dig into the detail of how exactly those capabilities are delivered. This provides you as an architect with a rich framework within which to focus on what the business needs without having to worry about the in-depth detail of the how.

A challenge has been thrown at me that “Surely this doesn’t apply when the focus of the architecture effort is about process standardisation. Surely, then you need to know the detail of the how?” Even in this situation, my stance remains the same – from an architecture point of view you don’t need to know the how. In fact, focusing excessively on the how can actually detract from the bigger picture view of standardisation.

From an architecture point of view, your focus is to decompose the overall process components into a series of reusable, flexible, capability components that can then be individually standardised going only to the level of physicality that you need to. What is architecturally important is that you have a standard component – what that capability does inside the black box is a question for business analysis not business architecture.

I stand by my view, processes are NOT part of a business architecture; capabilities very definitely are.

Posted in Controversial | Leave a comment

Business Architecture Briefings – Getting off on the right foot

So an idea has been floated, somebody has approved some more work on it, you’ve made sure that you were involved in shaping the idea, some cost benefit analysis has been done, we’ve had a look at the road map and decided that there is a new project to be commissioned.

Program office is busy working on the paper work and the resourcing, the newly assigned project manager is working on his PID and business case and you need to be working out how you are going to ensure that this project delivers to the architecture road map. How best to do that?

Well, apart from updating your knitting pattern and your functional dependencies map, one thing you may want to consider is a Business Architecture Briefing (BAB). I’ve used a BAB to sit alongside the PID and business case as a key project initiation document and it really focuses on 5 main issues:

  1. Strategic value
  2. Functional dependencies
  3. Outline solution
  4. Scope bounding
  5. External value/dependencies

The first element of the BAB addresses why we are doing this project. You can use the contribution to strategy ratings if you’ve chosen to use that technique or just use some narrative if not. The importance of this section is that it can be used to inform later, harder decisions about scope and solution – which trade-off will deliver best against the strategic value?

The second element works off your knitting pattern and highlights any areas where the analysts on the project need to be talking to analysts on another project to ensure that the overall road map delivers.

The third element is where you get the maximum ability to steer bang-for-buck. Do you need a Rolls Royce solution to a particular requirement or will a Reliant Robin suffice? Is a system solution required or should you be looking at a process based solution? How does the whole solution hang together to deliver the entirety of the business need?

The fourth element follows on from the third. Implicitly, your outline solution states what is in scope but you may want to use this section to be more explicit about “in scope” depending on the project. More importantly, this section gives you the opportunity to state what is explicitly out of scope.

The fifth, and final, element depends on whether you are responsible for the architecture of an entire organisation or a business unit within one. If it is the latter, then there may be organisation wide value or cross business unit synergies or dependencies that you need to highlight.

To summarise, the BAB addresses: why the project is being done; how it fits into the road map; what the solution looks like; what is in and out of scope; and how the delivery fits into the “meta environment”.

Who should receive get a copy of the BAB?

  • The sponsor (Mandatory) – Even if only for the strategic contribution bit. However, I have had feedback that sponsors find this to be the most useful of all the documents that the project machinery delivers.
  • The business project manager (Mandatory) – They need to know where you stand right from the outset and have the opportunity to debate and discuss with you. Remember, the PM will deliver your architectural dreams!
  • The business analysts (Mandatory) – These are the guys that will take your high level vision and turn it into a lower level reality. They need a clear picture of the vision and I would recommend a meeting to walk through the BAB with the business analysts in detail.
  • The IT architects (Mandatory) – You are setting out your stall on what your business demands are and the IT architects will need to deliver to it. My strong recommendation here is that you not only send them a copy but involve them in developing the outline solution.
  • The business test manager (Recommended) – While not strictly necessary, the BAB has key information that will inform the scope of the business acceptance test phase and any risk-based testing.
  • The IT project manager (Recommended) – Again, not strictly necessary, but the context is likely to be useful.

You can add additional people to the distribution as you see fit and depending on your particular circumstances e.g. subject matter experts, IT test managers, work package managers. When it comes to onward transmission within the IT side I tend to rely on the discretion of the IT architects and delivery managers.

Key Take Away: A Business Architecture Briefing document is a technique to help ensure that everybody involved in a project is “on message” right from the start.

Posted in Techniques | 1 Comment

Capabilities and your roadmap

So, you’ve got your list of projects, you’ve prioritised them for strategic value-add, you’ve scoped the program and projects to fit the change budget, you’ve arranged the schedule so that you can resource them all, you’ve re-arranged the schedule to avoid code and environment contention (that was a painful discussion with the top table wasn’t it?). You’re good to go right?

Whoa, Neddy, hold your horses for a minute.

What about your functional dependencies or conflicts? Do you know whether multiple projects are making changes to the same process, data, business unit or customer interaction? Do you know whether multiple projects are delivering incremental enhancements to any of the above and, if so, in which order they should you deliver them – one may be dependent on the other.

I can hear you now “But surely, I won’t know that until I know what the requirements are – and I won’t know what the requirements are until I start the project!”. This is true for a given definition of true. There is always a risk that project conflict on the functional level will emerge as projects progress. And, as we all know, rework and rescheduling is the biggest cause of project overspends by far. It’s also true, that functional conflicts can be predicted by using your capability model. If we can predict functional conflicts our stakeholders will expect us to do so.

Enter the “knitting pattern”…

Project 1 Project 2 Project 3
Business Capability 1 * *
Business Capability 2 * *
Business Capability 3 * *

This is a very simple example but it should be enough to illustrate the principle. We have three projects on our roadmap making changes to three capabilities and we have three instances of more than one project affecting the same capability. Immediately we should be asking questions: Are the requirements for each capability change aligned/consistent? Are there any dependencies? At the next level down, are there likely to be code contentions?

Like most business architecture techniques, the knitting pattern doesn’t give you the answer but it does illuminate the questions. You need to understand what projects 2 and 3 are aiming to do with business capability 1 and make sure that your road map still holds up. Are the changes conflicting or are they supportive? If they are conflicting how are you going to resolve the conflict? If they are supportive, is there a logical order in which they should be delivered? Even if they are supportive, the first project needs to be aware of what the second project will be trying to achieve so that the design of the first project will support the delivery of the second.

The same goes for business capabilities 2 and 3.

This is one of the areas where a business capability model really comes into its own. The fact that business capabilities are logical (mostly) means that you can work with a relatively small subset of your business architecture assets. You don’t care which systems, which processes, which data, which channels, which customers, which resources… the business capability model alerts you to a potential conflict which you can investigate.

I call it a knitting pattern because once you have 50-60 business capabilities and 20-30 projects on our road map the spreadsheet/table looks remarkably like a “knit one/purl one” knitting pattern 😉

Once you’ve got your knitting pattern sorted you are then in a position to take the next step with your Functional Dependency Map.

Take away: A knitting pattern comparing your business capabilities against projects helps you validate your delivery roadmap.

Posted in Techniques | 2 Comments

Diversity or divergence?

A key question for business architecture in my view. Definitions:

  • Diversity – a point of difference
  • Divergence – separation, division, variation, deviation

Architecture needs to support the diversity required by a business while controlling the divergence inherent in the people nature of a business.

The way you authenticate a customer will differ depending on the physical channel: phone; paper; web. The way you deal with corporate vs. retail customers are inherently different. These are examples of diversity that the architecture needs to support.

Different ways of logging work are likely to be divergent. Different authentication questions over the phone are likely to be divergent. Different systems for logging customer contacts are likely to be divergent. These are examples of divergence that architecture needs to control.

Why is this important? Because every point of difference within a business is a cost and a risk. Differences require the maintenance and enforcement of multiple processes; they require impact whenever any change is contemplated; they present business risk of non-compliance or less than optimal efficiency or effectiveness.

Diversity requires a business case to support it. Divergence is rarely justified. Know the difference and act accordingly.

Posted in Philosophy of EBA | Leave a comment

Business capability meta-model

I know, I can hear the question now… “How can he be posting about meta-models when the whole reason for the blog is about delivering real-world, gritty value from EBA? How abstract can you get?” Well, I could say “There are such things as meta-meta-models, you know, just ask the people who designed UML!” but that would just be getting picky.

There are two real reasons I’m posting this technique:

  1. I find that capability models underpin so may other things I want to do with my business architecture that they’re important enough to put some focus on; and
  2. While there is a lot of buzz (quite rightly in my opinion) about capability models there’s not a lot of information out there about what they actually look like.

These posts aims to set out how you can build a business capability model that can be used to deliver real business value without the cost of consultants, excessive time or expensive tooling. Building the capability model will be the subject of another post but I will show you how to build a capability model yourself, in under two weeks and using free software!

Enough hype, on with the meta-model…

A basic capability model need only consist of 4 first class entities (3 if you choose to differentiate between primary and supporting capabilities in another way, see later):

  1. Primary Capability – The end-to-end, logical (mostly) response to an actor’s trigger that delivers the value the actor is looking for e.g. Handle Customer Enquiry, Fulfill Customer Order, Provide Regulator Filing etc.
  2. Actor – The person or entity to which the value is delivered e.g. Customer, Distributor, Regulator etc.
  3. Supporting Capability – A logical (mostly) capability that participates in one or more primary capabilities but does not deliver value in and of itself e.g. Take Order, Render Communication, Route Call etc.
  4. Category – A hierarchical “folder” structure for organising capabilities e.g. Sales Capabilities, Customer Capabilities etc.

I’ve also included a second class entity (Focus) that indicates whether the primary capability delivers value internally or externally. This could be inferred from the actor but I would recommend being definitive – external value delivery is far more likely to be a source of competitive differentiation than internal value delivery.

OK, time for a couple of notes…

  • You may well find that some primary capabilities “consume” other primary capabilities e.g. while handling a customer enquiry they may also place an order. This is allowed for via the “pig’s ear” recursive association on primary capability.
  • Based on the above and depending on your circumstances, you may choose to consider abandoning the differentiation between primary and supporting capabilities. My advice would be to think very carefully before doing so – the key differentiation between primary and supporting capabilities is a question of value-delivery not re-use.
  • Aren’t primary capabilities just value-streams by another name? – Absolutely, business capability theory builds on Whittle and Myrick’s work; it doesn’t replace it.
  • Logical (mostly) – Don’t get hung up on whether this is a logical or physical model. Keeping it logical means that you don’t need to differentiate, for example, between customer authentication over the phone, via web, or via post. However, keeping it totally logical could mean you miss, for example, a capability to bespoke content in the web-space via CMS. Mix and match logicality and physicality to meet your business’ needs not the models needs.
  • Use different category hierarchies for primary and supporting capabilities. Your primary capabilities are much closer to the business and it’s worth considering a business focused categorisation. Microsoft (yes, Microsoft!) have a good starting point with their Motion categorisation of level 1 capabilities. Your supporting capabilities are much closer to the IT realisation of capabilities and it may be worth considering a more functional or entity based categorisation of capabilities.
  • Granularity/physicality – Any model is a trade-off between accuracy and maintainability. Physicality and increased granularity increase the costs of maintaining the model but may provide additional insight. Logicality and reduced  granularity reduce the costs of maintaining the model at the risk of loss of insight. I can’t give you the answer to this one, but my advice is to keep maintenance costs as low as you can and only increase granularity/physicality when you need to.

So, that’s pretty much it for my meta-model and it boils down to a few simple rules:

  • Do differentiate between value-add and supporting capabilities;
  • Do focus on the customer to whom the value is delivered;
  • Do worry about the costs of maintenance vs. value of insight;
  • Don’t fret about whether it’s a logical or physical model or whether it’s a value stream or capability model; and finally
  • Do worry about how you are going to use it to deliver results.
Posted in Techniques | 1 Comment

Pro tip: Learn to speak CXO

One of my quirks is that I like to collect aphorisms about change and architecture. One of my favourites is “People don’t care how much you know until they know how much you care”. You can be the most brilliant architect ever, but if you can’t show the top table that you’re interested in solving the problems that are important to them, then it’s not going to get you very far.

As a business architect in particular, you need to understand the whole of your business from multiple perspectives. You need to be able to see the same issue from the perspectives of finance, operations, marketing, compliance, legal etc. And you need to be able to understand why they have the concerns that they do.

This is why you will commonly see a requirement for high level business architect roles to have an MBA. Now I don’t necessarily subscribe to that view but I can understand the rationale behind it. I do recommend getting a background in the following four areas: strategy; finance and accounting; sales and marketing; and operations and management.

How you go about doing it is clearly up to you and your learning style – courses, qualifications, books, wikis, talking to people are all valid options. If you have a look at my library page you can see which books I’ve found particularly useful.

Now I’m not recommending that you go away and learn all this stuff and them come back to the office spouting buzz words. That is an ideal way to prove yourself a self-important amateur! What I am suggesting is that you understand the concepts so that you can understand the thinking processes of your top table and can ask meaningful questions.

Knowing the link between the amount and sources of capital and the return on equity means you can ask intelligent questions of your CFO. Knowing what gatekeepers are and how they control routes to market means you can ask intelligent questions of your marketing director. Knowing that there is a “shadow side” to your organisation and how that is affected by leadership and culture means you can ask intelligent questions of your COO.

The realisation of your architectures will happen in a real world context and you need to understand that context and the multiple perspectives of your top table. If you can “speak their language” then you will get much better engagement from them and your architectures will be stronger.

Posted in Philosophy of EBA | Leave a comment

Contribution to strategy

A couple of questions we will be faced with as business architects are the following:

  • Should we authorise this new idea and start up a new project on the road-map?
  • One or more projects are in conflict; which one should we stop?

Now, there are various dimensions to these questions including (but not limited to): code or environment contention; availability of skilled resource; business case; and legislative or regulatory directives. However, there is another dimension that is less easily measured and that is “What contribution would this project make towards achieving our strategy?”

Now, that can be a difficult question to answer. Very few projects are mission-critical in the sense that the strategy cannot be achieved without them. Added to which, strategies tend to be multi-faceted so it’s not always clear which project should take priority if they are making contributions in different areas.  The technique I discuss below is one that I have used to address these types of issues.

Step #1 – Distill your strategy

Review your strategy and identify the key drivers. You need to get it down to 6 strategic drivers, preferably less. Those drivers should be approximately equal in weight but don’t sweat it if there are 1 or 2 make-or-break drivers that dominate the others. Talk to everybody at the top table to get a consensus that these drivers encapsulate the strategy. This last step is vital – you will be asking them to make decisions based on these criteria so they have to agree on the measures.

Step #2 – Decide on a measurement scale

The scale is arbitrary and you can have as many points on it as you like. At the top end, the rating means that the strategic driver can only be achieved if this project is delivered. At zero, this project has no impact on the strategic driver. Don’t forget to include a negative rating; some projects can actively work against achieving a strategic driver e.g. launching a new product when one of your drivers is cost reduction. A basic scale is -1 to 3 but you may want to extend the top range to 5 depending on your circumstances.

Step #3 – Review the projects on your road-map

You’re looking to rate each project with a score against each of your strategic drivers. Some of your projects may be so small that they’re not worth worrying about and that’s fine. You’re also looking to gather the latest estimate of cost to completion. This way you have a snapshot of each projects bang-for-buck strategy-wise. You can convert this into a measurement by adding the strategy scores and dividing by the cost if you like.

Step #4 – (Optional) Consolidate the results

Adding up the strategy scores for the individual projects can give you insights into what you are doing for your strategic drivers at an overall level – including the bang-for-buck strategy score. This can be helpful in a number of ways:

  • It may reveal under or over weightings against a particular strategic driver – this can be useful in aligning the overall change portfolio;
  • Publishing this to the change team can be helpful in two ways: firstly, communicating or reinforcing the strategic drivers; secondly, motivating people that they are making a real difference by working on their individual projects.

So, you now have your strategy contribution framework in place. How do we use it?

Use case #1 – Do we commission a new project?

Assessing a new project against the strategic drivers gives you an assessment (via the bang-for-buck score) of whether this project is worth doing on its own merits. This assumes that the change is a voluntary initiative and not mandated by regulation or legislation. If the bang-for-buck score is low or there are other warning signs (e.g. no strategic contribution or even negative strategic contributions) then the indicators are not good. On the other hand if the indicators are positive and we have the bandwidth to deliver it alongside the existing change portfolio then it’s looking good.

Use case #2 – Which project do we stop?

Code, schedule and resource contentions are normally the drivers behind having to make these decisions. Unfortunately, all they are able to say is “Pick one but I can’t tell you which”. This is where the strategy contribution framework comes into its own. It can directly compare apples and pears through the bang-for-buck strategy score. If they are significantly different then that’s a strong indicator.

If they are quite close then that’s when you bring into play the overall strategic contribution from the change portfolio. If one of the projects is contributing to under-weight strategic drivers compared to the other then that is a positive indicator.

Caveat: Sometimes the decision is made for non-strategic but perfectly logical reasons. Your MD or Sales Director may be betting that if they do this they can turn it to advantage later on “Yes, I know this is totally throw-away and of no value, but prospect ABC wants it and I think I can win the business if we do it”. This may not be overtly stated but be aware of it and run with it. Your responsibility is to advise, their responsibility is to decide.


A strategy contribution framework:

  • Allows you to compare apples and pears between any two projects;
  • Gives you a measure of bang-for-buck contribution to your strategy at a project and change portfolio level;
  • Helps you to decide whether to commission a new project;
  • Helps you to decide between two projects that are in conflict;
  • Can help motivate your change team.

PS: It can also get you extra brownie points if your boss uses this in her annual appraisal to demonstrate the value-add of the change team – as my boss did!

Posted in Techniques | 2 Comments

Strategy Mapping

For the purposes of this post I’m assuming you are lucky enough to work for a business unit that has a defined and published strategy. That’s a good start, but sometimes you need to kick the tyres a bit and dig underneath a bit to find out what that means for your job as an architect.

The technique I’m going to work through here is how to analyse that strategy to identify two things:

  1. Which elements of the strategy are mutually reinforcing; and
  2. Which elements of the strategy are conflicting.

Why is this important? Because there may be some elements of the strategy that reinforce multiple other elements of the strategy. Finding these elements and focusing on getting them right will give you a bigger bang for buck than developing an element that only reinforces a narrower element of the strategy. There may also be elements that are in conflict. Finding these elements and getting a steer from the top table will allow you (and them) to refine your understanding of the strategy and focus effort where it’s needed.

Joe’s Goods wants to increase their return on capital (ROC) to 15% and to penetrate the wholesale market. When asked how they plan to achieve the ROC target it turns out that a 15% reduction in debt and an reduced cost:revenue ratio of 25% will do the trick. When asked how they plan to reduce the cost:revenue ratio there are two elements. Area ABC is a cash cow that they think they can milk for more and use the proceeds to pay down debt. In addition, area XYZ has costs that the finance area believes are too high for the revenue they are bringing in. When asked about the penetration of the wholesale market, it turns out that this is almost exclusively XYZ products and they need to enhance their service offering.

The outcome of this analysis is shown in the picture below.

Two things to note from the above strategy map:

  1. Increasing revenue in the ABC area supports two of the other elements of the strategy – it’s very important!
  2. Reducing costs on the XYZ area supports the cost:revenue element but conflicts with penetrating the wholesale market by enhancing service.

This analysis has shown the architect (and the top table) where the real effort should be spent and highlighted the fact that there is a debate to be had by the finance and marketing teams about penetration of the wholesale market.

Good strategies will have a lot of mutually reinforcing elements (supports relationships); weaker strategies will have more conflicts (conflicts relationships).

Posted in Techniques | 1 Comment