Analysis and architecture

Note: I originally titled this post “Analysis vs. architecture” but deliberately changed it based on the tone of the post as it emerged.

So, I’m not quite sure what inspired this post from Nick Malik but it certainly provoked reactions! Kevin Brennen from the IIBA responded very quickly with a detailed post citing numerous instances from the BABOK pointing out a lot of similarity between business analysis and architecture activities. In a comment to the original post, Tom Graves also pointed out that it may be the thought processes or weltanschauung that differentiate (or align?) the two roles.

In a follow up post the following two questions are asked of business analysis and architecture:

a) Is it better or worse for these roles to be independent?
b) When both roles exist in the same organization, how do we prevent confusion, clarify accountabilities, and make both roles effective?

Better or worse?

Setting aside time as a constraint, my response here is: someone who has the clearest view of the architectural needs is already well placed to steer the analysis towards meeting those needs. I agree with Kevin that the business analyst and architect role are not quite as far apart in terms of skill-set as is sometimes claimed. It does require that single person to be able to look “up” to analyse the strategy and capabilities and to then look “down” to the detailed implementation of their realisation. In my view, however, that is more a difference of mind-set (and experience) rather than skill-set.

But… I now come back to my caveat about the time constraint. I’m currently in a team of 4 business architects working with a team of around 30 business analysts. My current assignment is as an architect for a 2 year program of 4 projects (although the inevitable “phase 2″ is being talked about!) working with a team of 7 business analysts. Would it be better or worse if I tried to do my own job and that of the 7 business analysts? Would it be better or worse if the 7 business analysts all tried to do the business architecture in addition to the 4 people who have been given it as a day-job and on top of their own day jobs? I would argue worse in both cases.

So, sometimes it’s a necessary evil for the analysis and architecture roles to be separated. The business needs (I need!) multiple business analysts to get through the volume of work; but the business needs (the analysts need!) a single steer on the architecture.

Accountabilities

The table below sets out how we generally segregate accountability between the architect and analyst. Note that you can simply substitute “roadmap of change” wherever you see “program” if that is better suited to your situation.

Architect	Analyst
Responsible for the value delivered across the whole program	Responsible for the value delivered by individual project scope
Works with project management to scope and schedule capability increments across the program	Works with project management to schedule capability deliveries within the project
Agreeing with the sponsor the budget to be spent on each capability increment	Delivering within that budget or flagging risks of over/under spend
Advising the sponsor and project management on capability trade-offs at program level	Advising the sponsor and project management on alternative delivery options for a capability
Ensuring requirements are balanced according to business value across all capabilities being delivered	Ensuring requirements are proportional to the business value of the capability being delivered
Ensuring that all the “moving parts” work together – cross project dependency management	Ensuring that a particular moving part serves its purpose – inter project dependency management
Working with IT architects to resolve business and IT architecture concerns	Working with IT analysts to resolve application/component concerns

Communication

Clearly, this requires close collaboration between the architect and the analysts both formally and informally.  Our starting point for the formal communication is the Business Architecture Briefing backed up by our “knitting pattern” and functional dependency map.

Informally, it’s really just about working as a team – I and the senior business analyst on each project get together at least once a day – and trusting each other. I know I can count on them to flag with me when things are going pear-shaped and they know they can count on me to fire a rocket at the business if they need me to.

It’s not about seniority either. I would, and have, happily worked for business analysts in the reporting chain when they’ve asked for architecture support. It’s just about understanding that the analysis has to flow from the architecture – not the other way around. It’s all about communicating between the two formally and informally to get the job done.

That, after all, is what we are paid to do.

Process or Capability Architecture

An interesting post from Nick Malik recently about how process architectures and capability architectures are different – picking up on an article from Paul Harmon. I’ll be very interested to see the promised “later blog posts”. In the meantime, though, I’m dealing with something at work that really emphasised some of the differences between the two so I thought I’d share it here.

We provide services to distinct groups of individual customers and those services commonly need to be tailored to those distinct groups. We currently have a project underway to extend that tailoring to our web presence. The first capability increment we are developing is the ability to deliver bespoke web content based on the group the customer belongs to.

