Oracle EBS

The Essential Business Guide

Why does this Oracle EBS guide matter to your enterprise?

If you’re reading this guide, chances are that Oracle E-Business Suite, or Oracle EBS, plays a critical role in your enterprise. Oracle EBS is likely the hub of much of the real-time transactional data and processes that underscore the heart of your business.

Because Oracle EBS can hold the keys to your enterprise’s success, it’s crucial that you understand the issues with Oracle EBS, learn how to leverage the application to its fullest, and find opportunities to be both more efficient and intelligent with your ERP solution.

Why should you care about the impact of Oracle EBS on your enterprise?

Your Oracle EBS application records thousands of real-time data entries and transactions at every level of your enterprise.

So, whether you’re the head HR, director of IT, or manage operations, you need to be able to make informed and strategic decisions based on data from your Oracle EBS. You need a solution that can help you translate ERP numbers into actions that positively impact your enterprise’s performance.

When your Oracle EBS application is working for your enterprise, you will see:

R

Increased Revenue

R

Improved Efficiency

R

Business Intelligence

Unfortunately, Oracle EBS can be difficult to use. It’s not always modern or user-friendly. For the most part, Oracle EBS can be difficult to use and quite unwieldy. It simply does not produce at-a-glance visualizations of your business-critical processes and data.

Of course, this is issue that impacts enterprises. There are other drawbacks to your Oracle EBS ERP, which we describe in detail later in this guide, as well as potential solutions to these problems.

Who will benefit from this Oracle EBS business guide?

We’ve established that Oracle EBS can potentially touch every department of an enterprise. That’s why this guide could be useful for anyone in the both the line of business and IT. Let’s consider some likely scenarios.

=
As head of finance, you’re stuck in constant reporting cycles. With your current Oracle EBS setup, you find that your enterprise cannot forecast and effectively guide the company on strategic objectives. In this case, it’s important to find a solution that allows you to:

  • Share reports via modern dashboards that track performance and progress against business and financial KPIs.
  • Drill-down into complex data sets to identify opportunities and issues.
  • Set up automations and workflows that reduce errors and meet compliance requirements.
=
As the leader of the IT team, you’re constantly putting out fires. It’s impossible to constantly pull data from Oracle EBS for each and every department and provide it ad-hoc. That’s why you need a solution that:

  • Provides a self-service option for each department, allowing you to focus on key IT growth and improvement initiatives initiatives.
  • Avoid outdated ERP tools. Instead, you need a solution that offers comprehensive, at-a-glance visuals that effectively communicate company performance.
=
As director of operations, both supply chain management and juggling your workforce can be a hassle. To do your job more effectively and save the company millions in work hours, your Oracle EBS application should offer:

  • A real-time look into labor costs, workflow efficiency, margins, and more.
  • Immediate workforce management visibility that keeps you on track for reaching company goals for profitability and compliance.
  • Access to mobile dashboards that keep you and the line of business informed no matter where you are.
=
As a human resources professional who manages hiring, training, and turnover, you need complete access to employee data without having to ask IT for help. Your ERP needs to offer:

  • The ability to make strategic hires, quick decisions, and see departments’ workforce needs at a glance.
  • The chance to stay ahead of your competition and get the best talent with self-service portals that allow industry leading talent to submit their resumes.
In this handy Oracle EBS business guide, you’ll learn how to make the most out of Oracle EBS. We’re here to help your organization identify the common issues with Oracle EBS, and identify options for migrating or transforming your EBS system into a modern, top of the line solution.

How to Use This Guide

We’ve tried to make this (admittedly long) guide as user friendly as possible. Look for these icons throughout the guide to get an at-a-glance understanding of the topic and how it will benefit your enterprise.

About EBS

What Is EBS?

Oracle E-Business Suite (EBS) is one of Oracle’s most successful software solutions. At its core is a financial application developed by Oracle UK in the late 1980s, and which has grown and elaborated ever since. Today its inner workings have changed so much that it looks nothing like the original – and indeed, it is no longer just one system. Rather than one single application, EBS consists of many separate applications that depend on a common runtime stack and which follow broadly similar conventions for interaction, customization, and configuration.
Oracle grew the EBS footprint and feature set through several methods. Notably:
K

