The organization, the business problem it solves and the system it builds to solve that problem.
“Leadership and learning are indispensable to each other”
— John F. Kennedy
In the previous post we talked about the Mission Statement, Company Values, Methodologies and processes for growing startups. Now we will look into the organization, the business problem it solves and the system it builds to solve that problem.
The Organization (Why do we organize?)
What makes humans capable of building great things? Think about
· The Pyramids
· The Great Wall,
· The Manhattan Project
· The Apollo Program
· The Internet
· The Human Genome Project
If you ask Avraham Poupko senior researcher at Cisco, the answer is
1) Being able to communicate and share a mental model.
2) Being able to build an organization.
“Once we are are organized enough, and once we are communicative enough and once we have a shared model, then We can talk about ‘We’. ‘We’ as an organization have a capability of learning, which is the modeling of information into useful, applicable knowledge.”
– Avraham Poupko
We obviously need to communicate, and we obviously must work together, there is however a limit to how many people can work together in one big pool. We divide in to smaller teams.
How should we organize those teams?
Poupko points to Conway’s law. Conway’s law says that the architecture of a solution will always reflect the paths of communication in an organization.
So the claim here is that the organization of people directly will influence the architecture of the system that we are building.
Another important thing Poupko refers to is the Cynefin model. The Cynefin model divides problems into 4 categories: simple, complicated, Complex and Chaotic.
For a simple problem a simple solution suffices. If the solution becomes more complex than the problem it solves, we say that we have added accidental complexity. We want to avoid that.
Poupko argues that since the solution is directly affected by the organization according to Conways law, a complex organization will inherently produce complex solutions.
How have this problem been solved before?
Think about the Apollo project. They didn’t build one big system. The Total system was divided into modules and different teams could focus on those modules. Having clear boundaries for the modules made cooperation between teams easier.
The question is now how was the Apollo modules identified? It may sound like a trick question. But quite naturally the modules were divided by the problems they tried to solve.
Not all parts of the assembled system (space rocket) lived equally long. Some parts were designed for bringing the space capsule to the moon, another one was responsible for bringing it back. Only the space capsule itself containing living persons was designed to make it all the way back to earth and being reused.
So the trick here was to align the problems we solve with the system we build and again align our organization with the sub systems that solves problems in a sub domain.
“Identify the sub domains in the problem space. build a modular system where each subsystem solves a problem in a clearly bounded sub domain. Organize teams aligned with the Subdomain and sub system”
Look here for an excellent presentation by Avraham Poupko
The problem.
“The heart of software is its ability to solve domain-related problems for its user.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software.
What do you feel when reading that quote? Is it correct? Is it trivial? What value or even wisdom does this quote possess?
I can tell you what I think! At first sight it seems quite obvious. The software should solve a problem for the user. If it didn’t there would be no need for the software. Next I look at the term ‘domain-related’. For me that means that the software doesn’t solve all the problems of the user. But it solves a specific problem related to a specific problem domain. Next I go back to the part saying “The heart of software…”. For me it means that solving a problem for the user in the problem domain is the most important aspect of the software. This leads to the next question? What part of the software is not as important? For me that is the technical parts. The technical parts are important, but they are not the heart of the software. This is how I interpret this quote.
Here is another Quote by Eric Evans
“- the most critical complexity of most software projects is understanding the business domain itself.”
Is this always true? No, for simple problems its probably not true. But for complex domains its an important point to keep in mind.
For complex domains it’s important that domain experts, software developers, product people and user interface designers work together in order to understand the problem and to build a solution that solves the problem for the user, with a user interface that the user can understand and like working with and at the same time is technical possible and doable with the given time and resources. This is also widely accepted by modern companies that recognize that you need to form so called cross functional teams.
We have argued that in order for an organization to work effectively we need to break down the business problem that the Saas Company wants to solve for their customers. This is easier said than done. Problems are not always well defined or split up in clear boundaries. If the problem domain is complicated and the software system providing a solution grows big, it becomes difficult to remember all the subtle details of how it actually works. Misunderstandings arise, and people has different ways of understanding and explaining things. They might even be mistaken or outdated, because how it used to work is no longer true. Systems evolve.
To prevent this from going out of control we need to manage the complexity of the system.
This is what is hinted at in Eric Evans seminal book “Domain Driven Design, tackling complexity in the heart of software”. It was published in 2003, but is astonishingly relevant today, 15 years after.
If you want a more precise definition of what Domain Driven Design is, please watch the first 10 minutes of this presentation by Eric Evans
Avraham Poupko argues that an organization needs a mental model of its problem domain, that can be shared between all members of the organization. This can however not be one big model, because such a model would be too big to comprehend. In an enterprise a problem domain would normally span multiple subdomains and one model would not be precise enough to express the details of the individual sub domains.
Evans introduces the concept of a bounded context.
A bounded context is the solution space to a specific subdomain in the enterprise.
What is a solution space in the SAAS world? Well that is the software system that serves the needs of its customers. So, the first important point is that a problem domain is broken down into more subdomains, and that each subdomain should have its corresponding solution expressed in a bounded context.
1 Subdomain -> 1 bounded context
But a Common problem in software development is the communication gap that exists between the technical people in an organization and the product and business people. The techies don’t always understand the intricate details of the problems that customers are facing. And the product and business people on the other hand doesn’t understand all the tech details that the techies are working with daily.
What the software does and how it works or should work must be explained in a common language that spans not only the development and product departments but the whole organization. Evans refers to this as the ubiquitous language.
The System
Big legacy systems often end up in what software developers refer to as a “big ball of mud”.
The management of complexity has failed. Such systems drag development speed down and causes frustration for everyone in the organization, performance starts to decline, bugs are produced faster than they are solved. And if you don’t have a suite of automated tests, you have no guarantee whether the system is actually working or not. Instead tremendous manual effort must be put into testing the system. And lastly angry customers are putting the customer support people under heavy pressure.
Its commonly accepted that such systems should be modularized. We previously mentioned the Apollo project as an example of a modular system. We also touched upon how we should divide the system into bounded contexts reflecting the problem domain.
Microservices is a popular term in these days and has brought new focus to the Domain Driven Design Community from where the ideas of Bounded Contexts, Sub Domains and Ubiquitous language were coined and turned into a pattern language. This quote by Andrew Clay Shafer illustrates the connection pretty well:
“The point of microservices is to unblock independent queues at work. Both in the system of services, and the system of people.”
-Andrew Clay Shafer
Systems can get so big that a single person cannot possibly understand all details of it. But when divided into smaller modules it becomes possible. When we communicate we assume a common mental model! When I Say ‘elephant’! I assume the person to whom I speak forms a mental picture of an elephant in his or her brain. To communicate effectively when developing software, the people cooperating needs a common mental model. That mental model must be rooted in the system or the two will drift apart.
“To communicate effectively, the code must be based on the same language used to write the requirements — the same language that the developers speak with each other and with domain experts.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software.
Often software becomes to cluttered with technical details instead of reflecting the business problem it tries to solve, when time goes by and new developers are taking over code from other developers the meaning of the code is often hard to grasp.
The code should not only solve the problem but also communicate the underlying model.
“It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
A new way of communicating effectively is to use the events taking place in a software system. Events are formulated as verbs in past tense, to reflect the unchangeable nature of a fact that has already happened. Examples could be.
“user logged in”.
“Employee signed contract”,
“Product item added to basket”,
“Worker assigned to shift”,
“Shift approved”.
Alberto Brandolini calls these kinds of events for “the new ubiquitous language”.
He has coined the relatively new practice of event storming as a technique to discover, learn and communicate how a system works or should work. It’s a modelling technique where domain experts and developers are put in the same room in front of a large modeling surface (paper on a wall). Here any one can put stickers on the modelling surface starting with one event happening in the system. From there the conversation is rolling and questions can be answered. And a common mental model can be reached for all members in the room.
Please look here and here if you want to know more about event storming.
Today software systems often store these events, just like a bank stores all the transactions on a bank account. Imagine if your home-banking system only displayed the balance of your account, but didn’t show all the transactions, you probably wouldn’t be satisfied with this. Today artificial intelligence, machine learning and Big Data are buzz words leaping around the use of data. Imagine if you store all events happening in your enterprise system. These events could be used as the base for statistical analysis, predictions of behavior, discovery of trends. Also they would satisfy a lot of auditing requirements, that modern IT systems need to support,even enforced by regulatory laws.
All these things could give your business a significant competitive advantage, and business people know that!
“Storing all of the events happening in a software system, to be used in big data analysis, AI and Machine learning, could give the business a competitive advantage”.
in the next post we will look at some popular concepts often mentioned by leaders in growing saas companies.