In capability terms this can be encapsulated quite neatly into the ability to “Deliver bespoke web content based on customer groups”. This is something that is meaningful to any member of the top table and can equally be used as a scoping statement for the delivery teams – be that business analysts, project managers, test managers, solution architects or whoever.

When we get into the detail of the delivery then, absolutely, things become more complex. We’ve identified that we will need, at a minimum, the following supporting processes:

1. A process to develop, test and deploy new content;
2. A process to understand what content is currently deployed and, periodically, to get it reapproved;
3. A process to understand what content was used for a particular user at a particular point in time (non-repudiation);
4. A process to retire content that is no longer used.

In addition, the bespoke web content capability will be used in multiple, customer facing (primary) processes and capabilities – so each of those processes will need to be updated as and when they take advantage of the new capability. Now all of this has to be worked through in the detail of the implementation of the particular project. But how relevant is the detail from an architectural point of view?

My top table doesn’t care what processes we will have to put in place to deliver this capability – all they want to know is can we do it, yes or no? The processes that will use this capability, similarly, don’t care about how the content is managed. All they want to know is what can be done with the capability and how do I access that functionality? Neither of them care what is inside the “black box” only that the black box is there and what it is capable of.

So, to me, some of the fundamental differences between process and capability architectures are:

• Capabilities allow me to talk to any stakeholder at any level (business or IT) about what is to be delivered without having to delve into the detail of the how;
• Capabilities allow me to “architect by black box” creating reusable components of business capability where the implementation details are irrelevant to the capability consumer – this should be a principle that resonates with anybody who has been exposed to SOA;
• Capabilities are a layer in the enterprise architecture that sits above process or IT system architectures – capabilities don’t care how they are realised and you can, for example, automate processes within the capability to improve its efficiency without changing the fundamental building block; and
• As a result of that last point, capability architectures are much more stable than business process architectures, because they are insulated from the “how”, and so require less maintenance.

Now, where I agree with Paul Harmon’s point is that the concept of a capability has yet to achieve a fully agreed definition. I’m not sure that we will ever see that ultimate truth agreed, though. Is there a universally agreed definition of a process map, for example? One question that has parallels with capabilities is “How physical vs. logical should the process map be?”

What I do know is that capabilities have significant real-life benefits for me as a business architect and, quite frankly, I’ll take any edge I can get! Definitions will evolve over time as and when they get tested (and fail) against real world usage. I’m happy and grateful to be part of that real world testing.

The art of compromise: Designing deliverable architectures

You’re initiating a new project: you’ve mapped it against your strategy contribution framework; you’ve done your capability mapping and updated your knitting pattern; you’ve planned your architecture increments; updated your functional dependency map; adjusted your road map; you’ve provided a clear steer on the shape of the business solution required with your architecture briefing… you’re good to go, right? (If you’re looking for guidance on those techniques check out my posts in the Techniques category)

Whoa, there Neddy! Hold your horses just a second. Have you made sure your architecture is deliverable?

By deliverable, what I mean is, can you give your business the right thing at the right time for the right cost?

A whole host of issues come to bear at this point, many of which are outside of the sphere of business or enterprise architecture: is there any resource contention between this and other projects (remember to include analysis, test, SME as well as development resources); is there any code contention between projects (commonly changes to the same IT application or database); is there environment contention (development, testing or pre-production environments); are you proposing anything new (technology, capability or approach) that affects the risk/reward ratio of the business case; are you creating dependencies on projects that are already in trouble.

All of these things (and probably more) have the potential to compromise delivering the right thing at the right time for the right cost – and they all need to be factored into making the right decision. Here are my three recommendations:

1. First and foremost accept that your business architecture is one and only one view point on the right answer. Other parties will have equally valid view points. Unless and until you accept this don’t go to step 2.
2. You need to involve other parties before base-lining your architecture briefing. At a minimum this will include your sponsor, your business project manager, your IT project manager, your IT architects and your test manager. Depending on your organisation you may have other stakeholders.
3. Be prepared to iterate – but do it quickly! Prefer face-to-face rather than e-mail consultation, prefer a half-hour review this week to a 2 hour review in three weeks time, whatever it takes.

