It does not matter what the size of your organization is, switching software platforms for any system is a challenging task. Take the company I work for as an example, where we are considering adopting a new accounting package. We have been using the current platform for a number of years and as a company we have been able grow, however we are reaching the maximum potential that we can reap from this software. We have several applications that have been built as add-ons for this system, so our investment into the platform is by no means light. These add-ons have been built by a third party, due to the fact that the underlying database platform is extremely temperamental. We have a handful of capable developers on staff that can write good software, given that they have a good foundation to start with. This is simply not the case.

The accounting package that we are investigating provides us with an SDK that has literally hundreds of objects and Web Services wrapped up into some APIs that can be developed for inside of Visual Studio. Our current system has no APIs available at all, so in order to develop a third party application for this software, you MUST be a master of the schema of the data tier as well as being privy to all of the nuances of the application. As I see it, there are pros and cons to each, but I favor the API approach.

The API Approach:

An Application Programming Interface, or API, is a piece of software -beit a library, a service or whatever- that allows you to communicate with a program through a set of protocols defined by the publishing software vendor. In some cases, an API may be a library that is utilized by an application and it simply allows you to reference the libary to build on to the application. This is the case with software platforms such as Microsoft SharePoint Portal Server and most .NET applications. It comes as no surprise to anyone that software is complex. So much of today's applications are built around business rules and logic that have taken years to define. It is for these reasons that I believe that the API approach is far superior to directly writing to a data layer.

To me, using an API is like driving to Chicago from Fort Wayne. I could take a few backroads here and there or even a few lesser travelled highways, but I have a far less chance of getting lost and will most likely get there much faster if I use the highways that are designed specifically for that traffic. An API is that highway. It is the communication medium that is used to enforce the business rules and logic used to protect the data tier. It also provides a common language for collaboration. Seperate organizations can collaborate on projects using the APIs as a common development platform. Code can be reused and efficiency in development will be higher. Without an API, you would have to develop your own libraries for communicating with the data tier and those libraries would be used (most likely) only by your organization. Needless to say, your custom API will be quite different than an API offered by the vendor. The API supplies you with a common foundation on which to build.

The Non-API Approach:

There is only one feature of the non-API approach that I find attractive: Complete Control. I am not hindered at all by any of the logic or rules in place by the software's architecture. If I wish to write values to a table against the grain, in most cases I could do so given that I adhere to any constraints. But there is so much danger involved with this methodology. Proper database design ensures that data is properly stored, filed, linked and etc. because data integrity is essential. If you possess a complete understanding of the database schema, you can modify this data without issue. But if you are using an API, you are using the vendor's managed communication medium to read/write data from the database. Database connections, record locking and all of the issues you would have to keep track of while communicating with a data tier are now YOUR responsibility instead of the vendors. If you use an API, there is still the risk of your application being at fault when something goes wrong, however, by using the API you greatly reduce your risk.

Conclusion:

Ultimately, you can go either way with the API mentality. Risk, responsibility and accountability are much higher with the non-API approach, but they tend to offer a much higher degree of flexibility. The API provides a much more managed approach with software that is designed to be used in conjunction with the business rules and logic that are at the core of the platforms architecture.