End-to-End Oracle Deployments: Top 5 Challenges

Enterprise.jpg

While the complications are many, below I group them under 5 headings, the 5 main challenges we see most commonly facing organisations with complex or diverse Oracle deployments. For more detail, references and how smart organisations overcome these challenges, read our Blueprint for Continuous Delivery & Automation of Oracle.

1.New environments take too long

It can take many months to build a complex Oracle environment from scratch - far too long for smart companies wanting to get new initiatives to market. In today’s fast-moving marketplace, you need more agility to stay ahead of your competition.

The most common culprits for long Oracle project cycles are manual builds. Apart from being wide open to human error, manual builds introduce inconsistencies, instability and defects that often aren’t detected until new applications fail in production. And this can be too late to avoid major impacts on the business.

Another reason is that, to save costs, enterprises often start Oracle projects in-house; then they find need to bring in extra expertise to handle the complexities of Oracle solutions, technologies and Middleware (OFM). OFM is promoted as an integrated solution but it’s more a package of discrete Oracle products - as Alan R. Earls at TechTarget discovered. And this can challenge even Oracle System Integrators.

System Integrators often opt to bring more people to a project, rather than using automation tools that can accelerate deployments and improve their quality and stability. More people doing manual builds can have the opposite effect: increasing the probability of human error, complicating communications and raising the risk of a poor quality outcome. A recent study by PMI (the Project Management Institute) revealed that poor communication lead to Project Failure 30% of the time.

2. Costs are blowing out

Adding more people to projects is an obvious reason for cost blow-outs, and running over time is another. If you think about it, manual builds make a doubly negative impact on the business.  In a recent project, we were asked to assist with, dozens of Oracle environments had been built, installed and configured manually by a large workforce of contractors. This meant other project teams were waiting for environments to be built and patched, while the costs continue to rise.

Complex Oracle projects benefit from specialists who have the depth of experience to sort out issues with OFM, Oracle applications and the whole stack, and the skill to make the diverse components work in unison. That applies especially to new enterprise systems, where the risk of time and cost blow-outs is even greater because unforeseen obstacles require major design changes, or a change of project scope brings additional requirements.

The third impact of manual builds is a hidden one: the longer it takes to get new systems delivered, the longer your IT team has to maintain the legacy systems they replace. These resources aren’t available for new projects, and that puts yet even more pressure on budgets and timeframes.

3.DevOps seems like Mission Impossible

DevOps is a term that evokes strong reactions from different people, but few would argue that it doesn’t have a major role in big Oracle projects. How else do you stop teams working in siloes, and operations teams protesting they’ve been thrown a ‘ticking time bomb’ of new Oracle deployments that weren’t really ready? Once your organisation embraces DevOps principles, you can expect outcomes like:

  • Delivering new capabilities to business users faster
  • Reducing the failure rate of new releases
  • Minimising the lead time between fixes
  • Improving system quality, and
  • Speeding up Mean-Time to Recovery (MTTR) in production systems.

3.1 Obstacles: Lack of Automation, the Wrong Tools, Poor Communications

Recent  research from ZeroTurnaround found that 60% of the failures in DevOps projects are caused by human error or lack of automation, and IDC’s 2014 survey of Fortune 1000 companies found that trying to adapt current tools to deliver DevOps practices, has a failure rate of 80%.

In other words: automating the delivery of Oracle environments is essential for DevOps to succeed, and new tools are needed to make it work. Once you have both Dev and Ops teams working as one, with shared goals and responsibilities, focused on the fastest time to market for new business initiatives, you’ll reap significant business gains.

3.2 The Upside: Faster Time to market

The good news is that the DevOps framework actually speeds projects up, as  Lori MacVittie sums up on the DevOps Blog: ‘Speed with respect to DevOps is effectively equivalent to Time to Market …’ ThePuppet Labs 2015 State of DevOps report also found that ‘DevOps practices lead to better IT and organisational performance,’ and that ‘stability was significantly better’.

The key takeaway here is that ‘DevOps practices equip organisations to embrace more and more change, rather than to fear it.’ That’s the biggest change you face when you embrace DevOps: gone are the days of delivering big systems with lots of functionality all at once. DevOps is about doing the opposite: delivering frequent small, understandable and easily reversible changes. The results:

  • Reduced failure rate of new releases
  • Shorter lead time between fixes
  • Improved system quality
  • Faster mean time to recovery.

4.Complexity is going through the roof

The complexity we find in enterprise Oracle environments is not for the faint of heart. A recent project we worked on had over 40 distinct Oracle products and hundreds of clusters across multiple environments.  In addition there were many non-Oracle systems in place, including legacy ones.

The greater the complexity, the more critical it is to configure consistent environments for the various stages of development: prototyping for architects, coding for developers, testing for the Q&A team, and production for operations teams. The concept of DevOps is to tear down the walls of the silos that separate your Dev and Ops teams. Collaborate, cooperate and communicate are the bywords, and they become much easier to follow when all your teams work across consistent environments built to the same standards.  The business benefits are tangible too: when Dev and Ops teams are in concert, the business can more easily achieve its vision of innovation,  or respond to market or customer demands more quickly.

The greater the complexity, the more urgent the need for automation. Without automation, human error is a given, leading to differences between environments that stop the SDLC dead in its tracks: what worked in Dev doesn’t work in Test, and your people have to spend time figuring out why, instead of moving on the next milestone. The greater the complexity, the greater the waste of valuable time, causing urgent business initiatives or changes take a back seat, and dragging out time to market.

5.Configuration Drift is causing failure

What happens when a new software release fails on deployment? It’s embarrassing for your business, and infuriating for your customers. The cause can be tiny discrepancies between environments that can be hard to detect and harder to fix. Configuration Drift often has really innocent causes like these:

  • Minor fixes, software updates or the installation of a conflicting package or service
  • Mis-typing a configuration value, it should have been port 8001 and was entered as port 9001.

The toughest task in your network is not provisioning or configuration but troubleshooting, according to Lori MacVittie in her post How Deploy Frequency Impacts Infrastructure Stability. She’sright when she says: ‘… if you just deployed ten or fifteen different configuration changes across the core and per-app service infrastructure and suddenly something i

insightsLimePoint Team