“Agnostic technology solution” is a term I heard in a meeting . In IT terms – it means there’s a recognition the question is important  but the answer can be generic. The  context was a Data Architecture solution. The Proof of Concept (POC) would establish the effectiveness of a Data Architecture solution. If the solution proved effective – it could be implemented on different technology stack. The proposal was based on the SQL Server Data Mart. The Data Mart would handle the load, create ETL graphs and define security access to the data presented in the Delivery platform.   In theory , the solution could be applied to any other technology stack.

 The “agnostic” term is widely used. The vendor will define a solution for some middleware – and present the DDLs for the major Database Vendors. For example , a Process Engine middleware – which has potential for support of SQL Server, DB2 and Oracle. Depending on the vendor –  support may be better for one platform. The reality with an “agnostic solution” is the difficulty to adjust once the solution is in place. In a multi database environment – the solution may have been implemented on DB2 , by an unsuspecting middleware manager , but would have fitted better on the SQL server stack – due to in-house skills. This is one example amongst many. It is important to have the Database Architect \ Senior DBA involved at the outset . The Database Architect can discuss and recommend which platform to use –  for management and scalability.

Posts this week on SQLserver-DBA.com