A Developer's Overview of ERP, Page 2
What is the developer's role?
In the past, the developer designed stand-alone apps and the database tables that serviced them. In an ERP environment, the developer becomes a specialist in the components populating the various architectural tiers, in the relationships between the myriad database tables, and in the links, sprocs, and triggers that make them dynamic.
In addition, the ERP developer must know data communication and transport, which will often contain involve more than a little web technology, and is well off to know the most common protocols.
- Complete IT platform revision. There are two main scenarios an ERP developer is likely to face. In the first, your company is implementing a huge ERP software system from one of the big vendors, with canned applications and database table structures. In the second, you're being asked to create an ERP environment to encompass existing application systems and facilitate the development of new ones. In either case, your number-one task as a developer is configuration, which means a great deal of thought and planning regarding the redesign of your business processes. In a canned ERP world, you'll do a lot of embedded procedures in database tables, and configure a great many application links. In an ERP development environment, you're going to be writing a lot of app components and data transport containers to move information tier-to-tier.
- Implementation of a component-driven application environment. As a developer, you'll now be focused on balancing application logic between the smallest chunk of code that performs a complete operation on a data object, and a level of functionality that makes such a piece of code useful to multiple applications. If you have canned ERP apps, you'll have a full library of these to play with. If not, and you find yourself writing new app components from scratch, it's often a good idea to scrutinize your legacy apps to see what common denominators exist - you may end up re-building those apps in the long run anyway.
- Reconfiguration of databases. The old top-down hierarchies are dead and gone. An ERP database table configuration is endlessly complex, encompassing links between data items that stretch "relational" until it screams for mercy. Such links can, in a deeply integrated environment, seem almost infinitely lateral, meaning that a developer must pay more attention than ever to the full impact of table update. Fortunately, you have powerful tools at your command: embedded triggers and stored procedures can now do the work of ensuring data integrity and validity.
- Development of new interfaces. It's already been said: protocol, protocol, protocol (learn all the network security you can, while you're at it). But don't miss the shortcuts and conveniences along the way. Web services in particular are there to convert data from one flavor to another and to provide context-specific reference data, and the various dialects of XML specifically exist to give you a fast leg up in passing business documents in neutral formats.
What tools are available to developers?
I remember an era when my IT toolkit included a text editor, a compiler, and job control language - nothing more. The ERP developer, on the other hand, has more tools at hand than will ever be used. These can include:
- ERP software packages. If your company is buying SAP, Oracle, PeopleSoft or some other mega-system, don't think for a minute you're about to be automated out of a job. On the contrary, there is so much work to be done, configuring the canned business systems provided in those packages, that many companies hire a small army of expensive consultants to look after those basic systems so that the in-house talent can be focused on IT systems that differentiate the business. Whatever your company is doing personnel-wise, there is much work to be done, fine-tuning ERP to optimize database table relationships, customizing and extending applications, and developing new interfaces. To this end, every major ERP package has a suite of developer's tools for these jobs.
- ERP development environments. Perhaps your company isn't going with a big ERP package, but prefers to re-platform your existing application systems on, say, J2EE. These technologies are often open-source, meaning that developers have an almost endless range of choices in development environments and toolkits.
- New database technology. Any developer who overlooks the technology embedded in most databases today is sliding toward unnecessary overtime. SAP, Oracle, Microsoft and other database vendors all offer products with sophisticated procedure options that allow developers to initiate complex operations upon the occurrence of most database events. Updating a table can trigger processes within the database, set applications in motion, cause updates in other databases, initiate communication with users, and even trigger remote procedures in external systems.
- Web technology. There is so much great web technology out there today, optimized to service an increasingly voracious internet user community, that it is literally possible to create and grow a substantial ERP system using only web technology components! These include web services, CSS (cascading stylesheets) for rapid user-specific customization of interfaces, and DOM (document object model) for sophisticated user-specific client-side processing features - all highly appropriate and powerful tools for extending ERP systems.
Page 2 of 2