The importance of domain knowledge

The importance of domain knowledge

If you’re part of an organisation where software is key to the successful running of your business, there are probably lots of areas where you’ll engage people to work with it, from writing code and designing interfaces to research, maintenance and support. Of all the things these people can offer your business, one of the most valuable is domain knowledge; an in-depth understanding of your business, process and industry.

Gathering this knowledge can be an expensive process, requiring an investment of time and money, as well as potentially incurring efficiency and productivity losses as you bring people up to speed. How then can you ensure that your development teams have the level of domain knowledge you need while ensuring your budget doesn’t spiral out of control?

Talk to one of our digital experts

Tom Houdmont

Head of Business Solutions

Do you have an idea or a project you need support with?

Tom leads Box UK’s Business Solutions team and has over 15 years experience in the web industry.  Tom is passionate about creating impactful solutions that solve real problems and deliver the outcomes our clients need.

Book a meeting with Tom

Or call us on 020 8098 2093

Different approaches

One option is to have full-time staff working on your software in-house; people who are 100% focused on you and your business and who subsequently gain an excellent knowledge of your domain. This approach does bring with it substantial overheads (and of course takes some time to build up), plus you also accept the risks inherent in staff turnover. You do however benefit from the security of having the technical skill to maintain your software internally.

At the other end of the scale you could engage external suppliers who support you on a project-by-project basis and accept that this may lead to people working on your software for only a relatively short period of time who therefore can’t gain an in-depth knowledge of your domain. You can do your best to share information, and should specify and reiterate this as much as possible, but always remember that your development team is only working on your project for one particular snapshot. Soon they will probably have to move onto something else (and may not work for your organisation again) and the information you passed on is likely to be forgotten. In these situations nobody is working to generate software that matches your vision, because the people working at the coalface don’t have the chance to build up the required domain knowledge.

The answer: partnerships

So, how can you counter the two extremes of the cost of maintaining your own team versus external workers who don’t understand your business? The answer is to work in partnerships; where dedicated suppliers work with your organisation over a long period of time, communicating regularly about long-term goals and strategic plans. Striking the balance between requiring in-house resource and having a different supplier for each project means you’re saved the expense of hiring permanent staff, but can be confident that the team will develop the same care and attention to your domain as your internal staff would. Because now, when addressing an issue or performing maintenance they’re more likely to look for long-term, cross-system benefits, rather than simply focusing on how they can close a ticket and ship the final product as quickly as possible.

Domain knowledge at Box UK

The partnership approach is one we’ve embraced at Box UK. Our teams don’t dedicate 100% of their time to a single client, but instead we have developers who nurture long-term relationships with certain organisations (through close, but not constant, collaboration) and develop in-depth knowledge of a particular domain. This ensures they can not only build up but maintain a detailed knowledge of the client’s requirements and environment, and can be confident in understanding the business purpose of the software in hand. With this partnership approach we’re able to deliver a whole host of benefits, not least being able to see where a specified change may have an unexpected knock-on effect, helping to avoid potential problems and ultimately produce a better quality end-product.

Case studies

Take, for example, a financial client of ours who has a very complicated way of mapping their products – by user role, geographic location, user preference etc. Anybody could make changes to the system, but that doesn’t mean they necessarily understand the compliance reasons behind the complex model in place. As partners to the client, our Developers hold the appropriate domain knowledge, understand these requirements and are able to assess the impact of any new work and really do justice to the program.

I am also part of a team (made up of Analysts, Architects, Project Managers, Developers and Testers) that has been working on a commercial insurance application. At the start we knew little about the industry, but made our first task absorbing as much insurance domain knowledge as we could, particularly in the case of our Analysts who then passed it down to our Developers. It means that again industry- and location-specific compliance regulations are factored into all decisions, and everyone can see why each element has been included.

Through working with this client in a partnership model, I could now happily talk to an insurance professional about their industry, and so could everyone else on the team. This knowledge is valuable to us, and it greatly aids our relationship with the client as they don’t have to explain things in detail every time they embark on a new project (as they would have to do were they to engage a new supplier each time). It’s also enabled us to take on the role of ‘policemen’; validating technical decisions and identifying potential issues. Not only does this demonstrate to the client that we can manage the specific requirements and constraints of their industry, it also removes the need for them to be overly prescriptive, facilitating greater creativity and freedom on both sides.

Conclusion

When we work with clients we encourage them to think of us as another employee, and be confident about our level of knowledge about their domain. This is about more than just knowing your values and business goals (anyone can read a mission statement), but about being able to understand who you are and what you do enough to represent you effectively. Having people outside your organisation who are nevertheless embedded in your company culture helps ensure the delivery of the highest quality software for the best possible value, making it the pragmatic answer to the domain knowledge question.

Pete Withers-Jones

Head of Development

Pete Withers-Jones leads Box UK’s Development Practice, and has over 20 years of experience in software development, working across various industries and technologies.