This Business Attribute from the SABSA Business Attributes Taxonomy is one that deserves a great deal of attention with respect to every solution architecture. First let’s establish a conceptual framework within which business solutions are constructed. The essential goal of any such solution is to create ‘business value’ through what we call ‘value chains’. Supporting this goal we build a ‘business stack’ – a layered view of what it takes to create value. So immediately we introduce the concept of ‘support’ – each layer supporting the one above it.
The diagram shows a high level conceptual view of such a stack. Notice that it is a combination of people, process and technology – you cannot do this with technology alone. The people are supportive of every layer in the stack and are therefore aligned at all levels. Similarly there are a number of support processes and services also aligned at every level. The type of support service and the type people skills and competencies will, of course, vary from layer to layer. To meet the requirements of the attribute ‘supportable’ we must consider all of these aspects of support.
So, having set the scene for support as a concept, we shall now take a very focused case study to reveal some of the complexities that can arise. We shall consider what it means to support a specific technical product that forms part of an integrated business solution. In the case of a vendor product one of the questions we would ask during the buying process would be about the type of support that the vendor would provide and what the cost of this support would be. Then we find that two different vendor products are to be interfaced together as part of the system integration. Now it starts to get tricky unless the interface is clearly defined and the vendors are both clear about which side of the interface is their responsibility. The important thing here is to ensure that there are no gaps between the vendor domains of responsibility where there would be no support. It is also necessary that the interface is clean enough to prevent the vendors from claiming that the other is responsible and for this mutual face-off to create a deadlock in resolving support issues.
So far, so good: vendor products, out of the box, clean interfaces, clear domains of support responsibility. What happens next in so many cases is what destroys the capability to support the integrated system into the future. The system owner starts to customize it. New code is written locally and added to the vendor products to make them a better fit. This code does not have vendor support – it will be supported in-house, but we all know that the type of rigorous support that we can expect form a reputable vendor is never going be replicated by our own people. The imperative of the moment will always be to ‘get it working’ and then move on the next emergency, and so support documentation is never as good as it should be. Our people move on, change jobs, and new ones replace them. When it comes to the point where we need to support this customized component, no-one is around who knew how it worked and the documentation is inadequate to instruct the new people.
What do we do then: we call the vendor. The vendor will recommend that we first clean up the product and make it once again ‘out-of-the box’, otherwise any third party interfaces will not work. Trying to maintain a poorly supported product is not an option for the future at that point, and so we pay the vendor a large sum of money to put things right.
The lesson from this discussion is that whilst altering the internal functionality of a vendor product may be acceptable (provided that you really can support it), once you change the external interfaces of the product you really will be in trouble at some future point. The cost of this can be very punishing. SABSA Business Attribute Profiling is all about getting a balance between a wide range of attributes that cannot be treated in silos, otherwise the results can be catastrophic.