You can’t turn around in the field of IT today without tripping over “ERP.” Enterprise Resource Planning has been around long enough to have expired as a fad and become a reality that looms over everything, from the job market to the major software packages to most of the training available to you. There’s no getting away from it.
The problem is, everybody slaps the initials “ERP” on to almost everything, till it’s hard to sort out where it really applies. And even a concise definition of ERP has broad implications. What’s needed for developers is a perspective that strips away the non-essentials and provides some tactical direction.
Put simply, Enterprise Resource Planning refers to the integration and extension of a business’s operational IT systems, with the end goals of making information flow within (and beyond) a company more immediate and dynamic; increasing the usefulness and shelf life of information; eliminating redundancy and automating routine processes; and making information system components more flexible. Departmental boundaries generally become softer, accessibility of data is increased for partner companies and customers, and the company’s ability to respond to the marketplace is generally enhanced.
What are ERP’s tactical objectives?
If your company is going ERP, then there are probably several driving forces behind the decision, possibly including: the need to increase supply chain efficiency; the need to increase customer access to products or services; the need to reduce operating costs; the need to respond more rapidly and flexibly to a changing marketplace; and the need to extract business intelligence from data over time.
All of this is fine for the decision-makers, but what does it mean to you as a developer? To achieve senior management’s objectives above, IT needs to make the following things happen:
- Consolidate the databases. One of the most prominent features of any ERP system is that it is built around a “super-database,” or an integrated, all-inclusive data storage system that encompasses all of your company’s operational data. The major ERP software packages convert your in-house databases, usually system- or department-specific, into an interfaced conglomeration of thousands of database tables, integrated more tightly than before. Whether or not you convert to a new database platform, the integration of tables across systems and departmental boundaries is a key step in mobilizing for ERP.
- Integrate legacy apps with new development. Most ERP software systems offer all the standard business systems as canned packages, which you can use if you like. But it’s probable that you’ve got some legacy systems that are so specific to your business that they’ll need to prevail, even if you implement some of the new stuff. That being the case, you need to reconfigure your legacy software so that it will live productively alongside your new applications.
- Make information flow throughout the company. In the past, your IT systems have always broken data down into “master data” and “transactional data.” The relationship between them is simple: transactional data is built out of master data (a purchase order, for instance, is made out of customer information and product information). And master data has tended in the past to be “owned” by a particular department. In an ERP system, the relationship between master data and transactional data remains, but the departmental “ownership” goes away. Most in-house users will have access to most master data, and more transactional data than before, primarily for decision support processes.
- Increase data access beyond the company. For better or worse, the internet is now the tail that wags the dog. Your company is probably no exception! And it’s not just about selling products and services over the Web: real-time data access between your company and your partner companies, the economy of web services for distributed systems, and the convenience of web-based interfaces for systems both remote and in-house have made the need for flexible data access a core architectural component in your ERP development.
What do ERP systems look like?
From what we’ve covered so far, ERP systems take on an overblown “miracle software” fagade: they have to do everything; they have to do it more efficiently than it was done before; and they have to be much easier to modify and extend than ever.
These capabilities aren’t as unreachable as you might think. Broken down into clear specifics, your new systems will have these features:
- ERP systems are non-serialized. Most business processes are “hot potato.” A handful of data is passed along a chain, from person to person or company to company, until all steps have been completed. In the world of ERP, the potato passing is largely automated, and the people in the processes begin to serve a new purpose – that of making the information feeding the processes more accurate and immediate. The resulting systems pass information in many directions, not just one, serving not only the original business process but feeding real-time information into other processes concurrently.
- ERP systems are dynamic. The flexibility of ERP permits extended decision-making in business processes. The linear Step A – Step B – Step C mindset can go away, permitting a far more dynamic If-Then environment. Your company’s IT systems will enable business processes to change direction rapidly when market conditions, customer need or changes in partner relationships demand it.
- ERP systems have many interfaces. One idea that some developers find hard to wrestle with is the idea that applications are no longer bridges between the database and the user; instead, applications are now communications facilitators between systems. Your legacy apps and ERP app components are now more about passing data to other systems, and to users outside your company than they are a means of informing your own staff. In the more “static” pre-ERP universe, people were information processors, so applications informed people. Now, applications inform other systems, and people are decision-makers. So your job in IT is to get those apps interfacing with other systems, as often or more than they interface with people.
- ERP systems are integrated with other systems. See above. Your IT systems’ “audience” has greatly expanded. It is no longer a few hundred people staring at monitors in your building. It now includes human users far and wide, by internet, intranet and other paths, and other systems – meaning that your development team needs to become protocol-savvy, to facilitate the many different connections you’ll now be needing to make.
How do you achieve this? In a word, architecture. The task of IT is to begin building systems on a new foundation, using a new kind of blueprint. First, adopt the following rule: Business processes define database table relationships; database table configurations drive application components; applications drive interface development.
This hierarchy is powerful and effective, as long as you stick to it. Break away, and start redefining database tables to serve apps, or basing apps on interfaces (two long-standing standards from the old days), and your ERP framework will not bear the weight of it long.
The architecture that makes the data-to-interface hierarchy possible has three tiers, all generalized and all designed with convenient access to the next tier in mind. The foundation is the data tier; your company’s databases populate this layer, and a set of generalized (but highly customizable) access components must exist to open this layer to the next one.
That layer is the business tier, where application logic happens. The “guts” of what would be called an “application program” in a more traditional system exist in this layer; however, instead of self-contained, function-specific logic, a business tier is usually inhabited by a great many “components,” or re-usable chunks of business process logic that can be reassembled endlessly into many different applications.
Finally, the business layer feeds the next and final tier, the presentation layer. Interface with human beings, other systems, and the Internet happens in this layer. And, like the layers before it, you’ll be filling it with modular, reusable components that can be recombined into a wide range of interfaces, riding a broad spectrum of protocols.
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.
From the day senior management makes the ERP call until the transition is complete (typically a very long period), IT developers will tackle the following projects:
- 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.