JD Edwards business-level Traps

Photo Credit: Wikipedia
"How do you eat an elephant?
One bite at a time."
— Creighton Abrams
Implementing JD Edwards EnterpriseOne is sort of like buying a used Jet Plane for your business. It's big and complicated so you need help just getting it to fly. Because it was previously used by other companies all over the world you need to customize it for your business. Then, once you've got it in the air, you need to maintain it to keep it airworthy.

Rational executives hire a team of experts to help them with these tasks - but how do you communicate with these experts if you know nothing about Jet Aircraft? Obviously you need to crack the books open and start reading. Can you do that with JD Edwards? It's not easy as the available books are all highly technical.

Some months ago I was asked to work on a project that indirectly involved JD Edwards EnterpriseOne. Circumstances forced me to get far more involved with JDE than originally expected. Along the way I learned a few things that I'd like to share with you. Most importantly:

  • Oracle Licensing is a serious matter and it's far from simple.
  • JD Edwards development methodology must involve best practices and must be experience driven.

Oracle Licensing

As I'm not a lawyer I don't really want to say anything about licensing - but I must tell you that it's not as easy as it looks. In theory you just call your Oracle Rep and negotiate a license. In practice you are signing an agreement that is full of little details that don't seem important at the time of the negotiation.

For example: How many CPU cores do you have on your Enterprise Server? You don't know? Ask your System Administrator and he'll tell you. Of course, next year, that number might change. Your System Administrator might email you to let you know that he upgraded the server because people were complaining that it was too slow. The license management software on the server will report this change to Oracle and they will (eventually) send you a bill.

The above example sounds reasonable but the issues that can trigger a license fee increase are numerous and not always obvious to the licensee. Here is a link to an article that covers the subject in greater detail from a company that specializes in Software Asset Management:

Top 60 Licensing Pitfalls For Oracle Databases And Oracle Technology Products
by Friedrich Florea
Operations Management Technology Consulting GmbH

Note that, as your development team is customizing JD Edwards for your business, you may find that the developers will trigger changes in your license fees. The simple solution is to talk with your Oracle Representative - early and often - and make sure you get everything he says in writing. Get this paperwork out of the way early so that you can make intelligent decisions about your next development cycle.

Remember: There are always lots of good solutions to any problem. A little early effort can help your analyst design a solution that meets your needs while respecting your license terms and budget.

What's the worst thing that can go wrong if you are not paying attention? Simply put: Oracle can stop you from using your JD Edwards system until you settle with them.

JD Edwards Development

The sheer size and complexity of a JD Edwards installation forces every company to hire a number of consultants to help with installation, maintenance and customization. Each of these consultants is an expert in his domain but is forced to participate in many JDE activities. As a result you get, for example, guys with a background in BI Reporting providing advice and assistance with software development. On the surface it looks like things are moving forward. In the long run, though, there is an accumulation of small mistakes due to the errors that creep into the business process. The most visible consequence is that work must be done and then undone and done again.

There are many people involved in JDE implementations who do not understand the internal structure of JDE. It seems that they are often repeating phrases found in the JDE Literature without properly considering the related issues - and making decisions based on their misconceptions.

One phrase that has been repeated surprisingly often is: "JDE Business Functions protect the JDE System from [the perceived threat du jour.]" It's a nice idea and, in cases where a built-in JDE Business Function is being properly used, there is truth in it. Unfortunately the Oracle Provided Business Functions can also be misused. Worse: custom business functions can literally do anything and, in many cases, are coded to update database tables directly. There's nothing wrong with that as long as there is a solid business process behind it and best practices are being followed along the way.

Unfortunately some people set aside best practices and rely on the friendly and encouraging promises that we find in the Oracle Literature. Unfortunately those are really statements that must be understood in proper context: The Business Functions are an Application Programmers Interface (API,) and they do the work that they are designed to do. They do not perform any special magic and, as such, they can't take the place of proper software development methodology or common best practices.

Business executives should not believe that they are getting some mysterious value in exchange for making a grand effort to force everything to go through the Business Functions. Lots of code must go through the Business Functions anyway and the Grand Effort really is grand - but that's because the JDE API consists of 14M+ lines of code and comes with very little documentation - not because it is some kind of magic black box.

If you can find a serious developer who is willing to document his work with the API and the database you will find that your work progresses and your maintenance costs go down over time. If you don't do your homework, or you fail to make sure that your staff is following best practices, you will find yourself paying over and over again for maintenance on the same issues and the costs will not go down over time.