Blog

When I first planning for migrating to Oracle's Cloud suite of projects for Business Intelligence , I would get that sort of imaginary heartburn that you get when thinking of a daunting task that you don't quite understand how to do it, or more importantly, why to do it.

Why upend the existing BI ecosystem I've worked for years to complete? Why undo all the processes I've worked, not only in the developmental sense but also in the business sense of negotiating accesses, earning buy-in from stakeholders, proving out the value by demonstrating key functionality? Moving to the cloud would remove the result of all that effort and cause me to take significant steps backward before being able to take the step forward that cloud technology was supposed to offer... right?

This line of thinking turns out to have a key, fundamental flaw: migrating to Oracle Analytics Cloud does NOT require a full cloud-based architecture.

I learned quickly that migrating from OBIEE on-premise (either from 11g or 12c) to Oracle Analytics Cloud doesn't mean having to re-engineer or recreate your data warehouse and the processes that maintain it, but rather in most cases, OAC can connect to the existing warehouse to provide a hybrid cloud/on-premise solution that allows BI programs like the ones I've worked in to move in a practical, reasonable manner.

Established BI programs can take advantage of the benefits of OAC: namely not having to own and upkeep hardware and the costs associated with it, having easy access to the latest version of the tools, getting the earliest access to the newest features and tools, and being mobile ready and accessible from nearly anywhere.

To understand how this works, it's key to first understand that OAC is offered as a Platform as a Service (PaaS). This means Oracle provides the cloud space and the services required to operate the environment, but you, as the administrator within your organization, are responsible for standing it up, maintaining and administering it (including using Oracle's streamlined patching tools to keep both the virtual environments and the application itself up to date via patching as needed). This is different than Software as a Solution (SaaS) offerings where you simply are provided the front end of a tool and Oracle takes care of everything on the back end autonomously.

One of the benefits of being in a PaaS model is having greater flexibility with controlling how your environments are configured, especially concerning networking and general connectivity options.

Note: Before moving on, I have to emphasize heavily here to be sure to loop your network/security/infrastructure resources into conversations around these options AS SOON AS POSSIBLE in your project design phase. Any time you talk about connecting internal data and/or systems to applications in the public cloud, you must be able to have the relevant conversations with the folks in charge to get their valuable, expert input on the best methods to use in the best interest of security, to get their signoff on the final solution, and avoid situations where a solution is put in place only to find later that it doesn't meet the requirements of the organization or violates some sort of internal policy.

That said, here are the most common options used to create a hybrid cloud/on-premise solution for Oracle Analytics Cloud :

Remote Data Connector

If your on-premise data source is an Oracle database, then the easiest method of connecting it to OAC is to use a Remote Data Connector. This is a plugin provided by Oracle that essentially makes the on-premise DB visible from the Cloud. It has a built-in process to keep your data secured while OAC submits queries. Since this doesn't require any complex networking configurations, it is the best solution to deploy if your requirements support using it.

Click here to learn more about Remote Data Connector

But what if your data sources aren't an Oracle DB? What if they're SQL Server, Teradata, or some sort of application you connect to for real-time reporting?

VPN as a Service

Oracle offers a VPN as a Service option for cloud deployments as well, and it is the first and likely most commonly used method of connecting OAC to on-premise data sources that aren't an Oracle DB. Establishing a VPN connection between your OAC environment and your internal data center will allow the tools within OAC to consume the data just as they do today in the on-premise world.

Click here to learn more about VPN as a Service

Fast Connect

Additionally, Oracle also supports technology like Fast Connect to establish direct connections between your data center and the cloud environment. This may be beneficial if your data volume is exceedingly large or if your requirements are abnormally stringent regarding speeds of data transfer.

You can read more about Oracle's Fast Connect options here.

Finally, I know I am repeating the point noted above, but I cannot stress just how critical it is when considering these options to involve a representative from your internal networking and security teams as early as possible. This will allow them to get an understanding of the objectives you are trying to achieve as well as the technology and methods being proposed. After all, any network or security designs are going to ultimately need their support and approval before being implemented.

If you are considering upgrading and migrating to Oracle Analytics Cloud but are unsure how it impacts your existing data marts, or if you simply do not want to move that set of data any time soon, rest assured that Oracle has options to provide flexibility to facilitate hybrid cloud solutions .

If you're interested in learning more about OAC or any of Oracle's Cloud offerings, visit us at mindstreamanalytics.com , or find us on LinkedIn, Facebook, Twitter, or YouTube. We would love to assist your organization in advancing to the next stage of your Business Intelligence and EPM evolution.