Note: this is a blog series that covers the basic concepts of Oracle EPM Cloud.

A couple of years ago I flew on a puddle jumper. This plane seated less than 20 people and took only 40 minutes to reach its destination. Once we landed, I was giddy to be the first one off the plane. However, being a small plane, we were emptied onto the tarmac instead of the usual jet bridge. I didn’t know where to go.

There I was, looking around, trying to figure out how to get into the airport. There were lines all over the tarmac – with different colors and patterns going in multiple directions. Although lines were painted, I didn’t have a clear path in front of me. A little bewildered, I fell in step behind the second person off the plane (who clearly knew what she was doing).

The airport probably assumes that the path is intuitive, which is why they had no one directing us. Given the strict laws around airport security, the entire setup surprised me. It made me wonder if Oracle EPM cloud customers find themselves in a similar quandary. Oracle has gone full steam ahead in the direction of Cloud. Although the first Oracle EPM Cloud product, PBCS, was released over 4 years ago, Oracle still has no formal training class for it. Instead, they created self-service subscription training via a video library with an annual license fee. This means that they are relying on customers and partners to get up to speed using: the Oracle self-service online video snippets, online documentation, on-the-job training, or people more knowledgeable than them to fall in step behind. They believe their products are intuitive enough not to require much training. The truth is that even a little training goes a long way. People who have never seen these products in either Cloud or on-prem form need a nudge.

In this inaugural post, I’ll cover some important infrastructure concepts about Oracle EPM Cloud.

In case you’re wondering who I am, I am an Oracle Cloud specialist at interRel Consulting and was recently awarded Oracle ACE Director status. My primary work is in Oracle EPM and BI Cloud.

I provide this information freely because I truly believe that we are better off when we are all educated and collaborative. In fact, I encourage you to leave comments in my posts if you agree, disagree, or have additional perspectives to offer.

1. PBCS Rules the Oracle EPM Cloud World

