Know your Domain of Development for better DevOps outcomes

DevOps as a buzzword and as a philosophy has come a long way since the term was coined in 2009. DevOps practices and tools have evolved over years and many teams have demonstrated early success to prove it works. The missing piece is that most still haven’t been able to broadly replicate and scale that success.

Scaling DevOps beyond early adapters require lot more than tooling or practices. In my experience working over 20 such transformation engagements for different clients (teams ranging from 100 to 40000), different industries (Finance, Insurance, Healthcare, Marketing, Education etc.) and different geographies, I have found 5 key challenges that impedes DevOps scaling in an enterprise.

1. Culture — When you observe a gap or misalignment among your decisions, actions and behavior, you have cultural issue to fix. It denotes your fundamental value system is not followed.
2. Capability — Over 70% organizations are finding it difficult to find the right talent for their digital initiatives. It’s becoming an industry wide issue where people lack the ability to learn, unlearn and relearn.
3. Org Structure — Most organization structures are not designed to collaborate. They result into silo-based information, conflicting goals/priorities between departments and slow decision making. The ability to self-organize is neither encouraged, nor supported in such environment.
4. Fear of Failure — Most organizations don’t fund experiments or don’t have a hypothesis-driven funding model. This leads to innovation vacuum.
5. Measurement — Whilst organizations measure many metrics, they lack the ability to map metrics to business goals. This leads to a lot of data but the purpose remains unknown.

Whilst these challenges are not new, they need continuous efforts all across the board. Depending on your environment, you can identify quick wins and strategic changes to drive a systematic plan of action. There is no quick fix whatsoever. You have to relentlessly execute, monitor and adapt.

What is the Domain of Development? Where does it fit?

When I coined the term “Domain of Development” short form DoD, people amused at this acronym because it has a different notion (definition of done) in the agile world. So I stopped using the short form and don’t use any more to avoid confusion.

The Domain of Development refers to two most important aspects of construction process i.e. “What you are building?” and “How to build it?”. In other words, when it is combination of:

1. Value Stream
2. Tech stack

Both of these impact the toolchain choices.

For ex: for modern languages you might have one single tool chain handling all through to CI and CD (some languages are interpreted and some are compiled so steps for build might be different, mode of deployment might be different when some gets packaged but some are direct filecopy. However, modern tools like Gitlabs/Jenkins/ Azure DevOps pipelines/ Puppet pipeline etc handle that well and maintain the differentiation through flexible configuration. So one toolchain might suffice but you may need different pipelines setup for different tech stacks.

For legacy or enterprise apps, the choice of tools might be very different. For example — SolMan for SAP comes with very different “transport” methods. Instead of using Git,Jenkins, Ansible etc, you are dealing with tools from SAP or 3rd party vendors for code inspection, transport management, test automation, environment refresh, performance testing etc. In addition different tools may be required to cover different SAP platforms — Hybris ( Java Stack) and ABAP stack. So you may be dealing with two separate tool chains and few pipelines when it comes to SAP. Take another example for mainframes and the storyline might look very different.

If you are dealing with a data lake or IOT project, your value stream as well as tech stack may be very different and thus your toolchain/s and pipelines may need different handling.

So before you start to automate your DevOps pipeline, I strongly recommend knowing your Domain of Development. It is critical to understand the steps involved as it would have direct impact on your pipeline and automation feasibility. The practices and principles are same but the application / nature of implementation would differ from one Domain to Development to another Domain of Development.

One such example is Industrial DevOps — the idea of bringing the principles of DevOps to the industrial environment. (read more here: https://www.industrial-devops.org/#industrialDevOps)

Call to action:

Before you start your DevOps scaling journey:

1. Understand the Domain of Development for different initiatives
2. Map out the Domain of Development to your pipeline and adjust accordingly
3. Work through the challenges and define an action plan that you can track and sign up to