Applications Architecture: Capability Matrices

Over the past year – I’ve been finding myself using Capability Matrices for a wide array of purposes:

• Evaluating whether to use one application over another when hosting training materials
• Showing my management the level of effort (and money) it would take to replace key functionality if they choose to eliminate or replace a particular application.
• Figuring out WHY I don’t like any of the tools at my disposal to
  accomplish a particular task

A Capability Matrix generally has the name of the application on one axis and the requirements on the other axis.

This link contains a very high level SharePoint example from CMSWire.

In this case, the requirements are the rows and the applications are the columns.

———————————–
In an ideal world – the requirements would be pulled from the requirements that were used to purchase the application.

I don’t live in that world.

Also – requirements lists can get pretty long.

For our Unified Communications project – our requirements document was about 200 pages.
When we finally get around to building out the capability matrix for that system, you can bet we are chunking that up into much smaller functional sections.
—————–
I find the “requirements” in my early capability matrices have been based on
1) The decisions that need to be made around the particular applications (keep or ditch? should I use this or that?)
2) Generic requirements around that particular application – just go to any “checklist for evaluating X” article to find decent starter requirements.
3) Surfaced use cases for our more mature applications (ie – what people are actually using vs the “nice to have”)

Over the next few posts – I’ll talk through the use cases.