Oracle’s internal teams developed new applications for it to meet new market needs over the years, especially for service industries and manufacturing

K

Oracle refined the features of the applications within it in response to evolving patterns in the tech industry

K

Most notably, Oracle acquired smaller software companies in order to embed their applications into it, thus increasing market share and eliminating competitors

Each major release of E-Business Suite encompasses feature upgrades of this kind. If you are an E-Business Suite customer, your ongoing licensing costs pays for these improvements.

And just who is an EBS Customer? E-Business Suite is intended to be a one-stop software and operations shop for large scale enterprises. Large organizations have many common business processes and areas of concern, such as accounting, human resources, logistics, and order management. Rather than implement a patchwork of different applications from different vendors to fulfill these needs, Oracle offers E-Business Suite and its many applications to cover these functions and more:

Z

Oracle Financials

Z

Oracle CRM

Z

Oracle Supply Chain

Z

Oracle Logistics

Z

Oracle Order Management

Z

Human Resources

This way, one database technology and common suite of applications can be used to drive an entire enterprise. You can rely on one major technology vendor for all your needs, and rely on them to have technology answers for the various business scenarios you may encounter.

After all, Oracle is in the business of helping businesses run with EBS, and should be well-positioned to be the experts of your system. This keeps you from managing a heavy contact book with many service vendors, application developers and suppliers who each add a different piece of your architecture, and who can’t be relied on as a group for your overall enterprise software environment.

With E-Business Suite, you have one expert partner for it all. Sounds great, doesn’t it?

Who Uses EBS?

EBS was assembled with a diverse enterprise user base in mind. This includes a variety of business units:

Human Resources

Timesheets, payroll, benefits management, and more are enabled by the EBS Human Resources module, which becomes a significant asset to running this aspect of enterprise operations.

Finance

Extensive modules for tax compliance, account management, accounts receivable and payable, risk management, analytics and more are built into EBS’s Financial Management module.

Sales

Customer relationship management, product and order management, price configurations, sales performance, and margin calculations are available through EBS.

Operations

Product life-cycle management, supply chain management, logistics, and both discrete and process manufacturing modules are all available extensions to EBS. This allows industry players to begin with an appropriate template of core operations logic to shape to their specific needs.
This also includes a variety of work roles:

Floor Worker

Industry-standard time entry, human resources and IT service management for floor workers are all available through EBS. This means that teams working in offices, retail, factories, and assembly plants are all able to plug into a common set of tools that help them work with their employer’s ERP.

Manager

Thanks to the Oracle Reports and BI Publisher integrations, managers from all departments are able to rely on EBS for reporting data across departments and functions in the enterprise.

IT

Members of IT maintain, support, configure, and productionize a variety of features for many different business units with EBS as the common backbone.

Executive

In its traditional capacity, EBS is able to provide enterprise data to executives through reporting and extensions into dashboarding and business intelligence systems.
And a variety of integrated functions:

Enterprise User Management

EBS integrates with other Oracle tools for enterprise user account management. This allows you to track user identity, permissions, and organizational roles across all the different apps in the ecosystem, simplifying administration of users within those systems.

Workflow

EBS makes it possible to orchestrate some user tasks and workflows across the network of applications, in addition to task automation. These features tend to rely on custom coding and other custom extensions, but the framework for the logic is present.

Compliance

Large enterprises that employ team members, own operations, and do business in multiple states – or even countries – benefit from the compliance features of EBS. Especially with respect to Oracle Financials, the ability to configure and enforce the legal realities of doing business comes built-in.

What are the Benefits of EBS?

The Value of an ERP

As you can see, Oracle E-Business Suite is no small application. It’s an Enterprise Resource Planner (ERP) that integrates and orchestrates many common facets large-scale enterprise operations. It may seem like an ordeal to encompass so many features, users, processes, and requirements under the heading of one suite of systems. Yet this all-in approach has its benefits.

Vendor Support

If all these major functions of running a business, creating sales, optimizing operations, and coordinating staff are a daunting effort, they are made more challenging if the applications to support them are handled by a large number of separate, un-coordinated vendor relationships. Running your operations with software from one vendor allows you to merge, streamline, and scale your business relationship with outside supporting entities.

