Can DevOps Transform Your Time to Market?
How to navigate from a potential nightmare to a smooth reality
One morning, you enter your office. The air is cool and getting cooler when you get the news: "Your immediate presence is required in the CEO's office."
All LBU and LoB heads are there, and the atmosphere is tense and nervous. Suddenly, everyone quietens down and looks at you. The CEO poses the already anticipated question, “When will the new, fully integrated self-service portal be ready?"
But you can’t answer. Actually, you don't have a clue. The integration with the CRM and billing software — not to mention the product and tariff management — is so complicated that nothing can be predicted. Testing alone will take ages. "Months from now" seems to be the most honest response. But the CEO answers the question for you: “You've got a week from now, or I will expect your resignation.”
The chilling and stressful story above is not a fictional scene from a thriller but a realistic portrayal of a CIO's life in the digital era.
But it doesn't have to be. There is a way out. It's called DevOps. "But what is DevOps?" you say, "And what the hell is BizDevOps?"
One way to define DevOps is an agile methodology combined with a set of practices that unify business, development, testing, deployment, and operations into a team responsible for the creation and continuous delivery of business capabilities.
Sounds suspiciously promising, doesn’t it? Well, to bring it off successfully, you need to establish certain circumstances in advance. Let’s begin with a framework.
Starting with the business environment, you have to learn, consider, and understand the impact that digitalization will really have on your company and, in particular, on your IT department. Here's what your digital enterprise should look like:
- You enter a hyper-competitive and fast-moving environment.
- Speed, agility, and time to market become competitive differentiators.
- Software integrated applications are the new battleground; every company is becoming a technology company!
- Customer experience is a required metric.
- Change and organization management are core competencies.
Once you understand all the impacts of deploying DevOps, we suggest translating them for the major corporate stakeholders. This will make your transition more structured, transparent, and effective.
- Customers (corporate end users)
- Organization and skills
- IT operation
- Application development
If you have already started with agile projects or your application development is already fully based on being agile, then you certainly have a big advantage and “just” need to continue this transformation. From an organizational viewpoint, extending agile to cover business and IT operations would be the next move. Practically, this means involving your business architects, business analysts, and IT operations people in your development scrum teams.
Remember the BizDevOps term from above? Well, that’s what we’re really talking about today. Think of it as DevOps 2.0 — and the involvement of the business is a given.
So, that was the easy part, but let's take a breather.
The bad news is that DevOps is absolutely architecture dependent. If your organization has a legacy culture based on the waterfall model of software development, do not go for DevOps! It will be expensive and useless.
Systems designed via the waterfall model are hard to transform into agile. In fact, I suggest you don't even try. Instead, change the architecture. Now you are laughing, “And where is the business case to justify dropping the last 15 years we have invested in legacy systems and developing new ones?” You don't need one! First, carefully study your current architecture, and then split it into components, like web shops and self-service portals, omni-channel and mobility, BI and big data — the quick wins and what can be earmarked for more gradual change.
Starting to build digital from one corner of your department or company — such as the new CDO office — will lead to a bimodal IT setup. What's wrong with that? Some may point out that, “Bimodal is the practice of managing two separate but coherent styles of work — one focused on predictability and the other on exploration.” I don't believe this is true; it's unsustainable and unworkable. You simply create two competing organizations that result in shortcomings in culture, governance, and resources.
To make the hard part a little easier, start to change your architecture gradually, and integrate your platforms and systems continuously with your processes and people.
Now we've covered the organizational/business and architecture parts, let’s move onto IT operations. For many, integrating IT operations into a scrum team will sound rather unorthodox. They were “enemies” before, and now they are working side by side? Can a scrum master manage this? Admittedly, it will be hard at first, but education and mentoring will help. Luckily, automation tools will naturally help, but they won't be enough. The most important part of the whole DevOps story is people — with the right skills!
DevOps requires a different kind of IT person — actually, a whole new generation of IT people.
You need developers with operation skills, and you need operations people with developer skills. In practice, this means hunting for and educating people with an operations background by default but also with a good working knowledge of codes, scripting, and programming — people who won't flinch when several lines of code must be added or the code needs to be completely rewritten. DevOps-type developers can create a test environment or even a fully fledged virtual machine in any type of cloud and can understand the operation logs and monitoring maps of the systems. While proper staffing may be the most essential part of supporting integration, it will also be the hardest part, as such talent is rare; you simply have to grow it.
Finally, let’s look at tools and automation. To ensure continuous deployment, you need a completely new tool set — one that's different from any you may have used before. The aim is end-to-end integration of the whole process. And these tools don't have to be expensive and complex. Many very good and small open-source (often SaaS based) solutions can be linked together in much the same way that you want to connect your business services.
Jira is a good example of a framework for the whole process. Other tools you may need will depend heavily on your technology. To speed things up, I strongly recommend looking at container technologies, such as Docker, although many other good tools and technologies exist. For example, Vagrant is a powerful tool for making and maintaining your development environment fast and consistent. To avoid countless manual browser tests, try BrowserSync.