Solve problems in the right domain

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 u003cstrongu003eu003cemu003eANDu003c/emu003eu003c/strongu003e the total customer portfolio value (in Euro’s) does not decrease u003cemu003esignificantlyu003c/emu003e (whatever that means).rnrnSounds 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 u003ca href=u0022https://hitchhikers.fandom.com/wiki/Bistromathicsu0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003eBistromathicsu003c/au003e.rnrnSo, the requirement is that customers are allowed to downgrade in u003cemu003esomeu003c/emu003e 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!

Architecture principle

At VX Company, we use architecture principles to remain in control of projects. One of my favourite ones is: u003cemu003eproblems should be addressed within the right domainu003c/emu003e.rnrnTo keep it simple, for software development we have identified three domains where problems can occur:rnu003colu003ern tu003cliu003eBusiness domain. This is the domain of business processes, organisation and people but also the domain of (the need for) information.u003c/liu003ern tu003cliu003eSoftware domain. This is the domain of code and data.u003c/liu003ern tu003cliu003eInfrastructure domain. This is the domain of servers, platforms, networks and so on.u003c/liu003ernu003c/olu003ernu003cp class=u0022fs-m fs-su0022u003eu003cstrongu003eNoteu003c/strongu003e: 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.u003c/pu003ernAn 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.rnrnAnother 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.rnrnIMHO, it’s the latter option: we should analyse requirements u003cemu003eproperlyu003c/emu003e 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.rnu003cfigure class=u0022clearfixu0022u003eu003cimg class=u0022aligncenteru0022 src=u0022https://vxcompany.com/wp-content/uploads/Problem-domain-identification.pngu0022 srcset=u0022u0022 alt=u0022Problem domain identificationu0022 width=u0022451u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/Problem-domain-identification.png 113w, https://vxcompany.com/wp-content/uploads/Problem-domain-identification@2x.png 226w, https://vxcompany.com/wp-content/uploads/Problem-domain-identification@4x.png 451wu0022 /u003eu003c/figureu003ernu003cemu003eFigure 1: u0022Problem domain identificationu0022u003c/emu003ernu003cfigure class=u0022clearfixu0022u003ernu003cfigure class=u0022clearfixu0022u003eu003c/figureu003ernu003c/figureu003ernSo, 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.rnu003ch2u003eu003c/h2u003e

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, u003ca href=u0022https://www.washingtonpost.com/news/answer-sheet/wp/2014/08/08/the-difference-between-complex-and-complicated-and-why-it-matters-in-school-reformu0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003ean article in The Washington Post on school reformu003c/au003e). A complicated problem can be analysed and solved, for example by coding algorithms and implementing business rules in the software. It’s predictable.rnrnA complex problem means that there are many parameters, parameters that can change. It’s dynamic, unplanned, maybe leaning to u003ca href=u0022https://en.wikipedia.org/wiki/Wicked_problemu0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003ewickedu003c/au003e.rnrnI’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).rnrnIf 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.rnu003cfigure class=u0022clearfixu0022u003eu003cimg class=u0022aligncenteru0022 src=u0022https://vxcompany.com/wp-content/uploads/Reallocate-a-complex-problem.pngu0022 srcset=u0022u0022 alt=u0022Reallocate a complex problemu0022 width=u0022494u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/Reallocate-a-complex-problem.png 124w, https://vxcompany.com/wp-content/uploads/Reallocate-a-complex-problem@2x.png 247w, https://vxcompany.com/wp-content/uploads/Reallocate-a-complex-problem@4x.png 494wu0022 /u003eu003c/figureu003ernu003cemu003eFigure 2: u0022Reallocate a complex problemu0022u003c/emu003ernrnIn 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.rnrnAnd 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