AMIS 25: DevOps Best Practice for Oracle SOA and BPM

Editor's Notes

• #4: Let me give you a little bit of information about Rubicon Red. Since its original founding in 2009, Rubicon Red’s mission has been to lead customers to success on their Oracle middleware journey. This is the origin of our name; helping customers cross the “Rubicon” in their successful adoption of the Oracle Middleware “Red” stack. Rubicon Red is a recognized global thought leader in Oracle Middleware, delivering innovation and unrivalled expertise. We have authored several books on Oracle Middleware, including what is regarded as the premier book on implementing Oracle Middleware solutions. We have been featured on the front cover of the US publication CIO Review, in an edition identifying the top 100 Oracle Solution providers globally. We are consistently recognized by Oracle as the Oracle Middleware Top Technical Champion for Asia Pacific. In 2014 Rubicon Red received 3 global innovation awards from Oracle. This was the first time a partner received that many awards – something even the largest Oracle partners haven’t achieved. We sit on multiple Customer Advisory Boards,  at Oracle’s invitation, providing guidance to them on the direction of their Middleware Product strategy.
• #5: In today’s companies the end service delivered to the customer is not performed by a single system; but rather a patchwork of applications, each one performing a particular business function. Middleware provides the modern application infrastructure to combine these business apps, like puzzle pieces, into an integrated solution in order to deliver a seamless and unified experience to the customer. Oracle Fusion Middleware, by Market Share is the leading Modern Middleware Platform. 30 seconds
• #7: Oracle/Antony
• #9: High profile technology failures are increasingly common. On average - a single major technology failure can cost a business as much as $US 10.8 million. With 45% of organisations experience a loss of brand equity or market share following a major technology failure 20 seconds
• #16: /Antony
• #17: The manual process of provisioning Oracle Fusion Middleware environments, and the testing and deployment of code into these environments is often one of the most painful, resource intensive and stressful parts of any Fusion Middleware implementation. Small errors – such as misconfiguration of a middleware component, or deploying the wrong version of a software object – can wreak havoc on the newly deployed solution. Many weeks of man effort can be lost wrestling with builds and environmental issues; constant project delays, missed milestones and uncertainty are all too common. The business is frustrated when “development complete” code can’t be released, or unreliable code not fit for purpose is pushed into production – leading to the inevitable fallout and fire-fighting.
• #19: Critical PROD issues need to be re-produced in SUPPORT env Oracle will request this to resolve P1/P2 Service Requests If Environments out of Sync – this is often not possible! PRE-PROD is last chance to capture issues before PROD If PRE-PROD configuration different to PROD, higher probability a release which works in PRE-PROD will fail in PROD Each release into DEV, TEST, SIT, etc. contains latest release, plus remains of previous failed releases FALSE POSITIVES, with the release failing when promoted to next environment. FALSE NEGATIVES, with time wasted troubleshooting a non existent error.
• #27: Firstly, scripts are frequently written to a "good enough" standard to solve the current requirement sets, this results in brittle code that is difficult to change as requirements change. As a result scripts tend to evolve over time, leading to spaghetti script that is very hard to maintain, and can quickly become a full time job.   Of course the other issue here, is what happens when the person who wrote the script, either changes role or leaves the company? What is left is rarely documented and due to the spaghetti nature incredibly hard for someone else to pick-up and maintain, especially without breaking a few things along the way.   Secondly, because the scripts are written to be just "good enough", rarely is sufficient testing performed, so its easy to end up with buggy scripts, requiring manual work around's to fix. In fact its quite normal for scripts to get out of sync with the actual required environment, causing significant issues from a governance perspective, which can also quickly render the scripts obsolete.   Thirdly, scripts are tied to particular releases of a product, so as new versions of the product are released (especially major releases, such as 10g to 11g, or 11g to 12c), then the scripts often need to either be re-written or need major re-factoring. For example, I know of one Oracle SOA user has invested in excess of 5+ man years writing scripts for automated deployment, who is now having to throw most of it away as they won't port to the latest release.
• #29: Rubicon Red Key Points How to build and provision similar environments in the cloud and in the data center. Need to ensure that code that runs in the cloud works equally well when moved to Production (on-premise).
• #31: Rubicon Red
• #39: Rubicon Red