I was recently asked by a company that has a very large application with an equally large code base, on some advice on how to enable third-party developers to tap into their system by using either API’s or a SDK. The goal would be that any third-party developer would then be able to customize and enhance their current system.

Now, I am fairly familiar with SDK’s and API’s from my days as a full-time ACCPAC customisation programmer. I still do a few ACCPAC integrations and customisation from time to time; and I do believe that ACCPAC’s approach to opening up their architecture are some of the best. Here is a breakdown of what ACCPAC’s architecture looks like(Click for a larger image):

Now as you can see, it is split into 3 main areas:

*   Interface
*   Business Logic
*   Database

A classic 3 tier design. One thing that is very cool about the design is that it is a truly database independent system. You wont find one single stored procedure in the entire system. Instead ACCPAC relies on what they call Views. A view is exactly what it says it is a view on the data; the composition of the view (i.e. table linking, parent-child relationships etc.) are all maintained by the core business logic. As a third-party developer this means, you do not care about any database specific operations because you never access the database directly. Everything you do goes through the ACCPAC business logic, it applies some rules, checks that no rules are broken and then commits the data to whatever database ACCPAC is using.

Another excellent customisation feature of ACCPAC, which I haven’t seen in any other application, save MS Office, is the ability to record and playback macros. This feature records VBA code, which you can then manipulate afterwards or simply playback to repeat the actions you just recorded. Now I don’t have to tell you how powerful macros can be in MS Office, so just imagine the possibilities if you have VBA recording in your ERP system! Another brilliant decision ACCPAC’s architecture team made was to create all the UI forms as ActiveX controls. This allows developers to create their own customized ACCPAC forms by simply dropping the ACCPAC UI control on a form and adding or removing controls at will. Fine, it’s still old COM based controls, written in VB6 no less, but I’m sure ACCPAC will upgrade the technology as they go along.

As of July 2007, Microsoft no longer offers VBA distribution licenses to new customers. Instead they’re offering a new .Net-based language solution know as Visual Studio Tools for Applications. I’ve played with the VSTA toolset, and it certainly is not easy to incorporate into your application, but nor is it impossible.

I was told by the company in question that their chief architect has informed them that it is a lot of work, and that there are thousands of classes in the current code base and exposing all these classes would be one heck of an exercise. I know their architect and do have a lot of respect for him, and I’ve also seen their code base, and it is a LOT of code! Also it is most certainly a mammoth task to retro-fit your application to allow open architecture, if it was not one of the design goals from the beginning. One reason ACCPAC’s API is so successful is because open architecture and the ability to customize ACCPAC was one of the main design considerations from the start.

So what I suggested is to try writing a wrapper for the code base and only including the business objects a 3rd-party developer would need. You also do not need to expose the core business rules. Also, this is easier said than done, but probably one of the easier routes to go.

I’ll play around with some CSLA business objects and see how easy or hard it is to create a wrapper for your code…everything is always easier in theory than in practice. Will keep you posted.

‘Till later, keep coding!