Responsibility, Knowledge And Authority

These are the three aspects, if in improper proportion, can disrupt a working system, a real world system. They equally and aptly apply in the software world as well. Any software entity that we design – right from a macro to a class hierarchy should have the right mixture of all these three. That is why they can be used effectively to know before time if the design has holes. Of course we have the design principles to guide us, but I believe this new perspective can come in much earlier, even before software itself gets involved.

Responsibility

A typical functionality gets decomposed across various entities as we start going deeper. But how do we verify that the integrated output is equivalent to the functionality we desired? Looking at the decomposed functionalities as responsibilities of corresponding entities help us do that. If one entity fails in the responsibility, the rest of the system has to react appropriately to handle it. What is responsibility? Responsibility of an entity in a system, is more than just the functionality, it is to perform its tasks with the attached constraints, like time, speed, accuracy, etc.

Responsibility also highlights another aspect – dependency. In any process, responsibility of an entity can be dependent on others’ responsibilities. If the dependencies are not identified properly, it can lead to a corrupted system.

As an example, consider that the HR department’s responsibility to hire talent in a span of couple of months. If not performed, this can lead to a crisis in other departments which expect the hired talent to perform for them.

Knowledge

For any entity to honestly perform its responsibility, it has to have sufficient knowledge. A critical part of this knowledge is information. There two types of information – owned by the entity itself, and information that will be required from others. It is extremely important to identify the information that will be taken from others. If the entity decides to produce that information then it is an additional responsibility.

As an example, consider the following series of code, which involves the HR department.

hire()
    talent = cpp_on_unix
    time = two_months
    find_talent(talent)
    interview(talent, time)
    select()

hire(talent, time)
    find_talent(talent)
    interview(talent, time)
    select()

The change in the second function hire(talent, time) has shed away responsibility for knowing which talent to look for and what the time limit is. Someone else is supposed to provide that. Why was it necessary? Because it is someone else has the knowledge about it. It is quite possible that we apply this logic to other steps, like interview and further reduce the responsibility.

The aim is to identify whether the responsibility matches the knowledge it has. If not, then the design will cause corruption and/or inflexibility.

Authority

Another aspect that is required to perform the responsibility is authority. If there are problems or unexpected events, the entity should have enough authority to decide what to do. I know, this sounds very close to error/exception handling, but let us not go there yet. This more about dealing with deviation from one of the standard paths that were decided upon.

Taking the HR example again, if it cannot hire the talent, it has to take some action notify the other who are depending on it. It has to have authority to do what is required to handle the situation. Or consider the other scenario where lack of authority caused it to always go to someone else to decide on the future path. This will kill the efficiency.

Most of the designs that I have seen fail is because the responsibility, knowledge and authority do not match each other. This is true in the real world, and following this paradigm can help us make our design sturdier and flexible. Sure, we can easily map this to patterns in design and code, but I think it helps if this is considered right from the beginning, even to evaluate suitability of a software system.

The necessary thing to be able to follow this is to ask questions, which can probably find faults in the real world system itself, which can mean more work. But this can help you build a working model and develop it into a working design. This is something I have been personally practicing and have had benefits. This also helps in talking with the business people since this vocabulary is friendlier than the technical specifications, requirements and functionalities jargon. However, I do not have crystallized thoughts on this, rather I do not have a software process to enable this. Perhaps following on this series can help.