When designing Software Architecture, it is easy to confuse Vendor independence with Platform independence, or think that it is absolutely necessary. If your organisation already has a strategic platform, or that it has strategic alliance with a particular vendor, then this should be core to your architecture design processes. Ignoring this aspect, you might design a perfect solution for a non-existent problem. This is the software architecture equivalent to overcapacity, it could be costly.
There is always a temptation to come up with an architecture that is pure, scalable, flexible, and so on. But to what end? As we know, beauty is in the eyes of the beholder, and beauty for its own sake will often not make business sense. Why pursue it then?
One of the benefits of the software architecture practice is in delaying implementation decisions until after the business issues have been properly understood and captured, in fact it should be separating implementation decisions (and not delaying). But that thinking amounts to assuming that implementation is not a business concern at all, which could be wrong. There is a risk of designing a perfect architecture that simply cannot be implemented without significant performance or delivery penalty.
My point can be summarised as follows:
- A perfectly valid process can yield perfect disasters when it is short sighted in any significant way.
- Business domain semantics should be analysed in context, not based on a theoretical ground far remote from the specific business reality.
- Consider the complete lifecycle of the solution being designed: if the vendor or platform lifecyle is likely to survive your solution, duly include such vendor or platform considerations in your key drivers.
In large enterprise architecture endeavours, usually there are sufficient resources to tackle all aspects of an Enterprise Architecture requirements. This is often not the case for SMEs and start-ups, the largest group operating with tight resource constraints.
It might be tempting or even self gratifying to think that you’re designing a vendor or platform independent solution, but that might not be the best way to deliver value to your stakeholders. In practice, it is always better to take sides when designing business technology solutions. This is the main reason that large businesses often enter strategic alliance with a prominent vendor and thus commit to its solutions and products. There is nothing wrong with such practices, obviously. Carefully managing the vendor relationship is another issue altogether, which cannot be discussed in this post. What could always be counter-productive however, is when software architecture practitioners would try to downplay the role of such strategic vendor products and solutions at the design stage.