4 Ways to Make your Packaged Application's Customizations Upgradeable

Too often the Buy vs. Build argument get turned on its head when enterprises who buy a packaged solution to save money, end up spending more customizing it to fit their business' needs. When I say packaged here I am referring to things like ERPs, CRMs and even newer SaaS based applications. Customizing packaged apps is expensive since you often need proprietary skills and knowledge to make any changes. It gets even more expensive when it comes time to upgrade and many of those customizations need to be refactored or rewritten.

The reality is, no packaged app fits an organization like a glove, so some level of customization is expected. The blog below is meant to suggest some basic best practices for customizing packaged and SaaS applications.

1) Architect your Customizations - Encapsulate into Services
Too often developers don't think about architecting their customizations and instead, just slam some code into the packaged product. Customizations should be built as plugins, something that can, for the most part, stand on its own. I typically suggest encapsulating any business logic in an external REST service running on your enterprise's native application architecture (i.e. C#, Java, C++, PHP, etc.). Assuming it's a web based app, encapsulate custom presentation logic in an embeddable HTML or Javascript file. Ideally, embedding that file would be the only line of code that will need to be customized (plugged) into the packaged app. AJAX calls can be used to communicate between the custom presentation and the external services you write.

2) Avoid Use of Proprietary Customization Languages and APIs
Using proprietary languages for customization (i.e. Peoplecode, ABAP, etc.) will ultimately lead to pain later. Proprietary languages are typically procedural (or used that way) and aren't maturing at the same speed as industry standard languages are. It's often faster to build in external languages. The SDKs for the proprietary languages are evolving however, so upgrades usually require some level of refactoring. In general, what these languages were intended to be used for, and how they actually get used, varies widely. For basic data retrieval, processing logic and presentation, try to stay away from them. If you have to utilize a particular API because it contains some proprietary logic, encapsulate it in a single service, so you can minimize refactoring later.

3) Utilize Asynchronous Processing Where Possible
Customizations in packaged application often lead to performance problems in the app as a whole. The reason is packaged apps' application container's are often configured to run the native packaged application and basic customizations. The container's threading models are often not tuned to support large amounts of customized code (particularly those making calls to external systems). By utilizing the approach in number 1, you're utilizing the power of the browser to handle external calls to retrieve information. In cases when you need to make calls from the packaged application's server (i.e. to perform updates to external systems ), try to utilize asynchronous messaging for passing off requests. By utilizing a MOM like MSMQ or Websphere MQ, your taking a considerable amount of load off of the packaged application. You'll need to build some external services to handle any potential errors or issues that come out of the external updates, but this is a small price to pay compared to trying to debug issues occurring within the black box of a packaged app.

4) Keep the core-competency of the packaged app in mind
Too often business users will push to have more and more functionality layered into a packaged application. This bloats the packaged app, makes upgrades difficult and most importantly, limits reuse and accessibility of that functionality from other enterprise systems. By keeping custom functionality hosted outside of the packaged app, you're on your way to building a more service-orientated environment where the packaged app is a consumer of those services, and not the host of them. Portals and BPM applications can be used to string together those services (and those of the packaged app) into composite applications that are specific to a particular business. In general, use the packaged app for what you bought it for and don't try to turn it into something it is not.

Those are a couple of my thoughts, tell me about your experiences? How have you future-proofed your packaged app customizations?

This blog was also picked up by CIO.com

Utilizing Today's Technology to Formulate a Sixth Sense

Really starts to get interesting and practical around the 4 minute mark. Very impressive. Enjoy!

4 Things to Think About: Identity Management for SaaS Apps