Domain Knowledge Emphasis
Below is an adaptation of an email I wrote to my team when we started developing a new project in a domain we had not worked with before. One of the key points of the email was that not only business analysts, but developers also needed to possess a fair amount of domain knowledge, besides their technical skills. What are your take on the need of having developers mastering domain knowledge? Do you think it is critical for the success of a project?
…
One key point I want to emphasize in this project is that I strongly expect each of you to understand deeply about the business domain. To be specific, we are playing the role of consultants who are supposed to understand the real needs of the clients in order to engineer solutions which effectively address those problems. Since problems are not always obvious and clients do not always know what they want and sometimes even get confused between the problem and the solutions, we need to help them in the discovery process, instead of passively letting them to tell us what they want. Below are some problems that I have observed so far with other teams I worked with.
I have worked with business analysts whose requirement gathering techniques are chiefly involved with asking the clients what they want (GUI, flows, and business logic) and translating that understanding into something supposedly comprehensible by the developers. Doing so, they miss the opportunity of understanding deeply about the essentially root causes of needs (i.e. the Why’s), in order to propose something more user-friendly and cost-effective to the clients. In fact, discovering the What’s is the easy thing to do, while the discovering of the Why’s and proposing better specifications require a combination of good requirement gathering techniques and domain expertise. And while I have seen many BAs who possess very good requirement gathering skills, it is very unfortunate that they just cannot apply those skills effectively because they do not possess enough of the domain knowledge in order to communicate effectively with the clients using their own business languages. Consequently, instead of being proactive in discovering the requirements, they become more and more passive, instead of proposing better ways of doing things, they simply document down whatever the clients tell them, no matter how bad the specifications are.
In other projects, I know developers who think that only business analysts should understand deeply about the domain knowledge and developers just need to know the technical aspects of the project. That is not entirely true. Simply put, without really understand about the problem domain to be addressed, how are engineers supposed to be able to build an optimal solution? To be fair, with the help of other teams and the clients, developers can still implement a system which barely meets the requirements – but I can almost always tell right away that it is far more costly to build system that way and the quality of the system would be compromised significantly.
As a matter of fact, applications in which developers do not possess good domain knowledge often have a very bad architecture. Instead of having a comprehensive object model with well-defined business objects which are structured in a way that can not only fulfill the requirements but also easily be evolved when the business requirements change, they have a flatten object model which mostly consists of data-only objects containing few relationships and exposing little or no behaviors and have the actual business logic enforced (and overwhelmingly overlapped) arbitrarily in the UI layer, service layer, or even in the database. With the latter architecture, the larger the system is, the more painful it is to modify old features or enhance it with new features since it lacks of a rich object model to glue every part of the system together in a cohesive manner to facilitate changeability and reusability. In order to create a good object model, we need to understand deeply about the abstract business entities (data and behaviors) of the domain as well as their relationships. The problem is that this model is not obvious immediately by simply looking at the requirements and we can only discover and refine it via continuous domain exploring sessions conducted with the clients and the BAs during the whole software development life cycle.
But you say, “As a large software outsourcing organization, we need to work in multiple domains and there is insufficient time to learn to be domain experts,” and my advices are:
1) For BAs: you must be the experts in one or more domains and there is no way to escape from it. Pick the domain you like, and learn everything about it (and at the same time, do not forget to sharpen your technical ability in requirement gathering). While currently serving many projects in different domains, we are going to specialize more and more in order to be a leading offshoring software service provider for some vertical segments. Consequently, if you are experts in any of these segments, you will be indispensable resources of our organization.
2) For other teams (developers, DBAs, QCs): you do not need to spend time learning everything about a specific domain, since I still expect you to continuously focus on the skills required for the solution space (programming languages, patterns, frameworks, technologies etc.). However, you need to gain enough of the domain knowledge in order to be able to translate the business requirements into a well-designed system as well as ask smart questions and provide good suggestions to the BAs and the clients.
By now, I hope I have been clear on the expectation about domain knowledge in this project. Let’s roll our sleeves, learning about the domain, and making this project a success!
…
I don’t see how a software development project can possibly delight a customer if you don’t understand the problem domain. As consultants we are in a position to provide very valuable insight and perspective. You cannot simply be automatons responding to specifications. Specs are never complete, comprehensive, and fully expressed. The details must be teased out, and the more you understand the client’s business, the more effective you’ll be at this.
This is all the more important for remote / distributed teams.
I have clients as far as 2200 miles from my location and I have never physically visited any of the client sites that I am currently doing work for, so it is certainly possible to become knowledgeable even without the face-to-face contact. But it requires that you are interested, and ask intelligent, focused questions.
Thanks for your comments, Bob! I totally agree with your points.
That’s interesting! Can you share your experience in gathering requirement in that project? I’m managing an offshoring project, and I have yet to find any way to have remote business analysts communicate effectively with the clients without bringing the analysts to the client’s site.
In all cases I am dealing with very small firms and directly with the owner. For one of them, 100% of their business is their online B2C web presence, so there is little or nothing to be gained by seeing their three-person office that I can’t get with phone conferences. Another example was a pharmaceutical wholesaler, another three-person company operating out of a small warehouse. Not only were the business rules very clear cut, but the owner had developed his own software and I was simply rewriting and extending it.
I can certainly see situations where going on site would be useful, particularly where there are lots of stakeholders or other actors who need to be interviewed, but I have been blessed with simpler circumstances.
@Bob: I really appreciate your responses
During most of my career I’ve been performing both roles: BA and developer. I have found that it is indispensable for the developer to have a fair amount of domain knowledge for the following reasons:
a) Architecture: it was best articulated in your post; projects that don’t hold a constant preoccupation with domain knowledge/understanding end up working with a partial and distorted image of the domain and its inner operations, and the most concrete manifestation of this ill understanding is the architecture of the system.
b) Empathy: to a developer, it simply isn’t the same to work thinking about an abstract sort of entity called “Invoice” or “Accountant” or “Nurse”; the more energy the developer invests in understanding the domain, the more he’ll be able to see the reasons the process has its current form, the dimensions where growth is plausible and the precise advantages the new system represents to the overall functioning. Keeping the developer oblivious to all of these amounts to having a system based on generic/abstract ideas, not specific/concrete real problems.
c) Detachment: this is more of a corollary for b). To the extent the developer has a fair amount of domain knowledge will he take the project as a personal matter. The less he knows about the customer, the easiest it will be for him to remain almost indifferent to their problems. BAs, no matter how good they are, can’t possibly convey the experience of being with the customer, seeing how he operates, being confronted with their everyday problems. If the developer unequivocally perceives the mismatch, the inefficiency or the redundancy in the operation, he will provide a much richer and comprehensive solution.
I understand that developers can’t go too often -if at all- to the customer’s site; still, I believe a healthy involvement between the customer and the development team result in much better suited and enduring solutions.
@Jehu:
Thanks for your comments, you made really great points on this topics!
One of a headache of me, as a manager of an outsourcing company, is that we need developers to work on multiple domains and technologies. That is different from many development companies in which developers usually stick with one or two specific domains and a little more technologies. And while it’s ideal to have developers understand as much as possible about the domain knowledge, in our case, we need to have a very limited threshold – both we and our developers do not want to be handcuffed into any particular domain or technology, otherwise the developers will fall back and are not capable of rolling into other projects in different domains and using different technologies.
And that’s not to mention about something you already observed: it’s hard to have the developers and clients to work on the same site all the time. And it’s even harder in the outsourcing case.
Regardless, outsourcing organizations like us need to figure out a compromise. Maybe we should demand better cooperation from the customers about knowledge transfer, have better training system to retain domain knowledge across projects, limit our vertical markets to be more specific about certain domains, and even reduce this year’s bottom line to hire many domain experts to work for us
…
Yours is quite a different type of company from the ones where I’ve worked but, as you mentioned in your last paragraph, some sort of middle ground ought to be found because this issue exerts a direct and determinant influence on the overall quality of the product, be it along the dimension of sound and coherent architecture or clear and concise documentation, or even empathic training and overall team’s understanding of the customer.
It’s a bit comforting to know that, at least, you have a working awareness of this matter; my experience has proven this isn’t a priority, or even a passing thought/concern, in a sadly considerable amount of software leaders/managers/architects in our industry.
@Buu, it seems that you manage the developers in a services-based compnay. Even if substantial efforts are made to gather domain knowledge, the client would always know more about their business than we do. So, you are right that a healthy compromise is the way to go.
You can see my post, What is the best way to get Knowledge Transfer at http://tinyurl.com
/knowledgetransfer
It relates to the knowledge transfer for software testing professionals but the ideas may be used by others too. Let me know what you think.