Hello, my name is John Pocknell from Quest software. I work in product marketing. And in this series, we're going to be talking about DevOps, and in particular, database DevOps, which is a big challenge for a lot of companies struggling to figure out, how do we get this slow moving piece of change process into a fast moving DevOps pipeline?
So it's a very interesting topic. It's one which challenges many organizations. And I will be citing some companies for whom they've managed to embrace database DevOps, manage to bring database operations into their DevOps pipeline, and are now much more successful as a consequence.
So if an organization has implemented DevOps, things are a lot different than they were before. DevOps requires a lot of cultural changes, a lot of organizational changes. Because people have to work much more collaboratively than traditional companies work, where you've got silos. You've got people that are working in operations. You've got people working in development, QA, all these different functional areas working together.
And that creates a lot of problem. And actually, the word DevOps is a portmanteau of development and operations. And it just speaks to the fact that development and operations should really work together for the good of the business, so that the business can be much more agile. That's where the need for DevOps comes from.
At the end of the day, there's a need to be operating in a much more agile way. So that you can respond to market changes quicker, and deliver business value much faster than you were doing before. So for us to paint a picture of a company that has successfully embraced DevOps, it's one in which the business is able to realize value much faster than they're able to do. They're able to react to market changes much faster, and able to innovate faster than their competitors are able to do.
So it's a best of all worlds, where they're a much more successful business as a consequence of that. That helps drive revenue. It helps drive brand awareness, and more customers are likely to go and embrace whatever that company is offering as opposed to a similar competitor. Because they feel like change is happening much faster. They can see the change happening much faster than perhaps other similar companies are doing.
So DevOps enables a much more collaborative approach. It brings different functional groups of people together with an organization, which lends itself well to better collaboration. Simply, because different people are able to learn more about what other roles people play within an organization. And if you put people together into groups, project teams-- in fact, a term that is coined often is called tribes. So a tribe is typically a mixed functional group, where they're all working together on one project to deliver change to the business faster than they're able to do before, enable the business to be more agile.
And I can think of a financial services company in the east coast US. They were trying to embrace DevOps. They got DevOps culture on the way, but the sticking point was their database change management. Their database change management was still using a traditional waterfall type of release.
For them, they could only release changes to their production environment on the database side every eight weeks, which is too slow. The business demanded a 4X improvement on their ability to release database changes, but the problem for them was that they were still following a traditional approach the database change management. They had manual processes. In some cases, they weren't doing some things they really needed to do in order to not only move faster, but without compromising the quality of their data and the reliability of their application.
So the reason a lot of companies fail to achieve this is because they're not being driven from the top. There is no vision. It's something which may have come up in conversation. And IT is left to try to figure it out, which is not going to happen, frankly. But also, because there's still a lot of reluctance to change the way that you've been doing things.
Change is very difficult to embrace, right? Particularly in database change management, which has been following the same process for 30 or 40 years. And so to implement a new approach, where now you're automating things, there's an inherent mistrust amongst database administrators to automate anything. Because DBA's are the gatekeepers of that data, because they have a vested interest in protecting the business data. So if they feel like their job is being undermined because of the introduction of automated technologies, then naturally, they're going to feel a bit averse to that.
You might decide, OK, all this is too complex. Let's just keep doing what we're doing, but the downside of that, ultimately, is the business will not be able to be as agile as it aspires to be. They want better react to these market changes, the faster they need to be. And they may fall behind their competition, who, in the meantime, is innovating.
They're moving ahead with automated processes and made a success of it. And they have stolen a march, if you will, on you. So in the next video, we're going to talk about, how do we get started with database change management moving forward from a traditional waterfall approach to moving to a more agile approach?
06:11