Feature Roadmap

Just as your day-to-day operations may be more integrated when you rely on one master platform, so too can you rely on a coordinated, high-level upgrade pathway. An IT department that coordinates versions and incremental changes from a variety of software vendors are forced to chart their own future in terms of adopting and upgrading to meet new requirements from the business. But with one platform as with EBS, you can rely on a more cohesive feature roadmap. Whether you take advantage of all these features is another story – but you at least have a strong baseline to address the common needs of your business units as your enterprise evolves and scales.

Consistency of Technology and Documentation

The searchable Oracle E-Business Suite Documentation Web Library contains comprehensive documentation for Oracle E-Business Suite global business applications. You can use the Oracle EBS library to review and download the latest documentation by department and need including CRM, financials, projects, procurements, and more.

Variety in EBS Services

Paid Support

Oracle EBS is supported by Oracle with paid Premier and Extended Support options. This means that they’re providing updates, new features, bug fixes, and quality of life improvements to their license holders.

Oracle has also announced an upcoming major update to the Oracle E-Business Suite roadmap. Their goal is to add a future release after the current 12.2 release. While they have not yet announced a date for the big EBS release, they have committed to providing Premier level support for this release through at least 2030.

Premier Support Through:

Release 12.1

December 2021

Release 12.2

September 2023

Release 12.X

At least 2030 (minimum 10 years)
Upgrade Services

If your enterprise is operating on an older version of E-Business Suite or your looking to adopt upcoming new features, it’s a good idea to seek EBS upgrade services starting right now. Learn more about how PITSS can help your enterprise here.

A Customizable, Self-Contained System

If it’s possible to customize consumer goods that are mass produced, then theoretically you should be able to customize something critical as your ERP system, right? However, just because you can fully customize an ERP, should you?

Customizations are prevalent in many E-Business Suite shops. This makes sense as Oracle has focused on adding host of personalization features over the years. These features allow you to add branding, logos, and corporate colors to your EBS screens, as well as other customizations.

These types of personalization are metadata-driven. They’re persistent. This is the primary benefit of using the standard EBS personalization features—changes remain if the underlying screens are patched later.

However, your enterprise might have a unique service, process, or product that requires a non-traditional method of data capture, integration, or workflow. In fact, this type of customization may differ from how EBS developers intend the application to function.

To accomplish your new business need, you may need to deploy Oracle EBS in a new architecture, system configuration, or even apply a service layer. Though E-Business Suite’s personalization features are very useful on the surface, they simply won’t be able to meet these types of specialized, in-depth business requirements.

Understand Impacts of Customization

It’s important to consider all of the potential implications of a customized Oracle EBS ERP. Whenever Oracle issues a new release, patch, or, feature, your ERP may be at risk. That’s why it’s crucial to begin with a sound infrastructure, as well as employ the help of expert architects.

Before embarking on an Oracle EBS customization project, take the time to fully analyze the advantages, disadvantages, and possible outcomes of customizing your the E-Business Suite to incorporate your specific business needs. There are many options to customize or extend your EBS environment including:

=

Business Rules

=

Data Transformation

=

Custom Screens

=

Integration with Third-Party Apps

=

New Reports and Workflows

Consider the invasiveness, development time, and cost of all of these customizations. Remember, the more invasive the modification, the greater the long-term impacts on your enterprise.
R

Customization Advantages

  • New and Exciting Functionalities
  • Meets Unique Business Requirements
Q

Customization Disadvantages

  • Can Be More Costly
  • Requires Development
  • Needs to be Fully Tested
  • May Need Special Maintenance
  • May Be Critically Impacted by EBS Patches and Releases

What are the Drawbacks of EBS?

Vendor Lock-In Dictates Your IT Partnerships

Vendor lock-in, sometimes known as proprietary lock-in or customer lock-in, makes a customer “dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.”

Cloud vendors in particular seek to make the cloud simpler for their customers, resulting in vendors developing their own database services. For example, AWS has RDS and Microsoft has Azure DocumentDB and Azure SQL Database. Sure, these database services are helpful, but they’re all representative of the problem of vendor lock-in.

