IT managers and system architects know the critical applications they design, develop, and manage correlate directly to overall business success. These critical business systems increase operational performance, ensure service levels remain high, and drive revenues for competitive advantage.
To ensure their organizations reap optimum value from these systems, most organizations invest heavily in the design and implementation of the application architecture. Architects and managers spend countless hours choosing the hardware, operating systems, application servers, programming languages, and database technologies they’ll use. Given this long list of considerations, it’s surprising how often designers and developers overlook a critical lynchpin in their application infrastructure—the data connectivity layer.
Data connectivity middleware (typically Open Database Connectivity [ODBC] and Java DataBase Connectivity [JDBC] drivers, and ADO.NET data providers) ferry requests and information back and forth between the application and underlying database. Although often overlooked, or taken as a given, data connectivity is an architectural decision and can have dramatic impact on the performance and availability of critical business systems.
IT managers and architects alike often witness firsthand why today’s critical systems have zero tolerance for delays or errors relating to accessing, processing, and storing data. Inefficient or unreliable data connectivity can lead to poor performance, availability and scalability, and to data integrity issues. As developers at packaged software vendors and in corporate IT departments build and deploy critical business systems, it’s important to examine the role data connectivity plays and options available today.
Business Implications of Database Connectivity
While data connectivity is traditionally a technical decision, its implementation and architecture have significant business considerations, including cost containment and resource allocation; risk mitigation; and revenue, profit, and shareholder value.
Cost Containment and Resource Allocation
To stay within budget, database connectivity requirements should be evaluated early in the project lifecycle. System architects must determine the functionality, interoperability, performance and system uptime needs of applications before choosing an appropriate database driver vendor. Doing this at design time saves significant unbudgeted expense and unplanned developer time on unforeseen database connectivity issues down the road.
When evaluating data connectivity options, IT managers must weigh the pros and cons for each available solution. Factors to consider include:
- Drivers from database vendors: These drivers are designed to work with a specific version of a specific database and inherently lack interoperability features that enable developers to easily migrate from one database source to another. Database vendor drivers often require significant application rewrites to ensure successful data access and connectivity.
- Open source drivers: These drivers are appealing due to lack of licensing fees, but they’ve proven to be unreliable and slow when handling largescale systems. They also lack customer support and services.
- Independent data connectivity vendors: These vendor offerings support multiple databases through industry-standard Application Programming Interfaces (APIs), providing greater performance, interoperability, and reliability.
If the details surrounding data connectivity aren’t fully understood early in the project lifecycle, then developers often spend weeks or months during the project getting their application to work effectively. Too often, this time isn’t reflected in the schedule because of the implicit assumption that “it will just work.”