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.


About EBAnous

EBAnous works as a business architect for a FTSE-100 company in the south-east of the UK
This entry was posted in Techniques. Bookmark the permalink.

One Response to Business Architecture Briefings – Getting off on the right foot

  1. Pingback: Analysis and architecture | EBAnous

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s