To make a significant change happen inside an organization, some steps should be followed. In the following article, I will express my thoughts on how utilizing technology and technical competency can assist companies to clear a path for themselves in the future.
The idea I want you to take away from these steps is: “You should start now!”
Realize the change is needed
For an organization to change, the realization that change is needed for the organization to survive should be made first. A significant change is always met with confusion; people in your organization are going to feel like they are doing something wrong. Although change starts off with passion and creativity, eventually colleagues will be confronted with a feeling of incompetence. This feeling of inadequacy and the realization that it will take effort to realize the change often results in negative feelings throughout the organization. It is exactly this negativity that we want to avoid since it often results in complications with the required change.
So how do we tackle these negative feelings? A personal favorite approach of mine is conducting a pilot project and building a coalition of support. Management should make sure that the passion and enthusiasm, together with the results, are shared with the rest of the organization, allowing for the idea to slowly spread and take hold of the general mindset within the organization. The initial negativity will be replaced by a fear of missing out, potentially motivating those individuals who initially had a negative opinion on the change.
Having a small team working on a pilot project also means you can quickly identify whether the idea will bear fruit. In “lean” terms, you can “fail fast” without the impact on the rest of your business being too large.
Build the competence in the technology needed
Starting with a small team leads us to the second step in guiding an organization towards a change, building competence. I am not a fan of classical software architecture. Architecture should be agile and there should be almost no boundary between architecture and software design. When I talk about competence, I imply the automation of guidelines and sharing knowledge. I am a firm believer in craftsmanship and its pillars which I have explained in my previous [blog post]. To quote a brilliant colleague of mine: “I do not care about guidelines which cannot be automated. If I cannot script or lint your guideline it means nothing to me! – Jasper”.
Position the new technology within the organization
If the new technology or system succeeds within the organization, a snowball effect will be triggered. Usually, decisions made top-down will almost always hit resistance and this resistance will only dissipate when the decision has become part of the culture. I see this as a difficult and ineffective route. It is far easier to prove the success of a new way of working by building software and then convince people of its benefits. This will lift the arguments from an academic discussion into a practical, tangible piece of code that can be observed on a few key metrics, like, speed of delivery, quality, and security.
The second route also gives your organization an organic way to adopt the change. Once the new teams integrate the new competence and start to become more proficient and efficient, other parts of the organization will want to participate. Sharing knowledge about the new competence will be encouraged. And engineers will want to join their team(s) because they share the same passion for competence and craftsmanship.
Your new competence, once proven, will take on a life of its own. It is important to let this grow naturally, aligning the organization’s incentives and values along with this new change will help speed things up. Each organization should be steered on values. A value is something you want to optimize for. For example, if your value is "software development" you should not focus on buying software from vendors. You should focus on getting talent and motivate/help this talent build the best software they can. Let your new competence flourish while respecting your organizational values.
I've seen organizations try to accelerate too early more than I care to remember. Acceleration will not help you fix your problems since fundamental problems simply cannot be fixed while accelerating. Only accelerate if you are confident that the architecture, teams, and business are ready to accelerate and feel competent in doing so. It might feel counterintuitive, up until the entire organization is confident, acceleration will result in chaos and a reduced speed of delivery.
Acceleration is, in my opinion, a managerial problem and not an engineering problem. If your company creates physical things such as CPUs or rockets, scaling up the delivery means automating the manufacturing process. With software however, acceleration derives from splitting your software into the correct building blocks and giving teams the autonomy to perfect their work. Luckily, we as a software community have already been given the tools to scale up, accelerate and structure our organization in the form of Domain-Driven Design by Eric Evans.
In the latter part of this article, I would like to discuss how Domain-Driven-Design (DDD) van help organize and create software that drives organizational change. First, let’s dissect the concept of Domain-Driven-Design. The best definition of a Domain comes from Eric Evans: “Every software program relates to some activity or interest of its user. The subject area to which the user applies the program is the domain of the software. Some domains involve the physical world: The domain of an airline booking program involves real people getting on real aircraft. Some domains are intangible: the domain of an accounting program is money and finance. Software domains usually have little to do with computers, though there are exceptions: the domain of a source-code control system is software development itself.” When translating a Domain to the way we should structure teams, I would advise putting the care of a Domain within a single team. A team that has a passion for that Domain, a team that will take ownership. As I have explained in my previous articles, taking ownership is what happens when engineers are proud of what they have accomplished.
When a Domain becomes too big
A Domain contains a set of Bounded Contexts. Again, Eric Evans gives the best definition of a Bounded Context: “The delimited applicability of a particular model. Bounded Contexts gives team members a clear and shared understanding of what must be consistent and what can develop independently.” If I had to rephrase this, I would say that a Bounded Context is a cohesive set of data that has its own set of operations. I could have chosen many different definitions, but this one lends itself perfectly to the goal of forming a team. The reason why it is so powerful is that a Bounded Context is the perfect boundary of a microservice, and a team can have ownership of a few microservices. Eric Evans has a great [talk] on how Bounded Contexts are the perfect boundaries for microservices.
From Legacy to Domains
The last point I want to address is the problem of legacy software or big monoliths, which might seem to impede the DDD approach. I would say that even in the legacy software your Domains are represented. The only difference is that they are realized by a generally too big monolith. Go through the same exercises as when you are defining your Domains and break the functionality down to the Bounded Contexts, the actual operations on a cohesive set of data, and see if your organization would benefit from abstracting the data or the operations into a microservice. If not, leave them in the monolith but let a Domain Team take ownership of these operations. If you can find the option, abstract the calls to this monolith in the form of a simple API proxy. This way the operations are neatly bounded by a simple API that can evolve independently from the monolith. You can even add caching, either through daily loads or through memoization.
Change is inevitable. It is not constant, it is exponential. Everything is turning into either a software or hardware problem. Classical organizations need to adapt to a faster-changing world. Domain-Driven-Design is as relevant as it has always been in combating this problem and through the creation of the right Bounded Contexts and letting teams take ownership of these Bounded Contexts you can help your organization stay relevant and even help it to flourish in our ever-changing future.