What if companies say: “help me move away from Oracle”?
Authors: José Rodrigues (Link Consulting, Portugal), Arturo Viveros (Sysco, Norway), Sven Bernhardt (OPITZ CONSULTING, Germany), Rolando Carrasco (SPS, Mexico), Lucas Jellema (AMIS|Conclusion, The Netherlands)
We hear this aspiration from a growing number of organizations. Sometimes as a quite literal question. This however is merely half of a wish. Apparently, organizations do not want one thing anymore — but have not yet stipulated what they desire instead. What is the objective that is pursued here?
And what is even meant by Oracle? Oracle has a broad product portfolio and is of course also a company, a business relationship. Should all products be removed and all ties with the Oracle company severed? Does the person asking to be helped even know what their company is using from that supplier? Is there a business case for such an operation, which obviously requires considerable costs, efforts, and risks? And as with every question we get asked as architects, we have to understand the background and real purpose of a request and so we ask the ‘power question’: why??
In this article, we will first explore where the desire to move away from Oracle might come from. Then we describe what the term Oracle represents — more than 2.000 products on all layers in the technology stack and in different business areas. Finally, we map out what the ‘moving away from’ consists of: defining where you ‘move to’ and subsequently actually going there.
It will become clear why should you give a considerable thought about dropping Oracle, or any other vendors’ technology, when you’re not pleased with your current IT situation. You need to focus on the actual problems and objectives and define the suitable roadmap to fit your real needs.
Why (move away from Oracle)?
The reason behind this request for help to move away from Oracle is not infrequently the behavior of [representatives of] the company Oracle Corporation. A combination of assertive, short-term sales actions, limited apparent interest in customer success [related to the acquired Oracle products], persistent communication breakdowns and unexpected and substantial cost increasing verdicts from License Management Service (LMS) as well as some incomprehensible modifications in the pricing structure, has stymied many Oracle customers. The decline in the perceived value of a high priced Support organization and the additional costs of engaging ACS to actually solve problems have also caused a lot of bad blood. Oracle often seems perceived as rigid, blunt, customer dependency exploiting and misguidedly arrogant.
“With a party that treats you that way, you don’t want to do business. After all, their products are not that special.”
Like many suppliers — and certainly not any less than other suppliers — Oracle has enthusiastically introduced new products, discontinuing existing ones, sometimes after a surprisingly short product lifetime, and not always paying much attention to clear migration paths for existing customers. Oracle product teams often strictly work from their own context without much coordination and responsibility for the history that was built with and by customers.
Irritation is a poor counsellor
Although in many cases the irritation is quite understandable, in itself this does not provide a sound business argument as quickly as possible to get rid of Oracle [products] — or products from other suppliers where something similar applies. Just like fear — uncertainty and doubt — irritation is also a bad guide. But justified grumpiness puts a bombshell under a business relationship and is an additional reason to evaluate that relationship critically. However, this evaluation should be done using business and technical rationale, not emotional reactions.
A few things can and should be done. As with any other relationship, talking with the other party and discussing these issues will help all involved. Having a serious conversation with the Oracle organization — whether or not mediated by an Oracle partner and/or teaming up with other Oracle customers — might be helpful to clear out misunderstandings or irritations. Just reacting emotionally, from the gut, to break up with Oracle [technology and vendor] without proper analysis of alternatives or a business case could lead to a much worse situation. Stepping back, taking a deep breath and assessing the situation as objectively as possible is always the better option.
Continuous Technology Evaluation
A periodic evaluation of the technology stack that an organization uses is a good practice that should produce an updated roadmap with a medium-term plan for consolidation, evolution or deprecation & replacement by a viable alternative. Note that proceeding with a component is as much a decision as the choice to replace it.
This periodic review prevents the organization from adopting and maintaining technology that has become unsafe or a potential liability with too little market support, increasing the risk of dependence on a supplier, as well as too high maintenance, operations, and development costs.
The business is in constant change due to market pressure, and IT should provide a way to react to those pressures. This is yet another reason to perform continuous evaluation of the architecture and technology stack and its ability to still provide innovative features.
“No Old Junk in My New Cloud”
A special trigger for a reconsideration of the technology stack in many organizations is the desire for defining a cloud strategy. This is a time to re-examine and step away from products that have long been a given in the IT landscape (next to Oracle, this of course also applies for example to SAP, Microsoft or IBM).
Cost and Expensive
With costs, we touch on another argument we sometimes come across regarding Oracle: “it’s (too) expensive”. This does perhaps not sound all that emotional but it is actually still highly subjective. Expensive is a judgment that says something about costs versus revenues — [and] in comparison with realistic alternatives.
EXPENSIVE =
(operating expenses + management costs + maintenance costs) > Revenue
||
(operating expenses + management costs + maintenance costs of the Oracle solution) >> (costs of an equivalent alternative stack)
Of course, it is conceivable that the cost of an existing Oracle-based solution is higher than is justified by the business benefits it generates or higher than those of an alternative solution. And if so — and the cost of migration can be recouped — that seems like a great argument for “getting rid of Oracle” for that particular application. Note: it can well be that the existing Oracle-based solution is oversized, which is causing extra costs that can be reduced by simply downsizing the runtime environment.
SMART_TO_MIGRATE = (Current Cost — Future Cost) * 5 years >>
migration costs (consisting of requirement analysis + design + implementation + test + train + risk mitigation + … )
We don’t know many organizations that have a real insight into what their IT activities cost, per technology or per application — licenses, operations, maintaining knowledge, maintaining — and even fewer that know what business value each of their applications yield. This makes it difficult to turn the subjective idea of “it is expensive” into objective terms on which a decision can be based.
“I don’t know what it costs or what value it provides; I just think it is too expensive!”
We would argue that organizations should build more insight into the specific costs and benefits of their IT activities and their hundreds of applications, focused on activity based costing, proper management of IT applications and a serious business case development for IT spending, far away from the very crude lump sum based IT-budgets that we still encounter in the vast majority of organizations.
Technology, people and culture
Within organizations there are many people in different roles that work with (Oracle) technologies. Those people have different expectations, requirements and thoughts with respect to a specific technology, which highly differ depending on their positions within an organization. Usually, people from the technical staff, like operational specialists or software developers, have passion and specific preferences when implementing solutions. They typically have invested many years into honing their skills on a particular technology, accumulating mountains of knowledge and even building networks with colleagues and peers who are on a similar journey. Managers often don’t care so much about technical details and do not have that same level of personal investment; they are more interested in things like costs, as discussed in the paragraph before.
This is also a dimension to consider, when replacing technologies — especially without an apparent and rational reason that is not clearly comprehensible by all stakeholders — as this may lead to frustration and dissatisfaction. This disturbs the overall company’s efficiency and will tear deep trenches within the organization. For example, when the business stakeholders are satisfied to get rid of a certain technology like the Oracle Database, but the users (especially DBAs) that work with Oracle technologies since ages are not happy with that decision. Consequently, they lose motivation or — even worse — might leave the company, which means potential loss of essential know-how — not only on the technical side but also in terms of business insights and company memory and conscience. In some cases, they actively resist the adoption of the new technology, leading to projects even failing.
Companies invest money on technology, people invest in themselves
Replacing technologies or existing software solutions should ideally never be exclusively motivated by emotional or technical or business reasons; a middle way should be found which manages to consider not only cost and technology but also the impact this kind of decision might have on organizational culture and the people that are the organization.
Handicapped by inhibiting lead and victim of past success
It has become apparent to us that, in several places, the name Oracle evokes feelings of “large, complex, very difficult to adapt and old-fashioned”. Not dissimilar to how we talked about Cobol and mainframes in the 1990s — at a time when Oracle was hip & happening. And this, despite the fact that the Oracle technology stack has evolved and expanded enormously in those 25 years with acquisitions of innovative companies and introduction of cutting edge technologies.
We did not understand that sentiment very well. And then it dawned. What happens to any software system that has been worked on for 15, 20 or even 25 years? Regardless of the technology used? In almost all cases, such a system has grown unchecked into something that is large, complex and intimidating. They’re often maintained and managed by employees who have been working on that system for decades, and, not infrequently, still in the same way as twenty years ago. These systems are often of great importance to the business, the heart of an organization. And while each system was a big step forward in its early days, the growing complexity and rigid way of working has turned it from everyone’s pride to almost a burden. This is not specifically down to the technology stack used — because these crucial, burdensome systems exist in all kinds of technologies — but it is mainly down to our limited ability to build and especially maintain quality software. This is key: we are blaming technology for problems that we have our own more than fair share of responsibility for.
Besides software quality, we rarely care about updates of the used technology stacks. Most people like creating new things, but they — or their budget providers — don’t like to maintain them properly. Technologies are evolving fast these days, and we should find a way to update the underlying technology stack on a regular basis. If we manage to do so, the upgrades will lose the horror effect they frequently have today and, as a bonus, new features of a new version could help to increase the sustainability of the software. By doing so, significant limitations of a technology platform could also be discovered earlier, which could be a trigger to rethink the technology choice.
There is a lot of understandable discomfort about the lack of changeability and control over, those applications. This distress reflects on the technology applied at the time and by extension on the vendor and directly on all other products from that vendor. Systems that are now about two decades old are built with the technology that became popular at the end of the last century, such as the combination of Oracle Database and Oracle Forms.
This duo has been used in many places to build the applications that are now looked at with great unease. This seems to play an important role in the general sentiment about Oracle. Users, business stakeholders, and IT-managers with frustrations about today’s custom applications, project those feelings on the technology, the supplier and everything that has to do with that supplier. So, in a sense, Oracle is today a victim of its own success more than twenty years ago. And that of course is just the reality of any legacy system: due to their original success, organizations were comfortable at first and almost forced later on to continue building on top of it.
“I want to get rid of ‘big, complex, expensive and unwieldy’ (so therefore I want to move away from Oracle)”
Organizations have started enthusiastically with Oracle technology and were initially successful with it. If these organizations now indicate that they want to get rid of Oracle, but can’t quite answer the question of why they want that and where things have gone wrong, they run the risk of in about 10 of 20 years asking a similar question “help me get rid of xxxx ” (where xxxx is the technology du jour). In the end, you don’t want to get rid of a specific technology, but rid yourself of a complex, poorly adaptable, expensive application that is hard to manage.
So make sure you don’t end up in such a situation again and be aware that technology selection will not be the determining factor in all likelihood.
What does “Oracle” even mean?
What exactly is meant by “Oracle [that one wants to move away from]” will vary by customer. And many customers may not even know exactly what their degree of Oracle is. Many people will first think of the database — the RDBMS that the Oracle kingdom is built upon. And even with that database, it is all too easy to have the wrong image.
The Oracle Database is not a database
The Oracle Database is not really a database — or at least not just a database. The Oracle Database is a powerful and proprietary application platform. Using the PL/SQL procedural programming language in packages and triggers with Oracle integration-specific SQL-extensions, libraries, and special mechanisms for security, recovery, time travel, web service calls have inadvertently created a vendor lock-in that cannot be trivially escaped from. If APEX applications (a low code platform that is available for free from the Oracle Database) are also used, the entanglement with the Oracle Database platform is even greater.
And in addition to the Database (which is not just a database), Oracle has more than 2,000 products — from hardware to ERP applications. And it also offers training, support, consultancy and advanced support services.
So Oracle can have a lot of different interpretations. So if an organization wants to “get rid of Oracle”, a thorough investigation needs to be done to determine exactly where the organization is “on Oracle” and how the applied Oracle products are used, what (business) purpose they serve and what they are entangled with.
Even if an organization does not necessarily want to get rid of Oracle, the periodic evaluation of technology components should also include the investigation mentioned overhead and critically consider the roadmap of the Oracle products — as well as products from other origins. Maybe it is desirable if not required to replace a certain Oracle product in a specific area, because it is no longer supported or no longer applicable. But of course there cannot be a golden rule to always retain or always replace the Oracle product!
Deep Dive Oracle stack
In addition to this RDBMS, the Oracle product portfolio also includes hardware — for example, the traditional Sun Microsystems machines, ZFS Storage, Exadata engineered systems and the ODAs (Oracle Database Appliance). The operating systems Solaris and Enterprise Linux as well as Hotspot Java Virtual Machine are also Oracle products.
“Oracle” is more than 2,000 products
Many organizations that started working with Oracle technology in the 1990s have developed — and still use — applications with Oracle Forms and in some cases in combination with Oracle Designer that has been unsupported for over a decade. Today, these Forms applications run on the WebLogic Java EE Application Server — acquired by Oracle in 2009 with the acquisition of BEA. Many organizations use WebLogic and also various components of Oracle Fusion Middleware. These include Oracle Service Bus and SOA Suite, OBI EE (Business Intelligence), Hyperion, Oracle Data Integrator and GoldenGate, WebCenter Content, ADF and Coherence.
Oracle ruled the development stage for several years with a mix of Java, WebLogic, Database implementations. A lot of Oracle customers have their workloads running on top of that mix, and in some cases it is complemented with Oracle SOA Suite and Service Bus.
In addition to this traditional technology pillar, Oracle is increasingly relying on business applications. Generic on premise ERP packages such as E-Business Suite, Peoplesoft, JD Edwards and Siebel and industry-specific solutions such as Hospitality (including Micros), Retail (including Oracle Retail), Health Insurance, Engineering (among others Primavera). Most of these packages are now also available as semi-SaaS (hosted but not cloud-native). Cloud Pure SaaS products are also on offer — for example for Customer Experience and Marketing with services such as Eloqua, BlueKai, Marketing Cloud and increasingly for ERP — Fusion Apps for HCM, CRM, Sales, ERP, Supply Chain Management.
Due to all of these COTS applications from Oracle, customers tend to incorporate Oracle technology components to fill the holes and gaps in and between those applications, mainly for integration purposes and custom UIs.
In Oracle’s most recent strategic turn, the technology pillar has been re-launched under the name Oracle Cloud Infrastructure (OCI) — a public cloud with a range of services comparable to AWS and Azure — both IaaS and PaaS. The Autonomous Database is OCI’s flagship — as far as Oracle is concerned, the destination for all its enterprise database customers. Oracle proudly claims that OCI’s underlying infrastructure is state-of-the-art. Oracle has partnered with Microsoft on a connection between Azure and OCI data centers to enable customers to easily combine services from both vendors- for example, Azure Power BI against Oracle Autonomous Database. This makes the multi-cloud a reality based on the realization among both partners that the majority of their customers will use more than one cloud platform.
On the other hand, many of Oracle’s “on prem” technology products, are only being evolved in a very hesitant way; customers are increasingly being coaxed towards PaaS services.
Away from what?
Let’s assume that “away from Oracle” is implicitly intended as “to move away from the current usage of Oracle products under the existing conditions”. And in that case, you’re not really trying to move “away from Oracle”. You can achieve this by better-fitting application of (maybe still, partially) Oracle-technology under better conditions. A migration of part of the stack to the (Oracle) cloud and a dynamic pay-per-use model may be a more appropriate move than completely giving up on everything that has to do with Oracle. Or refurbishing the current Oracle stack using the 15 years of innovation and new features in that technology that an organization has overlooked all along.
If you use today’s technology like you used the older versions 15 years ago, you will get the results you got 15 years ago [and you do not benefit from 15 years of innovation]
Even if the current Oracle landscape does not function well or cheaply, it is conceivable that with those same products good results can be achieved, by making more efficient and better use of the products, for example. I regularly meet Oracle developers and administrators who use the 2020 technology as they did with its predecessors in 2010 or even in 1995. Cloud has accelerated the innovation of the technology stack even further: on a quarterly or even shorter interval, new features and better mechanisms are released. Better knowledge of the current capabilities of technology and a more modern process design for software delivery and operational management of that software can lead to substantial and surprising improvements in results.
For all technology components and systems created with them, a roadmap is extremely relevant. A direction for the onward journey. The 6R model describes various directions that can be considered: retire, retain, rehost, refactor & rearchitect, replatform and repurchase. Very briefly to indicate as: say goodbye, preserve (and possibly modernize), bring to a new environment (often the cloud), modernize and improve (renovation on the same foundation), rebuild with newly selected platform components, replace with standard solutions.
6R: Six ways to move away from current Oracle components
The wish to move “away from Oracle” could be explored in the following way: a journey from the current situation based on certain Oracle products in terms of cost, flexibility, manageability, security and scale to a desirable situation in which agile controlled software can be developed, rolled out and managed with an attractive TCO. This image visualizes these options:
The desired situation includes people (and their beliefs, engagement, history and emotions, skills and expertise), culture, process, resources and 3rd party products and technologies. Oracle products could have a place in that desired future mix.
Move away to where — and how?
The choice to discontinue one product or technology is generally the result of the decision to use another product or technology. The desire for something else results in the choice to let go of the present. As far as we are concerned, “not Oracle” should be the outcome of a process in which a careful evaluation has been made and a conscious decision has been made to ‘move to somewhere’ : to start using a particular product that in turn replaces an Oracle product.
When making these kinds of choices between retaining or phasing out and replacing, different aspects are looked at. The criteria used to compare the alternatives to a particular technology building block include, for example:
- fit for purpose,
- functionality (what can be done with a particular product or technology component),
- security,
- stability and scalability,
- currency / up to date-ness,
- cost and productivity (acquisition, development, management, maintenance),
- market acceptance,
- product roadmap,
- and fit with the existing landscape and organization.
The business reliability of the supplier — as objectively expressed as possible — is also a criterion.
Migration to the alternative
If there is an alternative that scores better than the current solution, the question arises as to what a possible migration scenario looks like. What does it cost, who can do it, how much time and effort are required, what is the availability of resources and what downtime is acceptable, what risks does that present, how much impact is there on the ability to deliver new business functionality? A not insignificant consideration is the involvement and motivation of the employees: would they like to make the transition to this alternative technology and is it feasible given their skill sets and learning capabilities and in view of existing responsibilities? Have they been involved in the decision process already in an early stage?
Money always plays an important part. The cost of a migration is often difficult to estimate — because it is composed of many elements, some of which are typically uncertain. It includes the write-off of the not-yet fully depreciated applications and platform components, as well as the training and temporarily lower productivity of affected staff. The cumulative investment — in money, knowledge and emotional involvement — in applications that are sometimes more than twenty years in use is much greater than is often recognized. The effort required to unravel the interconnectedness of this application with other systems and with the organization is great — as are the risks.
If it were possible to do so, this migration, like any major change, should not be taken in too big steps and certainly not hastily. Adoption of an incremental approach does however incur other challenges like the need for replication mechanisms between the old and the new solution. So, this should be planned properly upfront, to avoid decisions on the basis of wrong or incomplete assumptions that may lead to additional costs.
In order to achieve a successful replacement of components already in use, full functional and technical specifications and test sets should be available that describe in detail what and how the components are used. Using these, we can plan and estimate the as-is replacement path (which itself has little business value).
In reality these specifications are rarely complete and up-to-date and so the drafting of a detailed description will often have to be part of the process. This research can be used to build support for the replacement and to identify the low-hanging fruit in terms of optimization. Moreover, procedures and tools for CI/CD and for operational monitoring and management must also be part of the inventory and final migration.
What should the application even do?
The presence of automated testing at all interaction points between the system to be replaced and other internal and external applications is of great value in assuring the correctness of the replacing components and thus reducing risks. Such tests are also rarely fully present and must therefore be built up as part of — or in preparation for — the migration.
Each activity can be made simpler and less risky if it can be broken down into smaller steps. We will try to do the same in a migration journey from Oracle to something else: define meaningful plateaus that allow us to do the replacement step by step.
A technology migration is also about people and processes
The staff involved — or the people working for the outsourcing partner who manages and maintains the applications — form an important part of the migration process. Their functional knowledge and craftsmanship are of great value, also on the other side of the migration. The context in which they work is changing — and in this change they will have to be trained, coached and often even seduced — in order to carry out their work autonomously and motivated with the new products and technology. Not all employees may want or are able to continue in their roles after migration; that can be an additional challenge in the HR field.
What now?
If you want to move away from Oracle — we would like to come and talk to you. To understand why you would want that, and to determine what exactly you want and expect to achieve by moving away from Oracle. To get a picture of the baseline situation and the existing use of Oracle products. We would like to jointly identify the possibilities, potential benefits and impact of migration paths. And also to support the eventual actual transition of an Oracle product to the stated goals and make your organization successful with that new technology.
Oracle-technology has ensured continuity of IT and day-to-day operational performance for decades, also for organizations that now declare they want to move away from it. If you’re still going to replace that technology, it’s good to make a list of things associated with the Oracle-technology that you (still) appreciate, use daily and need for business. They have to come back somehow in the replacement technology you are going to select — and that might prove to be non-trivial.
If there is no positive business case to be made to support your desire to leave Oracle — neither in money nor by other measures — then we will tell you so unequivocally. To prevent your irritation and other emotions from becoming your bad counsellor.
Moving away from the problematic state of IT in many organizations makes perfect sense — in order to achieve a situation in which IT can propel the business as it used to do decades ago, when the current legacy situation originated. This undoubtedly means shedding some Oracle products. It may very well involve retaining and even adopting new Oracle technology offerings.
