Aligning technical Infrastructure with business needs: Talk to the business

Clean code, delivered on-time, with the required feature set — job done? Only if you’re satisfied with adequate.

As software developers we bridge the gap between business problems and technical solutions. By spending more meaningful and engaging time with the business, we can find opportunities to align the two domains which we were previously oblivious too.

 

The title of this post is a quote from Udi Dahan’s distributed systems / SOA course where he consistently talks about probing and understanding the business. In this series of posts I’ll make references to them and I’ll also share some concepts from Scott Millett’s DDD book. 

This post will be about extracting extra knowledge from the business, and the next post will be about aligning infrastructure with this new knowledge. At the very least, my aim is to make you think a bit deeper about your role, and aligning with the needs of your business.

Talk to the business

Extracting knowledge from the minds of business people is probably the most difficult aspect of this process. Not because they are unwilling, but because sometimes they make assumptions that you don’t know about. Sometimes, even they themselves need to think deeper about how the business works. Your job is to probe them into having these thoughts. 

In his book, Scott elaborates on the DDD concept of knowledge crunching, and making the implicit concepts explicit. He provides simple advice such as regular whiteboard sessions, and talking through use cases of your system with business experts — this gives them an opportunity to flag up cases where business needs can be aligned, and it gives you, the developer, opportunity to ask questions and understand the domain better. 

Even if you are not doing DDD, talking to the business is still crucial. Aside from knowledge crunching sessions, at 7digital the head of technology decided that business and technical people were going to sit together (the horror!).

This actually worked out very well in some respects, and has led to some breakthrough conversations which I’ll return to later.Get the whole team involved

At 7digital I found the whole team was interested in providing suggestions to better align with the business — from juniors to senior developers. In the example I’ll shortly talk about, we all built on each other’s ideas to arrive at a number of solutions — and we were all able to talk to the business directly (sitting close together again helps a lot). 

This concept relates to what Scott refers to in his book as “Team Modelling”. Scott wants you to empower your developers with knowledge of the domain by allowing them to attend sessions with business people, and continually have dialogue with them. 

Another benefit Scott cites is that business people can contribute to the software design, and tell you where it doesn’t quite align with optimal business needs. 

Scott feels it’s critical to continually have the sessions, and I totally agree. It takes time to build up mental representations, and understand the business domain. Give yourself more opportunities to maximise your growing knowledge.A true story

Our system was growing, incorporating new customers and increasing data volumes all the time. This meant that a batch job that runs on a per-customer basis was taking longer, and longer all the time. 

Effects soon became noticeable to customers, and they were often expressing dissatisfaction. The business was also upset because they looked bad. Us developers, we were especially upset — we wanted to make these people happy, but we needed a lot of time, effort, and extra resource to make a much more scalable, performant solution. 

After analysing the feedback we continued to receive, and a brilliant idea from one of my colleagues, we decided to probe the business experts. “Which customers are the most important?”, and “which customers don’t need the same priority of service?” we asked. 

“That’s really important, but I don’t know, let me have a think” said the business expert with a big smile. We had started to unravel an implicit business concept — customer priority. It was all made possible by involving the whole team, spending time with domain experts and especially being located within close proximity (I hate admitting my boss has good ideas). 

Now we didn’t have to make a massively scalable solution giving all customers the exact same priority. We were going to get some SLAs from the business on a per-customer basis, and we could modify our existing solution much more easily. Everyone wins. 

It really helped to have the mindset of “talk to the business and find missing concepts” which Udi Dahan repeatedly keeps talking about in his course, and Scott re-iterates through his book.Using this knowledge

In the next post I’ll detail what happened with this new knowledge — the number of implementation opportunities at the hardware and software level that now became possible. Also, the opportunity to be metrics driven — to define acceptable levels of processing, in line with the business’s new customer priority rule we had helped to uncover. 

I’ll also relate this back to some of the more general implementation patterns you can find in Scott’s book and Udi’s course. They might be more applicable to your scenario, or general enough to get you thinking about how you can better align your technical infrastructure with the needs of your business.