Earlier this year, I downloaded a DevOps book to my Kindle. I was preparing for a long trip and two of the five flights did not have Internet. I had been reading discussion and blog posts on the topic for some time and was finding the topic coming up more frequently in conversations with customers and prospects alike. The DevOps book, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win had appeared several times on my recommended reading list. Amazon even knows what I should be reading; they are cool like that. One click later, the book was downloading to my Kindle and I was ready for my trip.
By the end of the second flight, I had finished the book. The thought occurred to me that I may have been doing DevOps nearly a decade ago and didn’t realize it. Now, I am not trying to say I invented DevOps. I did not invent DevOps anymore than Al Gore’s oft misquoted statement that “he” invented the Internet. What I am saying is the story in the book was very familiar to my own story and journey. The familiarity, in part, was due to my having worked in a manufacturing company as did the main characters in the book. I had also faced similar challenges and issues as the fictional characters in implementing new and changed software in their company. But, what I really believe is going to be of interest to you is the role Stat for Oracle EBS played in empowering me to solve the issues and impacts of delivering new and changed software to my company’s EBS application stakeholders.
In the book, the authors describe ‘The Three Ways,' and their mastery, as the underpinning principles of DevOps. For example, ‘The First Way’ is about the left-to-right flow of work from development to IT ops to the customer. The First Way practices include:
- Continuous build, integration, and deployment
- Creating environment on demand
- Limiting work in process
- Building safe systems and organizations that are safe to change
Perhaps you have already read the book or have had some DevOps training and have already made the same connections to Stat functionality I did. For example, doesn’t the left to right flow of work sound like Stat workflows and migration paths? Are not Stat archive set, release management, and mass migration functionality at the heart of continuous build, integration, and deployment? Do not Stat Environment Refresh CSRs, environment refresh tracking, and the ability to sync changes from one environment to a new environment all work to empower creating environments on demand?
While asking myself these questions, I was once again struck by the realization that, much like Sarbanes Oxley audit and compliance requirements, which Stat fulfilled before it became “popular – and I use that term loosely – Stat’s been fulfilling DevOps requirements for over a decade, despite the fact that some of the key terms may be different. You know, kind of like, you say “potato” and I say “spud” but we both still make mashed potatoes! I have been always felt that Stat had ‘good bones’. Keeping the aforementioned Sarbanes Oxley example in mind, when auditors began looking closer at application changes made in EBS and PeopleSoft applications, Stat was able to deliver the requisite control strength and audit reporting required even before SOX was a hit! And now, as organizations look to improve integration and collaboration between development, IT Ops, and other stakeholders, and reduce cycle times isn’t Stat, again, able to meet the challenge? Our Product Team are visionaries like that.
So here’s the deal. If you have read the book or have implemented DevOps in your company, I would like to hear your thoughts and experiences around Stat and DevOps. So please reply to this post. If you haven’t read the book and are new to DevOps, stay tuned. I plan on covering each of ‘The Three Ways’ in detail in my next three blogs in coming weeks. Each blog will cover, in detail, one of ‘The Three Ways’.
In the meantime, check out the book or do some research on DevOps and join the conversation.