As long as I can remember there have been fierce arguments about the relative merits of installing software application packages versus developing applications in-house. It has never been a simple decision and we have seen over the years a lot of swings favouring first one approach, then the other, etc.
This inevitably creates a problem because it takes such a huge effort to implement any new application, package or locally developed. The software itself is in practice a small part of the problem compared to the training and the database administration. Thus there will never be a totally stable situation; there will be a mixture of old and new, which means that there will be mixtures of package and in-house applications.
Currently the package approach is the high profile one. It is obvious that for small and medium sized companies it is impractical to employ the staff to develop programs in-house and packages are the only answer today, but not necessarily so in the future when component technology matures. On the other hand, enterprises were faced with far more complex requirements (this claim is always made, but it not so obvious as to why a bigger company needs more complex applications in all cases). Thus the bulk of applications were tailor made in-house. Because of the scale of the investment, the larger corporations built up large data processing departments, which are a considerable overhead. They also developed specific skills around their own preferred development tools. This represented a big investment in development machines, software tools and staff skills. For various reasons though over the last ten years or so, much of the in-house developed application software has been replaced by packages, specifically those which integrate a variety of functions into a common database, referred to as Enterprise Resource Planning (ERP) systems. In fact these packages offer very little new functionality, but they were brilliantly marketed, mostly by SAP, extolling the virtues of "integration" and pushing the modern technology, particularly the client/server architecture. By recognising the failure of thick-client architecture from the beginning, SAP got it right and with their thin-client systems managed to push other package vendors such as MSA out. They also managed to get enough mind share to persuade enterprises to get rid of in-house development as well and to replace the bulk of the applications with the package solution. Unfortunately this was achieved as much with high profile marketing as with any real benefit, and it was done behind the backs of the IT departments in many cases
All is not well, it hasn’t worked out as it should. Most companies having committed to the new ERP concept found out too late that it was incredibly expensive. The consultancy companies made fortunes "helping" customers to implement ERP packages. But because no two companies requirements are the same, the tailoring that was needed during and after the implementation was substantial – and costly. But worse was to come. Two new concepts came on the scene before the ink had dried on the ERP contracts, first Customer Relation Management (CRM) and then e-commerce. The "integration" promised by ERP was instantly exposed as a sales ploy.
Needless to say the package vendors and the consultants have seen these new problems as opportunities and have produced new modules to add to the installed systems. But CRM should be based on a data warehouse that has data accumulated from all possible sources in the Enterprise, not just that in the ERP database. In an ideal world the data in the ERP system should be used to feed the data warehouse, something that proved difficult because of the proprietary nature of the database supporting the ERP system. Note that the problem is access to the logical data, not the RDBMS supporting it. Electronic commerce is even more difficult to integrate with a client-server application, since it must be based on Internet standards and message-passing in some cases. This means that the e-commerce applications are basically independent sub-systems, which must be integrated with the ERP systems. This of course is practical, but it requires a new suite of EAI applications, based on Web Application Servers such as WebSphere, etc. These must be interfaced to existing applications (the new ERP system is a legacy application already!), which means that the APIs to the application must be exposed. With an ERP package these APIs are available, but only at a price. Now if you only had applications developed in-house, then …….
