This is one of the most consistent questions we get when talking with SAP development shops about DevOps. As we’ve worked to develop our DevOps solution structure at Mindset, we continue to view DevOps execution work as falling into 3 main categories of work: Practice, Process, and Technology. Perhaps counterintuitively, I consider technology to be the least urgent of the three categories. The fact is, it is possible to gain a lot of the benefits of DevOps with process and practice alone, while approaches that focus on technology to the exclusion of practice and process do not see a lot of success. Tooling tends to fall into the technology area, and so I shy away from an initial focus on it because there are so many other things that need addressing with higher priority.
That said, tooling choices do matter, and we can offer some guidance. The general rules of thumb that I try to guide customers toward are:
-
-
- Good enough is good enough
- Use what you have
- Manage change organically
-
Good enough is good enough
You don’t need the perfect tool. The DevOps space is seeing great competition among tools and most of the major tools provide or will soon provide most of the capabilities you need. When doing tool selection, identify the tools that are good enough, which will usually be any of the leading tools in an area, then look at vectors other than features on which to make your purchasing decisions. Usability, price, and availability should all factor at a far higher level than any given feature.
Use what you have
Especially in the case of SAP development shops, which tend to have come relatively late to DevOps, there are usually already DevOps tools in place in an organization. Chances are that if your organization is doing any amount of non-SAP development you have a source control system like GitHub Enterprise, BitBucket, or Gitlab in place. You’ve probably got a CI/CD tool and issue management as well. They may even all be integrated. As long as the tools in place meet the “Good enough” bar, use them. Using the same tools as the rest of the organization will get you up and running faster and will make future integration with the rest of the organization easier. It’s becoming more and more common to have to manage releases as a portfolio across multiple software systems with dependencies. Using shared tooling can make that a lot easier.
Manage change organically
Sometimes you do have to change tools. Ideally, that change is attractive to those using the tools to do development work and those using the tool to manage development work. If it’s not, you may want to reconsider your choice. Change to a better tool can be driven organically, through evangelism and training in the organization. However, it still needs management! Further, change management is a key capability in the work of driving DevOps adoption across an organization. To identify the key metrics of adoption, the targets you want to get those metrics to at what times, and manage those metrics. However, one suggestion: measure at least one “customer satisfaction” metric.
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
