"Organization-Driven Design"

What metaphor am I talking about?

Recently, I released my mind from rational leash which led to exploring how we could think of software design - I am talking about Conversation-Driven Design blog post.

The conclusion was as follows: we could utilize metaphor (or model) of people talking to each other in order to design interactions, responsibilty assignment and do the verification if it all makes sense. I finalized that blogpost with:

I think it might get even more interesting when we would "summon" a group of such imaginary people and call them a "company" - how would they interact to achieve bigger goal like some of their domain capabilities?

When using a proper mental model (as in this example - conversation as a model for software design), our language changes, we are capable of utilizing different concepts and terms.

Let's explore the metaphor!

Objects are like humans?

Imagine we have two objects: A and B.

A conversation

For the needs of this blog post, we already assumed that we can talk to objects (weird, isn't it?) and objects can talk to each other, almost as if they have a conversation. To make them looking a bit more humane-like, let's change their outfit.

A conversation

Much better. There is some work that A needs to get done, but only B knows how to achieve it. So we can say that B is a kind of expert on the topic that A wants to get the work done.

Let's add additional constraint - because B is the expert, he isn't that much interested in handling some requests from unknown parties. He just wants to get his job done where expertise is required. So the constraint is that A cannot speak to B.

How we can prevent from those guys talking to each other?

Is something missing?

Of course, our guys are floating in some ungrounded space and we can't say where they are - in the shopping mall, in the university or maybe on the beach?

Let's imagine that guy A comes to a building where B is working. Now, how we can prevent person A talking to person b, knowing that they are within a building?

How to prevent them speaking?

Ok, we put them in the context of the workplace so might it be that there's a wall between them?

A wall.

Fine. There is a wall. A physical obstacle that prevents them from talking. A single wall, within a workplace might look weird so let's think - if we take a couple of walls, what concept is created?

Rooms

The first thing that comes to my mind is a room. An empty space that is organized by humans, related to their needs. It is a physical boundary that might stop unwanted parties to enter, e.g. doors preventing from entering teenager's room.

Rooms

But don't forget - dude A has a work to do and the only person who knows how to do so is expert B. Let's assign them some additional roles.

Imagine that guy A is a customer that enters to the workplace and requests a service.

On the other hand, B is an expert that knows how to do required steps of the skill-requiring work. And he doesn't care about handling the requests.

Additionally, B's "workroom" is full of equipment and he won't like to have other people there that could break some appliances.

What to do now?

Servicing a customer

An open position!

Probably B affords hiring a colleague that will handle "the boring" stuff: handling client requests and providing a respective details what they would like to do. Please warmly welcome C - a consultant.

A consultant handling the request

As a reminder: arrows show the "conversation" direction.

That's funny, the language we are using in our small example, while exploring the metaphor, looks quite similar to how we are talking about our software components?! (maybe not the consultant 😉)

If you follow me (I hope so, because I don't have any eye-tracking components installed - yet!), we build up an interesting realm here. Our client can't bypass the consultant to reach the domain expert. The expert is safely doing his precious work in his room.

How would we call both the consultant and the expert?

A group?

A team?

A gang?

A guild?

Once, I've heard that in order to work together to achieve a bigger goal, people need to organize themselves. They need to form an organizing unit.

The birth of organization

Could we say that our two actors, in our tiny theater, form an organization? I know, teeny-tiny one, but still.

Do they have a goal to achieve? Yes. The expert want to do his work in the best way, but not being bothered about talking to strangers so he needs to pay a wage to a consultant. Maintaining the equipment, skilling himself means costs. They both need to make profits.

Do they need to work together? Based on the previous answer it's quite clear - it's inevitable for them to collaborate if they want to make profit.

I think we advanced our metaphor quite interestingly - from a conversation between us, humans, and software components, e.g. objects, to an organization, in which people (or objects) are collaborating, fulfilling their responsibilities.

Just by having a simple example of two objects: business expert B and customer facing consultant C, we are able to "grow" our questions too!

• How consultant is passing the details of work - by going to the "back-office" or by leaving a message for B expert?
• What if customers want to leave a message, not come to the office - will the consultant C handle that or there should be another role?
• What if expert B is overloaded and can't work due to excessive amount of workload?

Our bread and butter activites, as software developers, are similar to: drowning in configuring ORMs, optimizing SQL queries or thinking how to add another boolean flag to our wicked object graph, that both represents data model and domain (sic!) model.

Where is the time for thinking about the design in such a (silly?) way?!

What if we scale our imaginary organization?

Ok, two people in organization isn't that convicing. Who the hell hires a consultant when he or she can be a god object, excuse me, the most responsible person in "one-man army"-like company?

Imagine the following: there is an organization (called "Imaginary") that provides two kind of services:

1. a service for urban planning
2. a service for organizing and managing workers, to execute urban changes

There are three groups working in this organization:

• "teal" group - responsible for handing services for urban planning (1)
• "gray" group - responsible for handling services for workers management (2)
• "dark orange/light brown" (or whatever color you see) group - responsible for archiving all the respective things about the work done by two other groups

An imaginary organization's office

There's a catch: someone decided that the rooms, in the office, will be organized by the role/function employees were assigned to. Of course this office is weird, because it doesn't have any doors (or something for walking between rooms!). Let's fix it.

Office rooms. Arrows denote "who talks to whom"

So we can denote four different rooms, related to a given type of role:

• room P - customer facing experts
• room A - process experts applying a structure to business experts recommendations
• room B - business experts with unique skills
• room D - experts on archiving

As a reminder, arrows show who is talking to whom.

People love innovations, so this sounded like a great innovation - distributing people across the rooms based on their knowledge, skills and profession. It might be some ingenious idea that experts in the room A will exchange the thoughts and it will bring a breakthrough? You never know.

"Do I need to talk with all of them?"

Still, the company has to provide their services.

The business needs to move forward, thus experts on urban planning ("teal" group), working in the room A, should try to speak only to their peers. They should focus on their main service. The same applies for other groups in the other rooms.

But at some point, something happened.

In the room A, urban planning experts ("teal" group) needed to quickly "fix" some mistake in the plan, and they asked worker management experts ("gray" group) to change scheduled workers' scope of job.

Soon, it turned out that more "requests for a favor" started forming the habit of this little organization. Such "requests for a favor" are marked as arrows. I think you know such scenario: "there is a person, who knows a person, that knows a guy, who can help".

It sounds almost like a "black market" (I think I learned this metaphor in "Software Architect Elevator" book. If I am wrong please correct me!)

Soon, experts across the entire office were exchanging information about details of their work. Poor archiver helplessly needs to track all of the work and he is really scared of any audit.

"Black market"-like collaboration

At some point, no employee in this little office is able to do the actual work, because he/she needs to know the details of another employee's work.

Owners are angry, because the business isn't performing well, the brilliant idea of organizing the office in the presented way isn't performing well too.

What advice could we give to the owners?

Build a friggin' wall

How could we prevent experts from talking to each other so that they are laser-focused on their work?

I think we already explored the metaphor enough to answer such question: use a physical boundary - a wall.

Let's imagine that our recommendation was actually implemented and this is how the office looks like now:

A wall and dedicated archives

Additionally, we gave another advice (extra charged, the invoice will be sent by email) - dedicate some of the archives for the urban planning experts' ("teal" group) work, the rest of available archives are destined for the work of worker management experts ("gray" group). We can think of such approach as physical boundary, but withtin a room full of archives.

This makes archiver happy too, because he has everything in place so that in case of audit, he can easily pull information and create a report.

Are we done?

What about rooms P and D? Should we separate them too?

Turns out that the organization made the new policy - if urban planning experts ("teal" group) want to ask some question or request something from worker management experts ("gray" group), they need to go to the customer facing experts of worker management experts ("gray" group) to achieve so. And vice versa.

And about archiver - he is only a single guy in the room so it does not make sense to build artificial walls. He manages to keep all archives in this single room.

"Please, stop drilling this metaphor!"

I hear your voice (do I?) - "where are you going with this metaphor?".

Let's reveal the hidden agenda I built through the entire tale.

It is not a coincidence that rooms were annotated with specific letters. Each room is related to a particular layer:

• room P = Presentation layer
• room A = Application layer
• room B - Business layer
• room D - Data layer

Our little organization was a model of a N-tier architecture (where N is 4 of course).

You can think of each employee as a class, with a particular role, based on the room (layer) assigned:

• experts in P room might be labelled as Controllers
• experts in A room might be labelled as Services
• experts in B room might be named Models or Services (something else? Please share your ideas!)
• archiver in D room might be called Repository

A model of an organization?

"Black market"-like collaboration is a typical way of how "systems" evolve when there are no clear and dedicated physical boundaries. Sooner or later every "room" and every "expert" is entangled.

In case of any change - a change of the structure of rooms, a new employee being onboarded - there is enormous effort, planning and unnecessary acitivities required.

"Just" by providing a proper boundary, everything can evolve in more organic, self-deteriorating-free fashion.

"I have an idea!"

If you think more about the model we used for how we could think about our software components and systems, it has really interesting properties. Again, we can ask "different" questions - they are different, because they operate on the metaphor's plane.

Here are some examplary questions I came up with:

• What if owners of "Imaginary" company decided to scale up the business by creating offices in other cities? Is it possible?
• What if we want to hire worker management experts, which requires more office space, but keep urban planning experts at the same size?
• What if urban planning experts have highly specific format of archives, whereas worker management experts use documents for archiving?
• What does it mean that offices located in different cities need to communicate?

Isn't it interesting?

Do you need this model?

A model is usable within a particular context and it was created for a specific purpose - to provide a solution for some problem. The same applies to the model (or metaphor, I am using them interchangeably) we explored in this blog post.

I think that Organization-Driven Design, as a model for thinking about the design, might be very empowering. We are trained by observing the surrounding reality how companies, employees and people operate, organize and collaborate.

Should you use it every time you design, e.g. a tiny class? No, probably not. It might be a waste of time.

Should you use it when you build your next CRUD-like API? Well, this might be pointless.

It's not a tangible practice as TDD or building Value Objects, or Aggregates.

It can just accelerate the thinking about the design, because we might leverage what we see in our daily basis.

With this metaphor, you can explore various forms of collaborations, responsibility assignment and how people, mhm, objects should converse with each other.

Objects? Try to apply this model on the service level. I believe you can find some fascinating insights.

A bonus: you can try to use such stories to explain to "business people" why you have problems in production ("my expert on archiving is giving information to the wrong people!").

Have fun with modeling!