Oracle EBS Technology Review [Draft]

When I started supporting Oracle EBS I could find little summary information that answered technical questions. So I thought I’d try and capture the technical essence of the product and with hindsight answer some of the questions I originally had. I aim to do this over just a couple of pages.

Oracle E-Business Suite is a comprehensive collection of enterprise resource planning, customer relationship management and supply chain management software. This functionality is split into various modules integrated to a greater or lesser degree on a single platform. The product is very widely implemented across thousands of organisations in many counties. Viewed as somewhat legacy in nature Oracle is continuing to extend and maintain the product. The latest version, 12.2, contains technology from, and a path towards, Oracle's leading edge technology ‘Fusion’. Unlike some of the application suites that Oracle has acquired over the last 10 years it continues to successfully sell EBS.

The Oracle applications division was foundered in 1987 and the software that forms EBS originates from that time. The different parts of EBS have been created and extended by teams across the world ever since then. It would be interesting to know what the oldest technical elements are of the current release. But the main issue from a support perspective is that different parts of the application will have been implemented using different tools and technologies. They have evolved using different design approaches and standards. For example some of the core HRMS modules have been written using PL/SQL and Forms and have a common debugging framework that experienced technical supporters will be able to use to help diagnose problems. Other modules such as finance have evolved over a similar time period but code elements are not built using the same approaches and debugging framework as HRMS. The self service parts of HRMS were written many years later using evolving technologies particularly in the user interface elements.

It is very much a suite of applications and technologies rather than an integrated product and unlike some other enterprise software it can only be run on an Oracle database. There are a number of advantages of being tightly integrated into a database. The main one being that code can execute within the database. This can lead to massive performance improvements compared with transferring data within a client server architecture. A key drawback is vendor lock-in and a proprietary drift away from standards, an example being SQL syntax changes.

Oracle forms runtime discussion here. Master data, transaction data, meta data, configuration data

Large teams comprising people with many different individual specialties are required to implement and support the product. This is one reason for the often long turn around times for changes on such projects. Another is often the lack of knowledge by test teams and approvers of the detailed nature of such changes.

It has evolved and dragged a lot of technology with it since 1987. It’s successful because it is successful with wide adoption across many different types of medium and large scales enterprises. There is a large community of literate users and technical supporters. Oracle is a very healthy company with a presence in many countries. It is a huge product, one person can only know a small subset of functionality or technology. In comparison to PeoplesSoft where over the course of 3 or 4 years it might be possible to have an in-depth understanding of the technology and a sufficient grasp of various functional modules to be able to resolve most problems in a time efficient manor – at least with HRMS.
There is no bundled debugger Support difficulties. Greater emphasis on configuration, via flex fields, fast formula (PL/SQL type code triggered from pre configured points in the systems) rather than customisation. For example in payroll.

The Payroll module is a closed box. In fact only a very people in Oracle fully understand how it works. Oracle does not allow more than two of these people to share the same aeroplane.

One of the first things that will surprise a first time ‘power-user’ or technical developer are the two different ways of interacting with the application from their Office PC. For the most part application functionality is accessed via one of two types of clients. The professional client – which is a ‘fat’ client environment and a thinner html based client. This can result in a some what jarring application experience. For example most of the screens used to hire a new employee are written in Forms but at the point where you enter a new salary a HTML page is spawned that fills the screen. Data entered on this page must be saved separately from the data saved in the forms based page.

The HTML client is delivered by OAF. This is a Java based framework that delivers all the security, a standard look and feel, etc, The tool used to produce and extend this is Oracle's Swiss Army knife JDeveloper.

to be continued.