From: Joe Pluta
And to me, the biggest question is a fundamental one: do you
need to modify your software?
To answer that, just consider the smallest of companies and other organizations you know of who may have "package" ERP class applications, but also employ part time technicians to set up and maintain Access databases and Excel spreadsheets, which may duplicate data in the "package" - but offer a means of customization. And when evaluating a package, the organization gives added weight to its data export and import capabilities.
That unfortunately creates little islands of experts who have their own data stores that may cover valid needs, but may operate under the radar, or expose security vulnerabilities. Where are the Social Security Numbers? Well, they're on Dave's notebook, and unencrypted. Or leads to misunderstandings as data conflicts arise, or where databases are not synchronized, or questions arise over data ownership. Add to that the cost of managing disparate systems.
A package vendor may not offer source code. Or the source may be available, but priced high enough that it's out of reach. In that case, consider what options are available for maintaining a centralized database, and centralized authentication and authority, and a centralized menuing system, but enable organizations to seamlessly integrate with, and extended the package.
That's one advantage of using Web technologies and running applications under a Web portal. The client is the browser. Browser plugins offer rich capabilities like PDF and Flash support. Your server extensions may be written in RPG, or PHP, or Java, or whatever your expertise is with, but may reference a common style sheet from the "package".
You may not need to change the package source code. You just plug into it's authentication, authorization, application definition, menuing system, application deployment system, style sheet, and database.
Nathan.
midrange.com
