Over the years the role of the Oracle Database Administrator (DBA) has changed significantly. Originally the DBA kept your database running, adding new datafiles, tweaking SQL queries for performance, but organisations had a team of other resources managing the hardware components, backups, network and all associated components. Today, and especially with the options presented by “Engineered Systems”, the Oracle DBA has become a hybrid resource, taking a hand in storage, network and general hardware administrations as well as no longer being silo’d to Oracle. Additionally, the DBA has access to powerful suites of tools like Oracle Enterprise Manager which help automate backups, performance tuning, and simplifying basic database administration tasks.

So.. what happens when you go to a Cloud infrastructure ?

Firstly, we should consider what “Cloud” actually means. Oracle has a number of Cloud offerings, each requiring a different level of user interaction and administration. It therefore makes sense to consider these offerings in logical groups.

SaaS (Software as a Service) is the capability to present a fully-functional application to an end user, with Oracle providing all the patching, operating system, capacity and performance monitoring for that environment. SaaS introduces the idea of a Service Administrator, a privileged user who has access to the SaaS console and is the point of contact for eMail communications from Oracle with regards to the service, such as outages etc. The Service Administrator is not a DBA but can be a ‘Super’ business or functional user. Responsibility for activities like arranging clones and coordinating outages for patching also falls under the scope of the Service Administrator, although Oracle performs all of the actual technical work). It’s important to nominate the right person for this role and ensure a secondary, delegated account is created for holiday coverage etc. Apart from this Service Administrator role, and essential setup and configuration of the application (creating business groups, user admin, etc), there is little else for an organisation to “manage” within a SaaS application. The technical activities which do remain primarily involve environment management and coordination between your network support (firewall) team and Oracle, with very little input required from a traditional DBA. However, with SaaS based products, it is very important not to forget integration. Generally, products don’t stand alone, and need input from, and feed into, other systems in order to carry out daily tasks like BACS payments, job offer letters, P45 submissions etc. These sorts of activities are discussed below.

Oracle Managed PaaS (Platform as a Service) covers the PaaS products which are treated almost like SaaS by Oracle. This includes Integration Cloud Services (ICS) as well as other products like IDAM (Identity Management) and MCS (Management Cloud Service). For these products, the level of support Oracle provides include patching, upgrades, etc, and the customer has no access to the underlying operating system and product binaries. The reason these products are branded as PaaS, rather than SaaS, is because they generally act in concert with other products, rather than stand-alone.

As mentioned above, where you have a SaaS product, integration becomes key, and products like ICS, which come ready-built with a whole suite of integration components, provides what looks like relatively simple integration capabilities. However, the difficulty of integration should never be underestimated, and there is still a need to retain resources who understand the data, business processes, and integration patterns for your specific environment, in order to achieve a successfully integrated solution. In “old money” this would have been SOA (Service Orientated Architecture) developers, Java developers (these are all still valid in the Cloud (see below), but gradually are being replaced by ICS developers).

The final grouping is Customer Managed PaaS and IaaS (Infrastructure as a Service). IaaS is the traditional Cloud hosting which provides the end user with a virtualised server, hosted on an Oracle managed platform, and sold in chunks of CPU and storage as required. The Customer Managed PaaS is a layer on top of this and encompasses Database, SOA and Java Cloud services, to name a few. The PaaS offering is effectively IaaS, plus the embedded license for the relevant product, and also some tooling to simplify some of the patching and general administration tasks.

For these PaaS products (and we will take the database as an example operating system) patching, bug fixes, backup management still remain the customers responsibility, despite being Cloud hosted. Additionally, while Oracle can automatically provision a RAC or DataGuard (High availability/DR options) environment, ongoing management and any changes (e.g. moving your 2nd DataGuard environment to a secondary datacenter for true DR) require an experienced DBA to manage, and potentially also operating system administrators as well. All the Linux level administration is also the customers’ responsibility.

In conclusion, coming back to the original question of whether you still need a DBA, the answer seems to depend on what you’re implementing. If your environment is a simple SaaS implementation of Oracle ERP Cloud, with very little integration, then a majority of your technical requirement will sit with Oracle. However, if you have a multi-site, multi-product implementation, involving 3rd party products hosted on IaaS, with a DBaaS instance for APEX extensions to your applications and extensive integration, then you will still require DBAs, Developers, System Administrators, etc, just as you did when running on premise.

In my experience, the requirements for a DBA is somewhere between these two extremes, and organisations will still need to maintain a technical capability, because while products are getting easier to manage, keeping them talking together and adding those features unique to your organisation, is getting more complicated.