Oracle EBS is no different. Surprised? Think of it this way – EBS is designed to be an all-in-one ERP. That means it covers a huge waterfront of business features and operations. And all the software to execute those features, in the most important ways, belongs to Oracle. The database where your business data is stored, the application servers used to host EBS, the languages the business logic is written in, the frameworks and tools you use to customize and extend EBS – with remarkably few exceptions, they are all Oracle products.

This means it’s impossible for you to keep EBS – and potentially a huge slice of the software that drives your business – without Oracle. You’ll need them for their expertise of their own product, for patches to improve your software security and for new features on the roadmap that Oracle also dictates.

You’d better like the relationship you have with Oracle, because you’ll be relying on it quite a lot. Any effort to keep the software but distance yourself from its creator will never be completely successful – you’ll always need Oracle, or service partners who are one step removed from them.

Monolithic Architecture Closes Out New Technologies

What is monolithic architecture? It’s actually the traditional merged model for software design. Here, “monolithic” means composed in one piece. This type of software was designed to be self-contained, interconnected, and dependent.

In a monolith, the architecture is tightly coupled, so each component and associated components must be present in order to execute code. Therefore, in monolithic architecture if you need to update any program component, then the whole application has to be rewritten.

In contrast, more modern modular software architecture is usually uncoupled, allowing it to be more flexible and allows for more integrations. Modular applications can be changed without drastically affecting other elements of the program, reducing the risk that any single change could create a ripple effect of problems elsewhere.

So why is Oracle EBS considered monolithic?

As discussed in previous sections, EBS is a stack of several Oracle proprietary technologies. In this configuration – where one party has total control of the entire application ecosystem – there aren’t many incentives to *not* be a monolith. That supposes a universe in which the database might not be Oracle’s, or the business logic may not be Java.

Conversely, by relying on the tightly coupled nature of these technologies, built side-by-side, Oracle can tout some benefits. This monolithic style delivers high-speed results to your users, because Oracle Forms – a very monolithic user interface technology – maintains a stateful connection directly to the database.

There’s no service layer in between to slow things down. But that also means there’s no service layer to make either the DB or the UI swappable. Instead, the user interface is attached by a web of numerous direct connections to the business logic layer, which is itself attached to the database in the same way – numerous, small, tightly-coupled connections that require the database to be a very specific product, version and structure.

This is the definition of a monolith – there is no such thing as an isolated change.

Technical Debt Writ Large

To put it mildly, Oracle EBS is a framework that has years of built-in technical debt. When we say technical debt, we mean that outdated and disorganized information and code can easily build up in your Oracle EBS environment.

So what does this mean for your enterprise? The technical debt found within an EBS framework can mean more lag, inaccuracy, and inefficiency. Your enterprise should have a strong strategy for addressing and cleaning up technical debt, as well as for clean data management moving forward to avoid these problems in the future.

Poor Documentation

Many enterprises experience the problem of poor documentation within their business-critical systems, and Oracle EBS is no different. Proper documentation within your EBS application matters because you need to be able to:

  • Track decisions
  • Understand the reasons behind changes
  • Track changes
  • See the scope of work
  • Plan for future development needs
  • Educate end users
  • Identify opportunities for improved efficiency

To solve the complex issue of poor documentation within your Oracle EBS application, first create a strong standard for documentation at the start of your project. Hold all team members accountable for adhering to documentation requirement standards. Good documentation practices will improve development costs and outcomes in the long-run.

How EBS Fits into Your Overall Digital Future

Migration and Integration: A Primer

[insert text here]

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

EBS Migration Options

Understanding the complexity of your code will help an EBS project succeed; it will be easier to develop new functionalities on a clean surface than trying to deal with the bulk of your EBS code and customizations all at once.

The first step and the quickest way to get a clear picture of your Oracle EBS code is to perform a legacy code analysis. The right tool will provide visualizations for:

Process dependencies

UI Navigation

Database tables, relationships, and triggers

User interaction and usage

These visualizations rapidly identify crucial business processes and their relative complexity, allowing stakeholders to quickly carve the project into manageable, individual modernization efforts.

An effective code analysis tool will look for dead or unused code code, focusing on clusters of functionality. This allows application re-engineering to happen naturally; developers can easily see where code can be consolidated with low effort and high return.

The Prioritization Matrix

