The shift to a service-oriented architecture (SOA) by many software vendors has changed the focus of application architecture. Although it is a given that it is best to separate an application into layers, the question remains whether the application should be tightly integrated with the database. The traditional approach, known as database agnosticism, allows the user to select an application and a database independently. While this approach may sound good at first, it sacrifices system performance and flexibility.
The reason for this is that to support multiple databases, the software vendor must pick the lowest-common-denominator set of database features for the application to use. Often this results in less than optimal design, user experience, and performance. Focusing on a particular database product enables developers to take maximum advantage of the database's feature set. This allows the application to offer additional capabilities not available in a database-agnostic application, resulting in richer functionality. Tight application and database integration also lowers database management costs because the application itself can automate these ongoing management tasks, eliminating much of the work required of a database administrator (DBA).
This article presents the case for applications that are integrated tightly with the database platform on which they operate. This method of application development increases functionality, improves system performance, and lowers both development and maintenance costs. In the past, databases were the integration point where applications connected to communicate with each other. But in the twenty-first century, the middleware layer is the integration point. Companies are investing more in middleware acquisition and in building the competence to manage that middleware than in investing in database technology and expertise. To achieve cost efficiencies, companies are using a single middleware layer for all their applications and are choosing the middleware themselves rather than being forced to accept what their application vendors dictate. In other words, they are turning away from database-agnostic applications in favor of middleware-agnostic solutions.
More Than a Storage Bin
Today, database applications have become more than devices with which to store and retrieve data. Significant query functionality and data management tools are packaged with the database itself. As enterprise application vendors work to add Google-like enterprise search features, development organizations that rely on the text indexing and query functions of their underlying databases will find it easier to bring this functionality to market. However, database-agnostic applications must be developed and then redeveloped to adjust to each database. This adds cost that customers must absorb through increased license fees and makes the applications more complex and expensive for vendors to support and upgrade.
Furthermore, operating these search capabilities is database-intensive. If you can rely on the database to perform these functions, you are spared the stress on system resources that would result from pulling this information out of the database and performing the search function. Similarly, rich media, such as video and audio, can be handled much more easily if they can be accessed within the database itself rather than by pulling a large, unwieldy file out of the table in which it resides.
Apart from enterprise search, database-specific applications can more easily deliver business intelligence (BI) and data-mining functions. BI tools such as online business analytical processing (OLAP) cubes can be built right into the application at the database tier, and this is where this type of functionality should naturally reside—as close to the actual data as possible.
Database-agnostic applications often require different management tools and processes for the database layer than for the application layer. An application that is database-specific can lower costs by unifying the tool set and management time for both layers, thereby reducing or eliminating the need to retain the services of a DBA and cutting application management costs.
Also, a database-agnostic application has very different performance characteristics depending on the database on which an instance of the application is running. Although other portions of a system, including the operating system and hardware, can vary without significantly affecting the performance of the application, this is not the case when an application runs on different databases. Queries that might run quickly on an Oracle database might run slowly on Microsoft's SQL Server or IBM's DB2, or vice versa, depending on how the application is optimized.
New Technology Solves Problems
One argument for designing database-agnostic applications was the perceived difference between the level of skill and effort required to manage different database platforms. Historically, SQL Server had the reputation of being relatively simple and user-friendly, whereas many people believed that Oracle required a DBA with extensive knowledge of tools and methodologies that were difficult to comprehend and master.
However, recent data suggests that the opposite is true. A study released in March of 2006 by Edison Group, Inc. reveals that current Oracle databases are, in fact, less time-consuming and less costly to administer than current structured query language (SQL) databases. The study, titled Comparative Management Cost Study of Oracle Database 10g Release 2 and Microsoft SQL Server 2005 (visit http://www.theedison.com), makes the following conclusions:
- DBAs can perform typical administrative functions 38 percent faster when using Oracle Database 10g Release 2 than when using Microsoft SQL Server 2005.
- Oracle Database 10g Release 2 requires 30 percent fewer steps than Microsoft SQL Server 2005 for the same set of standard administrative tasks for a relational database management system (RDBMS) based on Edison Group's metric for complexity assessment.
- Benefiting from increased DBA productivity, businesses can save up to $31,664 (USD) per DBA per year by using Oracle Database 10g Release 2 instead of Microsoft SQL Server 2005.
These facts aside, many users of applications running on Oracle databases retain no DBA whatsoever. Automation tools within the database have largely "leveled the playing field" in terms of maintenance cost and activity. All databases require some level of maintenance, and the types of maintenance—such as the maintenance and work required to prepare for a restore in the event of system failure—are similar regardless of the database vendor. Today, anyone with the knowledge and skills to administer an SQL database can likely do the same with an Oracle database. It is similar to switching from one brand of automobile to another: When it gets dark outside, you know you need to turn on the headlights, and you can do so simply by familiarizing yourself with the location of the switch.
By tightly integrating the application with the database, the application can be designed to perform much of the routine database maintenance by itself. This is simple to do if the application is designed so it understands the performance characteristics and maintenance requirements of the database, but is more difficult and expensive if the application must support multiple databases.
One argument against database-specific enterprise applications has been the fear that the database eventually will become overburdened, creating a bottleneck in the system. This is no longer a concern as a result of technologies such as Oracle Grid Computing and Oracle Real Application Clusters. Real Application Clusters allows an application to share a single database across multiple nodes or servers in a computing cluster. It is now possible to run a powerful enterprise application that is tightly integrated with its underlying database in an infinitely scalable environment—without suffering performance problems or requiring increasingly expensive server hardware.
Focus on the Middle Tier
By the late 1990s—about the time that Microsoft purchased SQL Server—many enterprise software customers were interested in applications that were database-agnostic enough to support SQL Server. Although there arguably may have been a case for database neutrality in those days, such is not the case today.
The focus of how applications interact has changed since the late 1990s to the point that it makes little difference what database an application is running on, as long as the application can make the best use of its database platform. Today, it is more important that the application be compatible with a variety of middleware products because this gives users greater freedom.
As recently as ten years ago, applications were designed to deliver reporting directly from the database tier. Similarly, integration with other systems was done from the database. If an add-on program was developed for the application, it was tied directly to the database. The database was the functional hub of the application, and the ability to choose the database affected how well the application could interoperate with other systems.
But things have changed. Today, any integration work is done through Web services in the middle tier of the application, and add-on development is similarly tied into the application in the middle tier through services that communicate with the application programming interfaces (APIs). Reporting is done not against the database, but rather against extensible markup language (XML) data schemas in the middle tier. In short, the middle tier has become the place where all connection points and interfaces in an enterprise application are located.
Today, it is more important for customers to choose the middleware product they want to use, and less important to choose the database. It is as if the database is turning into a "black box," meaning it is performing its tasks in a self-contained manner, with little or no human intervention required. Everything a user does with a truly modern enterprise application is driven by the middle tier, while hidden elements of the functionality may, in fact, be driven by features embedded in the database layer.
The enterprise application of the future will not need to offer the choice of multiple databases, but rather it will give users the power to choose the middleware product. This will allow twenty-first century application vendors to offer products that are technology-neutral, with functionality that can quickly adapt to changing technologies without disrupting the entire application stack. While implementing these applications, a company can choose to use middleware such as Oracle Fusion, SAP NetWeaver, or IBM WebSphere—or it can opt for an open-source solution such as JBoss.
It is important to note that many leading enterprise software products are owned by companies that also are in the business of selling middleware. Application vendors that specify a single middleware solution—or force users to adapt their own—are increasing the cost and complexity of their customers' solutions. Operating a single middleware product leads to a more homogeneous information technology (IT) environment and lowers total cost of ownership (TCO) by limiting licensing fees and training costs. Today, however, nearly all companies use multiple products, including enterprise resources planning (ERP) and customer relationship management (CRM) software, extranets, and homegrown applications. If these products offer a choice of middleware, a company can standardize on one middleware product, but if each application requires a different middleware product, then the customer is in a difficult situation.
Imagine a company that runs Oracle Financials on Oracle Fusion middleware. When it buys a new maintenance solution, can it continue to use Oracle Fusion? If its maintenance product does not support Fusion, could it be forced to adopt a second middleware, such as WebSphere, to accommodate its new maintenance solution? Or imagine a company that is already using WebSphere to manage integrations with its old mainframes. Will the company be able to continue using WebSphere, or will it be forced to learn a second platform when it acquires a new business application?
The answers to these questions are, unfortunately, not what companies would want to hear.
To be clear, a SAP customer, for example, is limited to NetWeaver. A Microsoft enterprise applications customer must use Windows Server. Other products, including those from Lawson, limit users to WebSphere.
Conclusion
At one time, database-agnostic enterprise applications may have had marginal advantages. But even then, these applications presented vendors and users with significant drawbacks. Today, new technology has eliminated the benefits, and the advantages of integrating an application with the underlying database are more compelling than ever before. At the same time, it has become more and more important that enterprise application vendors offer a variety of middleware choices.
Not only does a middleware-agnostic application reduce TCO and complexity, but it also frees enterprise software buyers from relying on vendors that use their middleware applications to force customers to adopt their enterprise software. After all, why would an application vendor develop its own middleware product if not to lock customers into its solutions and to stifle competition?
About the Authors
Rick Veague is the chief technology officer of IFS North America, and is based in the company's Schaumburg, Illinois (US) headquarters. In this role, Veague provides direction for IFS's use of service-oriented architecture (SOA), and works with IFS's leading customers to leverage SOA to provide state-of-the-art enterprise asset management (EAM) and enterprise resource planning (ERP). Veague can be reached at Rick.Veague@ifsna.com.
Dan Matthews is the chief technology officer of IFS research and development (R&D) and is responsible for the strategy and development roadmap for the architecture, development tools, and technology platform used in IFS Applications. Matthews joined IFS in 1996 after working as a freelance software contractor. Matthews can be reached at dan.matthews@ifsworld.com.