Does your architecture pass the “So What” test? Can you demonstrate the specific value that a particular architectural deliverable or activity will add? If not, why are you even bothering? In this case, as with justice, your activity must not just add value, it must be seen to add value.
A number of recent discussions at work made me think about this question:
- I had proposed doing a small piece of architecture work, and a programme manager had challenged me, asking me what was the value of that work. I was able to describe how it would help us achieve some of the programme aims, converting them from being opposed to the piece of work, to be being happy to support it.
- A colleague ran a piece of work past me, and I had to ask: What if your business owner asks “so what”? Our discussion ran along the lines of: I’m an architect, I can understand how this could be useful, but you want business people to look at this. You need to clearly articulate how it is useful, how it adds value for them. Otherwise they will just think you are wasting their time and money – and you won’t get their attention and buy-in.
- A colleague and I were discussing a piece of work that we were wanting to undertake. During the discussion it became obvious that this wasn’t quite the small thing that I had originally thought. Given its size, I immediately asked – can it pass the “so what” test? Can we demonstrate to the people who will pay for this activity that it will actually add that amount of value? We both thought that it did, but we were also unsure about the best way to show this.
Asking if your architecture can pass the “so what” test is just a specific case of a general principle: if your activity isn’t adding value, you shouldn’t be doing it. The additional difficulty with architecture – especially enterprise architecture – is that what we are doing is often at several removes from concretely delivering something (such as a working IT system) and is often in impenetrable technical/architectural language. This makes it very hard for people who aren’t architects, or at least IT professionals, to understand what we are doing. Let alone how it might help. To address this problem I think we should be able to succinctly describe how an artefact helps solve a business problem. Preferably that point should be included in any document you are producing.
Asking this kind of question – or explicitly articulating the answer can also lead to you refining what you produce. Articulating what the value is might lead you to change the content. In particular once we understand the use this might be put to, you might decide that to be truly valuable it needs additional pieces of work. We need to be on the look out for cases where in order to add any value we need additional pieces of work! Sometimes what we are doing only helps if some other piece of work occurs. In these cases we need to ensure that both happen, otherwise what we are doing is a waste of time and money.
So, for any piece of work, but especially for large pieces or ones requiring non-IT people to agree to them ask yourself if it passes the “so what” test: does this add value? Does it solve a business problem? If the answer is “yes”, have we clearly articulated this in a way non-technical people can understand? Does this activity add value on its own, or does it need something else? And, finally, is there something else we could spend time on that would add more value?