With a clear picture of your EBS code, dependencies, and functionalities, now you can begin plotting on a prioritization matrix.

So what is a code prioritization matrix? In short, it’s a simple graph that helps sort applications or business processes by order of value and importance. In this case, this prioritization matrix shows where business value relates to the effort of modernizing those applications or processes.

Re-Engineering Zone

High business value but low non-functional or operational performance applications fall within this quadrant. These applications or processes are suited for re-architecting, re-platforming, or integration with emerging technology solutions such as mobile and cloud platforms.

Replace or Retire Zone

Applications that fall in this quadrant have lost significant business value, features, or technical quality. The goal here is to move any remaining useful features, rules, and data to another platform with higher functional and/or technical quality.

Retention Zone

Applications in this quadrant meet both the business and IT department needs, but may be subject to different opportunity. With little effort, this code can be easily modernized or transformed to accomplish new goals.

Re-Prioritization Zone

These are applications with higher than desired maintenance or operations costs, but are aligned with business value. They’re necessary to the business, but perhaps there are ways to make them more efficient.

As you can see from the matrix, it’s easy to spot quick wins when the applications and processes have been plotted. You can easily see how to plan the segments of your EBS project, starting with the quick wins that utilize the least amount of effort for the highest return.

Determine Feature Value

It’s important to determine the value of new or updated features in your Oracle EBS system. After all, what’s the point in having working ERP software if it doesn’t necessarily benefit your enterprise or end users?

Determining if your software is working or not is the simpler part; it can be measured by tasks done, bugs fixed, or the absence of issue reports. However, determining feature value can be a little more difficult.

Value should first and foremost be determined and agreed to by both your business executives and IT directors. It can really be anything that matters to your enterprise, as long as these metrics are clearly defined, established, and measured. Here are several popular metrics enterprises can use to determine the value of your EBS features:

=

Revenue Minus Cost of Development

=

Operational Costs Minus Cost of Development

=

Decrease in User Turnover

=

Uptick in Customer Satisfaction Scores

Determine Opportunity

Even your monolithic Oracle EBS application can offer countless new opportunities for your enterprise. All it takes is a little creativity, some clearly defined business objectives, and a capable team to deliver the solutions.

One excellent example of turning your EBS application into an opportunity is to make an internally facing application into a revenue generating, customer-facing service. For instance, you can create an external self-service portal by transforming your EBS workflow that helps employees track hours or sick days. When you can realize operating efficiencies by turning more control over to your employees, and they frequently find value in the rapid communication and efficiency opportunities that such an approach gives them.

EBS Integration Options

Fortunately for business leaders looking to find new opportunities within their EBS application, Oracle E-Business Suite offers integration points and a variety of technologies. Oracle has made it easier to integrate new applications and technologies with EBS, including SOA and REST services, Oracle products, and other options. While a specific integration point is possible through these other technologies and products, it’s in your best interest to analyze the costs, challenges, and risks before you begin an integration project.

Listed below are the 3 most common strategies for EBS customers looking to extend their EBS into new consuming systems.

Database API

A direct connection into your database, allowing outside systems to query and transact directly against your EBS.

R

Pros of Database API

  • Low up-front technical cost
  • Low up-front technical effort
  • Low operating cost
  • No new technologies necessarily required
  • Can enforce different levels of data privileges to different consumers
Q

Cons of Database API

  • Limits integration to high-trust users and internal systems
  • Slim to no integration with modern systems you don’t host yourself
  • Significant IT network, security, and hosting work to set up each connection
  • Requires consumers to understand your data model and code in PL/SQL
  • Limited opportunity for API re-use
  • High risk of consumers becoming tightly coupled, monolithically attached to EBS
A database API is a low-effort way to expose your core EBS features. In essence, a database API wraps the callable logic and database objects of your EBS application in a form that other applications can use (such as Oracle database views and stored procedures). However, outside applications and systems need a direct database connection to do it. This involves setting up a username, password, firewall ports and other security measures to establish a connection between your EBS database and each individual API consumer.

As you can guess, there are lots of people and red tape involved, making direct database connections cumbersome to set up. That’s why they are usually reserved for high-trust communication between applications that you host on your own servers. You only set them up a handful of times to connect your database to a few specific applications that you know everything about.

