A Case for Technology Agnostic Design (TAD)
Have you ever heard someone describe a design or platform architecture by using the names of the third party systems used to implement their platform? The discussion starts with a question: “How are you architected?” and ends with a statement like “We use ACME web servers running on PLATINUM computers connected to our own internal application running on ACE application servers. We use BESTCO databases to maintain state and store information and they run on FASTCO SMP servers connected to a BESTSAN storage area network. Our network is all FASTGEAR and SAFE supplies our firewalls”.
The statement is innocent enough, but it does not address how a site is architected; it is rather a statement of how that architecture is implemented using technology.
Mature technology organizations understand that there is a very big difference between architecture and technology. The architecture of a platform describes how something works in generic terms with specific requirements and the technology describes how it is implemented and what it is comprised at any point in time.
The aim of technology agnostic design, or TAD, is to separate design and architecture from technology and implementation for the purposes of reducing cost, decreasing risk and increasing both scalability and availability.
TAD and Cost
It is unlikely that you will see an architect of a house label trusses, beams and supports with the vendor’s name. More likely the aforementioned objects will be labeled with sizes or specifications for load bearing. One reason this is so is that the architect recognizes that most pieces with which they will design a house are “commodities” or things that can be easily swapped out and which might be purchased primarily based on price.
Most technology solutions also ultimately suffer from the effects of commoditization. This is to say that as a good idea starts to become successful it is bound to attract competitors. The competitors within the solution space initially compete on differences in functionality and service but over time the differences in functionality and service start to decrease as the most useful feature sets are adopted by every provider in the competitive landscape. In an attempt to forestall the effects of commoditization, providers of third party systems and software try to produce proprietary solutions or tools that interact specifically and exclusively with their systems in order to create switching costs for the users of their systems, hardware or tools.
While there are always exceptions, as a rule we believe you are better off maintaining the flexibility of using nearly any provider’s solutions where there exists competition for that provider’s product offerings. The ability to replace one vendor’s product with another fairly easily gives you significant leverage in negotiating prices long term. We don’t mean to imply that you should never leverage proprietary functionality; rather you should understand that the use of such an embedded toolset has hidden and long term costs.
TAD and Risk
Designing for a particular vendor’s solution also creates a great deal of risk for your product and for your company. What if the provider of the solution goes out of business? What if the provider finds themselves being sued for some portion of their solution that does not exist in other similar solutions? What if the viability and maintenance of the product relies upon the genius of a handful of people within the company of the provider? What if the solution suddenly starts to suffer from quality problems that aren’t easily fixed?
Technology agnostic design reduces your risk by increasing your ability to quickly move to other providers without the problems identified above.
TAD for Availability and Scalability
As discussed above, as competition increases between providers of software and hardware and before commoditization completely sets in, providers of software and hardware attempt to differentiate themselves on functionality, performance, and service. During this period of attempted differentiation there might be significant performance, quality, and functionality differences between the providers. Ensuring that you can easily switch between the providers gives you the ultimate flexibility in leveraging these differences to the benefit of your platform.
The TAD Approach
Implementing technology agnostic design is fairly simple and straightforward. At its core, it means designing and architecting platforms using concepts rather than solutions. Pieces of the architecture are labeled with their generic system type (database, router, firewall, payment gateway, etc) and potentially further described with characteristics or specific requirements (gigabit throughput, 5 TB storage, ETL cloud, etc). The first, very simple test is to see whether a 3d party vendor’s name is tied to the system described on paper in any given architecture or design. Data flows, systems, transfers and software that are specifically labeled as coming from a specific provider should be questioned and where possible the system should be designed to allow any provider of a service to exist in that area.