In concept, estimating the return on investment (ROI) of a technology initiative is like any other capital budgeting process. The objective is to estimate the cash flows/savings likely to be generated by the technology initiative and determine whether these cash flows exceed the costs of designing, building and operating the systems and processes associated with the initiative.
The practical challenges of putting this concept into practice are considerable. It is generally difficult to quantify the benefits of technology initiatives. Often it is more fruitful to estimate the cost savings of technology initiatives by applying activity-based costing, a procedure that assigns costs to activities based on the amount of time they consume. Our real life experiences in enterprise project engagements with big clients pursuing the development of database intensive applications gave us a better understanding how to quantify ROI on database access technology decisions. It is the only way to figure out the real costs by being present on the development floor and experience development with these technologies and observe the time that is takes to develop/change/tune database transactions.
In many systems today the decision to choose a database access layer is critical to the total budget that is allocated for the entire system. During requirements gathering and use case analysis, the business data that is involved and their relationships define the actual database transactions that the code needs to execute. A technology that targets these data requirements in a direct way (Custom auto generate data services for the database transactions that you need) makes a lot of sense right from the beginning. Other technologies simply offer a black box framework that can be used as your database tier by implying that:
1. You do not worry about how efficiently SQL is build by the framework.
2. That defines multiple entities that may or may not be used with a wishful thinking that it is adequate to fulfill all requirements.
3. That the power of SQL can be fully utilized by some Object Query language.
There are many articles that people publish on the web about this type of technology choice. Unfortunately these people do not come from the actual field that forces them to use the technologies that they support in many different scenarios with steep performance requirements. A current example is LINQ to SQL where clearly it was pushed as the technology of choice to build data tiers (only is SQL server) and today it is replaced by another framework that is pushed by the same company.
Choosing the right database access technology the cost can be significantly lowered if:
1. The amount of coding is reduced.
2. Database access tuning is an easy task to perform.
3. The design of a database access tier is forced to be isolated from the business logic tier and directly targets actual business requirements.
4. Performance analysis can be easily performed from one place in one tool at any transaction level without writing any code for both the raw database server response as well as the actual code that executes the SQL.
5. The technology of choice guarantees the fastest performance possible because of the code that it generates.
6. Multiple skill sets can come into one application tool to solve data issues and redundant operations.
7. Maintainability is a breeze.
There are some basic and true facts in a typical project that can explain how development costs go on a rise:
A. Not collaboration of different roles: The business analyst knows the business rules and the database analyst knows how to retrieve the data that relate to the business rules in the most efficient manner. In most cases resources that execute both of these roles are not responsible for writing the database tier. The lack of a software tool that allows collaboration will slow down development and tuning of the database tier and therefore yield higher costs.
B. ORM one to one table to class/mapping limitations: In the majority of cases the physical database schema table structures do not resemble the business model objects that are involved in these transactions and realistically they shouldn’t either. When the chosen technology relies on a one to one table to class mapping, the amount of code generated and the code that needs to be written is significantly more.
C. Framework bindings/data objects dependencies /Reflection: Physical storage should be independent of the business model objects that are used in the database transactions. Business rules can involve data from multiple tables using all different sorts of relationships. Unfortunately, many database access layer technologies either assume one to one match of business model objects to database tables or they map to multiple tables using XML files that they always have to keep in sink somehow. These mappings become very tight with the framework and the model objects (Entities) become part of the framework.
D. Object Query languages limitations/learning curve, Object cache required: These technologies use object query languages to read and persist the objects and they require object caches to perform fast. Since they are one solution fits all, they have to utilize reflection to populate data in their entity models. In some of these frameworks most of the queries performed in the systems that use them are anonymous queries that the results come back in strong typed result sets. These result sets are traversed to build other objects that represent the actual business model objects in result sets. In other cases the table mapped object graphs returned have to be transformed into different objects that the business layer understands. In both cases we end up with a lot more code, slower performance and high cost in maintenance. Object queries are not easy to write and the skill set is not popular either. The cost for pursuing a solution with typical ORM solutions is huge. Developers spend enormous amount of time building object queries and transforming the results into other object structures as well as trying to enhance performance by applying a lot of guess work to enhance the underlying SQL that they have no direct access to. In an enterprise system object caches add tremendous cost on the budget in terms of maintenance, monitoring and actual licensing fees. Some ORM technologies cannot be used with enterprise caches either since they have their own in the CLR.
E. Ignoring the power of SQL and pure ADO.Net: The power of SQL and the ability to manage it in all database transactions that make up the system by auto generating the related object code in one IDE saves time and money. It is more accurate, faster and uses only business model objects that are derived by the business data requirements. By sharing open XML format project files, that do not define anything for runtime deployment rather XML files that contain project design data, developers of different skills can focus on the database tier and enhance performance as well as fix data related issues with the ability to view real data from method executions within the IDE itself.
To reduce ROI and use a technology that has been proven to do exactly that, consider the fact that the auto generated on demand data services code is written by the IDE that promises to:
A. Greatly reduce development time – developers spend less time coding and bug fixing. Remove the complexity of ADO.Net and SQL from developers by not having to write it.
B. No expensive runtime licenses. No licenses at all.
C. Generate efficient, clean code that would cost a lot of cash to build by hand. Generates the entire DAL as source code - no proprietary run-time components.
D. No technology lock in. Orasis Mapping Studio 2009 generates source code – there are no proprietary components.
E. Guarantee code uniformity across the boundaries of the database tier.
F. Target raw performance.
G. Allow switching to different .Net languages with a click of a button and therefore utilize different skill sets and therefore no need to hire extra resources.
H. Allow switching to different databases and different middleware Providers.
I. Save money by not having to spend hours for writing Unit test code.
J. Secure deployment surprises by knowing data tier speed while in development.
To utilize a mapping concept through a graphical user interface, backed by an auto code generation engine targets requirements to their root. Build only what you need, when you need it and share it with the rest. If somebody can improve performance, simply utilize the tool, update your queries, time your results and save. The choice of a database access technology becomes crucial to the overall budget. With the growth of the business data requirements as the majority of use cases go through analysis, it becomes evident that the table object generated graphs do not match the business data requirements and therefore more transformation code needs to be written; In many cases the power of SQL cannot be utilized at all and a lot of database processing ends up in business layer code. Porting to another similar ORM technology is also wishful thinking. The data access code is mixed with the business code and the maintenance/debugging becomes very expensive. Using Orasis Mapping Studio 2009, an organization can bring down the cost on the data tier significantly and target production deadlines in realistic time constraints.