This makes Database API integration a great choice if your API consumers are limited to applications you control and users you trust. However, this approach is a poor choice and maybe not even an option for API consumers you don’t control or trust, such as customers, PaaS, SaaS, and mobile applications.

Lastly, a database API puts a big requirement on your consumers: they have to understand your database. This goes against good API design, because good APIs should be like contracts. They proclaim what your database can do for consumers without explaining how it all works. A database API requires consumers to write queries in PL/SQL (or use code libraries to do this for them) to get data and make callable statements. In other words, they still need to know how it all works. And without significant work, the little “gotchas” and workarounds that make your EBS tick won’t be contained behind your API the way they should.

This means consumers have to write DB-specific code to get information from your EBS’s database API. This DB-specific code may need to be updated if you upgrade your database version, or if you change the internal layout of your EBS database, or your security model, or, or … the list goes on. Ultimately, your consumers are at risk to become tightly coupled to your EBS database architecture, and may become a monolithic extension of your ERP. For long-term maintainability, that’s a big negative.

Flat File Data Export and Import

A process of scheduled, bulk data exports from your EBS to consuming systems in the form of flat files.

R

Pros of Flat File Data

  • Low up-front technical cost
  • Moderate up-front technical effort
  • Potential for low operating cost
  • Easy to set up for precise, single-use integrations
Q

Cons of Flat File Data

  • Limits integration to high-trust users and internal systems
  • Slim to no integration with modern systems you don’t host yourself
  • Significant IT network, security, and hosting work to set up each connection
  • Requires consumers to understand your data model and code in PL/SQL
  • Limited opportunity for API re-use
  • High risk of consumers becoming tightly coupled, monolithically attached to EBS
You’d be surprised how many enterprise-scale companies still rely on this approach for critical integrations with their ERP.

There are times when you simply can’t beat the tried-and-true flat file export. It’s nothing sophisticated: Oracle’s built-in APIs let you export your EBS data in a variety of common formats (most notably CSV). Then it’s up to your developers to airdrop them to the systems you want to receive your data. These exports can be automated, run on a schedule, and sent to consumers through a well-understood transport such as a shared network drive or SFTP server. In clever implementations, you can import bulk flat files from your consumers (a reversal in the provider/consumer roles). This effectively creates two-way communication between servers, allowing them to interpret and do with the flat file data whatever they want. The sky’s the limit.

Alas, the simplicity of this approach is also its shortcoming. The only data you expose this way is the data you choose to export. This is different from both Database and REST APIs, who by their nature expose large and varied sections of your database. This means that flat file integration is extremely purpose-specific, rather than a general use API you can set up once and employ anywhere.

Ironically, this approach is also relatively insecure: flat files are a form of “data at rest” with no expiration date. Direct database connections (and to a lesser extent, REST services) send information instantly, over protocols with high security standards. By contrast, flat files can live forever if you don’t delete them, and can be sent in unencrypted clear text if you aren’t careful. This is a major issue when dealing with sensitive data: you really have to trust the parties who receive your data to delete it when they’re done.

This method is not real time, which can be problematic. Consumers have to wait for the flat file to be created and delivered, rather than calling an API and getting a response in real-time. You can set up your file transfer jobs on any schedule you like, but the more frequently you generate files, the more hardware resources your EBS database uses for these jobs.

Hence the next issue: this method is inefficient with system resources. This trade-off between conserving hardware cycles and providing consumers with fresh data takes fine tuning, and in a cloud hosting situation, you’ll pay for those extra clock cycles. Regardless of how often you send the data out, your consumers know they aren’t working with up-to-the-second information, and are similarly burdened with re-importing and re-processing your exports to find the data they need.

Data Export

A modern, HTTP-based method of providing access to specific data and transactions in your EBS for a wide variety of high- and low-trust consumers.

R

Pros of Flat File Data

  • Modern API approach that plays well with modern systems
  • Developer-friendly, leading to high API re-use and innovation
  • Can enforce excellent data security with a high number of low-trust consumers
  • Allows consumers to efficiently query, filter, and manipulate data without knowing the structure of your EBS database
Q

Cons of Flat File Data

  • Significant up-front technical cost
  • Significant up-front technical effort
  • Significant operating costs
  • Often requires new IT infrastructure to develop and host the API
  • Often requires more complex, expert maintenance
REST services are the gold standard for modern API integrations. A widely-adopted and well-understood API approach, REST services rely on the well-understood network rules, encryption, and practices of HTTP to send and receive data across the networks. With good security practices, you can send even send extremely sensitive data over the open Internet.

The main downside of REST is the cost and effort involved. On their own, database APIs and raw data exports generally don’t require new hosting infrastructure. REST services generally do. This means buying significant new horsepower in your data center to host your REST API and handle the traffic you expect.

Ultimately, the API strategies you choose revolve around your goals. If you want to support customer-facing mobile applications, you need a REST API. Period. But if you only need to update your resale partners once a day with your inventory numbers, a flat data file export could serve just fine. If you are like many enterprises out there, the evolutionary architecture of your EBS will eventually encompass all three of these approaches.

AAR recently partnered with us to take an existing internal application and create a customer facing service called the PAARTS store. For our client AAR, we utilized ADF REST web services to expose their underlying data structures to a modern front-end technology, Angular. Learn more about this successful market disruption project.

Planning the Future of Your EBS Installation

The Future Of Your EBS Matters

Oracle’s most recent EBS release was Oracle E-Business Suite R12.2. They also made some changes to their support timelines for earlier releases of EBS. These changes make now the perfect time to evaluate your EBS strategy.

To stay on target for this year and to ensure that your strategy is ready to move to the next level, we recommend that at the very least Oracle EBS customers:

Stay upgraded to the latest EBS release to minimize risk as you plan for the future

Augment your team or partner with vendors that have full-stack and modern development skills to help tackle your EBS plan head on

Consider all of your upcoming integration, content management, and other needs for this year and beyond

Perform an EBS code analysis to get a full picture of your EBS system, dead code, challenges, and opportunities

Migration Options and Challenges

Oracle EBS Cloud Hosting

Cloud is a particularly important step to take when re-considering your EBS options.

According to Oracle’s website, “With an Oracle Cloud Infrastructure Compute or Compute Classic subscription and our automation tools, you can quickly provision new instances of Oracle E-Business Suite as well as lift and shift your existing Oracle E-Business Suite instances from on-premises to Oracle Cloud.”

Learn more about the keys to a successful EBS to cloud migration.

Hybrid Architecture

Hybrid cloud architecture means that you blend and manage both cloud and on-premises environments together in one EBS architecture.

According to Oracle, “Application Management Suite for Oracle E-Business Suite (AMS) uses Enterprise Manager to provide a central console that you can use to manage and monitor your Oracle E-Business Suite environments.” Their suite include tools that help you to manage and monitor a blended cloud and on-premises EBS environment.

Configuration Migration Challenges

Many enterprise will deal with numerous challenges migrating their EBS applications to the cloud and other technologies. For instance, custom EBS setups can be so large and cumbersome that one of the migration options enterprises have chosen is to physically ship hardware to their cloud carrier. This sounds crazy, right? It’s more common than you think.

From complex data needs, to years of technical debt, to customizations that may take developers years to untangle, enterprises need to assess all of their options to tackle these challenges. This section may help you identify those challenges before they become a huge problem

Sensitive Data

It’s also common for enterprise EBS applications to deal with sensitive data that requires security compliance with HIPPA and financial regulations. This data needs to be handled with care and masked when migrating from the existing EBS infrastructure into the cloud or other technologies. This can be a challenge for teams that are used to handling data within their existing frameworks, but once they begin a migration project, they need outside consultants or vendors to help them perform the work to compliance. This can rack up the cost significantly.

Configuration Management

Configuration management is a process to establish and maintain consistency of “performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.” Traditional software configuration management is often considered the best solution to handle numerous changes that occur during software projects.

The CM process gives you more control and insight into every step of an EBS migration by being able to “perform functions like root cause analysis, impact analysis, change management, and current state assessment for future state strategy development.” [source]

So why is configuration management a challenge for EBS migration projects?  Simply put, the configurations in your EBS are shorthand instructions to your EBS about which features it should switch on, which to switch off, and how to behave in lots of other ways. As a switchboard for you to control the built-in features of EBS, your configurations are incredibly valuable.