I originally titled this post “Designing deliverable architectures” then changed it to “The art of compromise” and then combined the two. Fundamentally they are the same thing. In order to get a deliverable architecture you will need to compromise – accept it, embrace it, work out in advance how you’re going to handle it.

Business Architecture: How long?

Interesting article from Jeff Scott at Forrester. The headline for me was “63% [of survey respondents] thought they could create the core business architecture in less than two years” followed up by his caution that this was over-optimistic. I have a lot of respect for Jeff ever since I first read this article from him in Architecture & Governance.

Now, I guess all this comes down to what you define as “core business architecture”. But if you mean a stable, repeatable method and models that are fully integrated into strategic planning and the change road-map then I would agree that two years is quite challenging.

However, that doesn’t mean that you need to wait two years until your business architecture efforts can start to add value.

Sure, we had a couple of attempts at defining our capability model until we got it right. These were spread over a number of months and, speaking frankly, it’s still not quite where I’d like it to be. On the other hand, we got our strategic alignment framework up and running in a couple of weeks and, touch wood, it hasn’t really needed any change since we started it.

Maybe I’m an optimist but my response to this post was:

• Don’t let the best be the enemy of the good – you can get value quickly from business architecture; and
• If it really is going to take a while to get it right… best get started now then!

 

Help needed – How tactical should my architecture be?

Yeah, the title of this post probably didn’t give you much to go on did it? Let me explain…

We’re in a service business where our key customers are corporate customers rather than individuals. Our strategy calls for us to be penetrating the really big corporate customers – think top 50 FTSE, DOW, EUROSTOXX etc. and we’re having some success. But here’s the thing – most of the time, these guys won’t take off the shelf processes. They have to put in place their own processes to consume our services and each corporate wants to minimise the cost of their own processes. As a result, I’m seeing a lot of new requirements coming in that I need to match back to the architecture.

In the main, these are different ways of accessing the same core service/process which doesn’t require modification. As an example, we have a core process that is carried out by our BPM automation engine which is stable but, depending on the customer, needs to be initiated by an internal user interface, or by an external web user interface, or by a flat file that may be pushed to us, or pulled from an FTP server and so on. However, sometimes there is a specific requirement that doesn’t fit within any of our core capabilities (you can assume that our architecture is capability based rather than process based by the way).

So, I think I’m looking at having to assign attributes to my capabilities along the following lines:

• Core – This capability is stable, repeatable and predefined; it will not vary by customer;
• Strategic Flexibility – This logical capability must be capable of multiple, physical realisations that, for a large subset of our corporate customers, will vary and therefore requires investment to deliver that flexibility;
• Tactical – This capability is something we agreed to do for a particular customer (or small subset of customers) just to win the business but is not something we want to spend a lot of time or money on.

One of the great advantages of blogging is that it gives you the opportunity to clarify your thoughts and I think I’ve clarified it to two questions:

1. Is my 3-level categorisation appropriate or is there another, better way of approaching this issue?
2. If it is appropriate, what should I do with the tactical capabilities?

Simplistically, anything we do as a business should be traceable to an entity in our business architecture and therefore every tactical capability should also be in the architecture models. But if you take that approach to its extreme, you’d be reflecting all the manual workarounds in your architecture which is clearly wrong and will simply add cost of ownership to your architecture models. On the other hand, I need to be aware of two things with the tactical capabilities: I need to give guidance that I need a Robin Reliant solution and not a Rolls Royce to the IT guys; and I need to monitor whether a tactical capability is moving into the strategic flexibility category (e.g. if multiple customers start asking for the same flexibility) and respond appropriately.

Should I or should I not include the tactical capabilities in my architecture? Have I or have I not got the right categories for my capabilities?

Help!

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.

Functional Dependency Map

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.

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.

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.

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.

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.