Oracle has made a solid path around PBCS (Planning & Budgeting Cloud). This was a stellar product on-prem (called Hyperion Planning) that was built on over 15 years of innovation. So Oracle decided to port it to Cloud and it’s one of (if not #1) their best-selling Cloud products.

A good number of their tools are based on this technology foundation. Why spend development money on different architectures and platforms when you can just create one and tweak it for multiple products? Case in point…the following EPM cloud products are built upon a PBCS platform:

• PBCS (duh)
• EPBCS (double duh)
• FCCS (yes, we now have a close & consolidations tool running on the almighty Essbase database)
• TRCS (surprised?)

The following technologies are currently not built upon PBCS but are expected to follow later this calendar year:

• EPRCS Management Reporting
• PCMCS
• ARCS (may be this year, but may be next year)

It might not seem like this would be the case because there are different features and use cases for each product. To put it simply, the difference lies in the web layer. Oracle chooses to expose different attributes in each web interface. So if you are someone interested in jumping on the Cloud bandwagon then guess where you should start? If you learn PBCS first, you’ll know the basic navigation and features of many of the other Oracle EPM Cloud technologies built upon the same platform.

2. PaaS vs. SaaS

What the heck are PaaS and SaaS? Every time I hear the word PaaS, I think of those Easter egg decorating kits. PaaS and SaaS are very nerdy buzz words that describe different Cloud licensing models at Oracle. There are even more “aaS” acronyms out there in the Oracle world that don’t apply to EPM: IaaS (Integration as a Service), JaaS (Java as a Service), DBaaS (Database as a Service), and more.

All EPM Cloud products are SaaS. “SaaS” is an acronym that means “software as a service”. This generally refers to product offerings that are built upon an application foundation. Meaning: customers don’t have the ability to make modifications to the platform or backend. PBCS is a perfect example of this. In PBCS you don’t have direct access to the foundational Essbase Administration Services technology, nor the supporting database layer. Your world is somewhat pre-defined for you. This can be both a blessing and a curse, and this is how most application-focused Cloud software is built.

OAC (Oracle Analytics Cloud) is an example of a “platform as a service” (a.k.a. “PaaS”) technology. Although the autonomous offering is now out there to shake things up, OAC is architected differently from Oracle EPM Cloud. Also, it isn’t built upon the PBCS platform.

To most Oracle EPM customers and partners, the important difference between these two platforms is in the licensing model. SaaS products generally follow a month-to-month “pay as you grow” named user cost model. For instance, all EPM Cloud products are currently priced at a fixed fee per named user/month. There is a minimum required number of users for some of these, but there aren’t any extraneous fees (like support). PaaS is generally based on consumption: storage space, number of processors, and memory. There doesn’t seem to be a single standard licensing model for PaaS, and it has evolved so much since OAC was released over a year ago that I don’t feel that we’re in stable territory just yet. From what I understand, most of the “traditional” Oracle database cloud products are PaaS technologies and follow this consumption-based licensing.

3. How to Refer to the Cloud Software Version

Oracle development teams often refer to the version of each EPM Cloud product’s technology as a 4-digit number. This is based on the year and month that the feature set was released. For instance, the June PBCS release is called the “1806” version. The “18” refers to the calendar year 2018 and the “06” refers to the numerical representation of the month – June in this case. If you look deeper into the version number – under the user menu in the “About…” section, you’ll even see a specific patch number added to the end of the 4 digit number.

There are other version numbers as well, but they are hard to find now and are mostly used for backend support or internal Oracle discussion.

4. Multiple Environments

Right now, every Oracle EPM Cloud technology comes with two environments/instances for a single pod license: test (a.k.a. pre-production) and production.

5. Hardware, Installs, Upgrades, and Patching

One of the main benefits of the EPM Cloud platform is that Oracle handles all of the hardware, installs, upgrades, and patching behind the scenes for you, and they handle this for both test and prod. You no longer need a server administrator to tackle these tasks. This allows the Cloud technology to fully reside within the business, which is a big attraction for some customers. Test gets the latest patch/release on the first Friday of each month. Production receives it on the third Friday of each month.

PaaS (which OAC falls under) is a different story. If you’re not on the new Autonomous OAC offering, then you are responsible for patching your own environments. This usually requires some downtime, a couple of button presses, about 30-60 minutes, and then you’re ready to go. Right now there is not regular cadence for OAC patches – they are delivered to customer environments when ready. The good thing is that these patches are cumulative, so if you miss one then you can skip it and get all of the updates in the next version. In addition, the OAC environment does a backup prior to doing the patching. Finally, you can always rollback a patch if you find any issues with it.

6. Security

One of the main reasons why customers initially feared Cloud was due to security. However, after a history of good behavior, customers are starting to come around. There is another blog series where I cover the specifics of Planning Cloud security, so let’s keep this high level. Here’s what you need to understand.

Most customers are on the Traditional Public Cloud licensing model. This means that any one of your users can access EPM Cloud with a web browser and a few security details: a URL, domain, username, and password (which are all assigned to you once your licensing is squared away). That’s why it’s called public Cloud. No VPN is required. (Note: if this is worrisome, Oracle does offer other types of Cloud licensing options that are more customer controlled.)

With it being so easy to access your environment, is there cause for concern? In the past 4 years, I have not heard of a security breach. I’m not saying that it isn’t possible, but Oracle does seem to have their game together. Remember that pesky Intel chip bug, Spectre? Oracle put a fix out for that within weeks. How long did it take your IT department to resolve the same issue?

Another common question around security is whether or not Single Sign-On is possible. Yes it is and many customers are using it. (Hint: you’ll want to use this, too, if you plan to buy multiple Oracle EPM Cloud products.)

7. Scripting

So, given the statements above, is scripting still possible with Cloud? How does one handle automation of common administration tasks? Yes, you can create batch automation still with public Cloud. There is a common utility that goes across almost all EPM Cloud technologies called EPMAutomate. This is a command line tool. It can be scripted, batched, and scheduled (with a 3rd party scheduling tool). It’s recommended that you use an on-prem management server to handle this processing centrally for your organization, using system administrators.

8. Backups

Note that you will have to learn scripting if you want regular, automated back ups of your EPM Cloud environments. Oracle backs up your environments for you every night, but only once every 24 hours and they overwrite the last backup. Therefore, customers have to download that new snapshot every day and keep them stored offline in order to have a set of rolling backups to restore from.

In addition, Oracle just rolled out a new policy this month regarding the snapshots stored on your EPM instance (both the snapshot that Oracle creates nightly plus any you create on-demand). They’ll keep your snapshots for up to 60 days. Snapshots over 60 days old get automatically deleted. However, if your snapshots are large and exceed 150Gb in total, Oracle will delete them to make room, starting with the oldest one no matter how long its been on the server.

PaaS has it’s own backup methodology. You can configure your OAC backups to have them automatically run. Since you are paying for your own storage in PaaS, it’s up to you how many you keep.

9. Disaster Recovery

Oracle has a complete disaster recovery plan for Cloud. Basically, they cover it for you and it’s included by default with your subscriptions. That’s pretty much the extent of what I know.

I reached out to one of the best Cloud infrastructure folks in Oracle SaaS to get more details about Oracle EPM Cloud: if you find that you would feel more comfortable with another DR environment, Oracle can set up a self-serve DR standby subscription that will go to a different data center. To read more on the SaaS security, support, and disaster recovery strategies, read the SaaS Public Cloud pillar document.