Stephen Smith's Blog

Musings on Machine Learning…

Porting Versus Integrating

with one comment

For Accpac we are a large ERP package with all the core accounting modules, and many third party ISV products all written in our SDK. With this approach all the applications have the same look and feel. They all work consistently and share many system services like VBA macros, import/export, data integrity checking, integrated security, shared signon, same database support, etc. Then Accpac also offers a number of powerful interfaces to integrate with other applications not written in our SDK. With this approach the other application and Accpac can exchange data, create source documents in each other’s system, and do all sorts of look ups and inquires. We have lots of such integrations with ISV products as well as other Sage products like Sage CRM, Abra and FAS.

If writing an application for Accpac from scratch, it makes sense to do it in the SDK for all the above advantages. If wanting to integrate with an existing product that runs standalone and has been developed for years, then it makes sense to do the integration route.

There then seem to be a number of more murky cases. For instance if we want an accounting module from another Sage accounting product, then does it make sense to integrate it or to re-implement it in our SDK using their design as our implementation guide? For instance if we wanted a module from Sage Timberline (like estimating or a more advanced PJC) then does it make sense to install both Accpac and Timberline and run the existing Accpac accounting modules and then run Timberline for the one module we want added to Accpac? Or does it make more sense to start with their developed database schema and re-implement it in the Accpac SDK.

Besides the straight implementation of the database, business logic, UIs and reports, then their is the further problem of possibly tight integrations with other accounting modules like Inventory Control, Order Entry, General Ledger, etc. Will we need to add functionality to these to support the new modules? Will we be able to un-entangle the module we want from all its integrations to other modules in Timberline?

As we move to Accpac 6 and our new web based user interface, we would want all our modules to share the same web based interface. Perhaps if the other product can present its data using SData (our REST web services interface), then we can put Orion UIs on that? But that still leaves many problems with the back end integration. Can SData be used to solve this as well, offering standard web based interfaces between the accounting modules as well as between the web server and the browser based UIs? Or would it be easier to just re-implement the whole thing in our SDK?

Anyway just a few interesting questions to consider as we move forwards.


Written by smist08

June 13, 2009 at 3:32 am

One Response

Subscribe to comments with RSS.

  1. Stephen,

    Some of your words on Accpac 6.0 just kindles the interest. Can you start a separate blog for Accpac 6.0, so that we can know more when the pot is boiling?

    Sundaresan Ramanathan

    November 17, 2009 at 2:13 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: