EA Voices

Packaged Applications (such as PSFT, eBiz, etc…) are the very operational heart and soul of most companies.  Whether it is human capital management, logistics, sales, or any number of other fundamental applications – they are most valuable when they are customized to fit YOUR business and integrate with YOUR systems.  The problem is that these customizations and integrations are most often done with built in (proprietary) tools or using things like PL SQL, batch files or other less-than-optimal (often proprietary) solutions.

Enterprise Architecture steps in at this point because the move from one major version to the next is a major undertaking for most companies; one that takes month (sometime as much as a year) to plan and implement.   When the applications have been customized to meet the business’s requirement, these very customizations make upgrading more complex.  One of the tasks of EA is to establish guiding principles which help shape decisions at every level of the architecture.  One key principle here is “Keep COTS Packages as Vanilla as Posible” – meaning do as little customization as possibly directly in the application itself.  The more vanilla the application is kept, the easier it is to upgrade.

It is a best architecture practice to place these customizations in the middleware layer where standards such as Java, Web services, XML, and the like mitigate the risks of using proprietary technology.  They also provide a more comprehensive and faster-development-lifecycle framework for integrating with the entire corporate IT ecosystem while greatly enhancing the possibilities for service/integration reuse.

So, with all that being said, a common question I get is “OK, where do we draw the line between using the built-in tools vs. using a middleware layer?”  This chart helps answer and provides delineation between the reasons to use one approach over the other.  Though not exhaustive, it should provide a framework for figuring out which customizations/integrations should go where.