They are also incredibly specific to your EBS. Different ERPs, even different versions of EBS, will not be compatible with these configurations. When migrating to a new system, your configurations have to be translated into the instructional language of the new system. Often they must be interpreted case-by-case by an expert in your new platform, or with special migration assistant programs. In some cases you’ll have new configurations available to you, and sometimes you will lose settings you had before because there’s simply no apples-to-apples way to bring the setting over. The built-in behavior of the platform you intend to migrate to is not a guaranteed 1-to-1, and configuration management is all about how you creatively close this gap.

End User Adoption

One of the most common (and often overlooked) enterprise challenges once you’ve migrated or implemented your new EBS solution is user adoption. What happens if you’ve spent money, time, and energy to plan and execute new workflows or self-service portals that are meant to impact your bottom line, and your employees simply won’t use the new technology? What if the training time has actually increased for the new workflows?

Enterprises can head off this particular challenge and increase user adoption by making sure that end users are involved in the planning and implementation process from the beginning. With a combination of use case analysis, user interviews, testing, and training, you can ensure your EBS project gets off to a great start and that users are completely satisfied with the end result.

IT Infrastructure Cut-Over

What is IT cutover? ‘Cutover’ as defined -‘rapid transition from one phase of a business enterprise or project to another’. It follows approaches that are emanated from various project experiences and aligned with the organisational policies and procedures for better execution and control. In simple terms, when a project or product completes a development stage, it needs to transit into operations stage or another phase.

Cutover is vital process as it involves placing the product or service or result of a project to its operating lifecycle, so that initial issues/pitfalls could be monitored, minimized and managed effectively, thus in context of Project Management it is important to understand the ‘Cutover Process’.

Though cutover process is more associated with or pertinent to the IT processes, but it is equally relevant in all types of products/projects, the scale and volume of activities may vary.
The cutover process is crucial to an EBS project because it focuses on the important tasks and activities necessary to make project result for actual use by the end user.

According to ProjectManagement.com, the “cutover process involves a series of steps need to be planned, executed and monitored in order to make the project golive.” It encompasses:

  • Migration from controlled development environment to operational environment
  • Finalizing an established cutover date when new procedures and processes officially begin
  • User training, documentation, and issue resolution procedures
  • Ensuring that the new EBS setup meets compliance and governmental regulations

Of course, there are many other possible steps and outcomes that could come into place for your EBS cutover process. The important point is that your enterprise must ensure that business and IT departments work together to fully establish parameters for a successful implementation.

What’s Next for Oracle EBS?

Everything is changing. As much as the world of technology changes with ever greater speed and unpredictability, it is only the most outwardly visible sign of change in the business world. New technology sparks new business models, new revenue streams, and changes buying patterns in all industries. The companies that lag behind are the ones who don’t see the urgent need to adapt. That is the core motive behind digital transformation: the need to adapt quickly.

Oracle will undoubtedly speak to this need to adapt your EBS to an evolving world. They will, no doubt, describe product roadmap for EBS and a future in which the technology stays relevant. Oracle’s new cloud hosting for EBS is a step in the right direction – but it’s not enough. A cloud migration is not the sort of innovation that puts you ahead of the curve, nor is it the architectural transformation you need to help your innovators thrive.

Make no mistake, the choices you make in upgrading and migrating your EBS have everything to do with your ability to keep up. The right technical architecture around your EBS can turn it into a center of innovation, enable business units to creatively pursue new revenue opportunities, and even help you mine your data for insights that only your data can tell you. Without this forward-looking perspective on your EBS, though, you may not see the value in transforming. You might not see the urgency.

If you don’t make the big changes, you won’t be ready to make the fast ones. The agility gap between you and the competition will only get wider.

If you’re ready to consider an Oracle EBS analysis, upgrade, migration, or development project, contact us. From planning and analysis, to development and execution, PITSS can work with your business and IT leadership to make the most of your business-critical Oracle EBS system.

Meet our team to see how we can transform the systems that matter most to your business.

Contact Us
First Name*
Last Name*
Email*
Country*
Company*
Role*
How Can We Help?
Lead Source
Lead Stage