(but don’t try to solve all of them)
IT development projects can suffer from problems that are addressed within the wrong domain. I’ve encountered many projects where a development team implemented requirements that in the end did not add any business value, purely because they tried to automate a business process that was far from stable. Sounds familiar?
A recent example I encountered was at a company that sells pre-paid services (on a contract basis) with included and optional components. The system we’re building should enable customers to manage their own contracts. Customers are allowed to upgrade their contract (add additional components or increase their capacity) at any time but in case of a downgrade, a notice period applies, meaning that downgrading is not actually possible. However, no notice period should be applied when the customer adds other components to the contract or to a contract for another service AND the total customer portfolio value (in Euro’s) does not decrease significantly (whatever that means).
Sounds complicated, especially when you realise that upgrading and downgrading is a serial process (one contract at the time), so you never know if the portfolio value is going to increase or not. To make things worse, account management is allowed to make exceptions, for customer relation or strategic purposes. Unfortunately, human decisions are as easy to understand and implement in code as Bistromathics.
So, the requirement is that customers are allowed to downgrade in some cases. A previous development team took the challenge of automating this but failed, throwing away an enormous amount of development hours. Their mistake? It’s not a software problem, it’s a business one! The business logic and process are far from clear and, due to changing market needs, there is even a strategic discussion within the company on getting rid of notice periods completely!
At VX Company, we use architecture principles to remain in control of projects. One of my favourite ones is: problems should be addressed within the right domain.
To keep it simple, for software development we have identified three domains where problems can occur:
- Business domain. This is the domain of business processes, organisation and people but also the domain of (the need for) information.
- Software domain. This is the domain of code and data.
- Infrastructure domain. This is the domain of servers, platforms, networks and so on.
Note: Software and infrastructure are sometimes regarded to be one domain (the IT domain) and in the world of DevOps they are getting closer indeed. However, for most solutions there is still a distinction between software and the infrastructure it is hosted on. One might argue that there are more domains, but let’s keep it simple folks.
An implication of this principle is that we do not automate business processes of which the business is still making up their minds or that are likely to change in the near future. Is the business process quirky? Optimise it before automating it.
Another implication is that in case of a performance requirement, we might not necessarily spend time optimizing code but, for example, add extra CPUs to our server and upgrade the storage tier. If the problem is within the infrastructure environment, fix it there!
Those requirements again
A problem is always related to one or more (functional or non-functional) requirements. If we don’t require something, we’re surely not going to build it and thus will not encounter any problems. If we do have requirements, we can just go ahead and start building something without thinking about it and run into problems along the way. Or we could analyse the requirements first to identify potential problems.
IMHO, it’s the latter option: we should analyse requirements properly and I might post something about what that means in the near future. I prefer an analysis before the start of the project, but as not all details might not be known at that time (only the epics are known, not the user stories), before the start of a sprint is also fine. When you find a (potential) problem in the analysis, determine the domain it belongs to and solve it there.
Figure 1: “Problem domain identification”
So, what did we do with our downgrade problem I mentioned earlier? We gave it back to the business and decided not to write a single line of code for it yet. The business did come back with some additional business rules, but the problem was still complex.
When the problem looks complex, it probably is. Don’t try to solve it.
There is a difference between complicated and complex (see, for example, an article in The Washington Post on school reform). A complicated problem can be analysed and solved, for example by coding algorithms and implementing business rules in the software. It’s predictable.
A complex problem means that there are many parameters, parameters that can change. It’s dynamic, unplanned, maybe leaning to wicked.
I’ve seen development teams struggling to solve a complex problem with software, requiring huge effort and not leading to an acceptable solution. I’ve seen business managers struggling to identify their processes and business rules and trying to repair processes that were wrong in the first place (like not being aligned to the company strategy). I’ve seen ops struggling to keep their infrastructure performant while the problem should have been addressed in the software domain (bugs, wrong configuration etc).
If you encounter a complex problem within a domain, it’s probably allocated to the wrong domain and should be reallocated (see figure 1). Evaluate if it’s still complex there. If it remains complex in any of the domains, drop the requirement related to the problem and go back to the drawing board.
Figure 2: “Reallocate a complex problem”
In our case, we concluded that even with some additional business rules, the problem of downgrading was complex in the software domain but also in the business domain (too many views and opinions, no alignment with strategy). The requirement for allowing customers to downgrade their contracts themselves was dropped for now, we added a phone number to contact account management and did not build in any downgrade restrictions in the backoffice. It’s up to the account manager to decide to downgrade or not.
And they lived happily ever after? Not quite, there is still a business requirement but we’re going back to the drawing board and align the requirement with company strategy. Just another day at the architect office…