đź’¸ Autonomous models and products
A fundamental principle I first heard about in high school, but didn't realize its power: divide and conquer! Why is this so important? When you don't know what it's about, it's about money. And that's exactly why we generally build our software — to make money.
Your model either enables quickly evaluating new ideas with proof of concepts, or it doesn't.
Your model either offers the possibility of emergent new products from existing or composed modules, or it doesn't.
Brutal, but true. There is nothing in between. Can a given module of your software work on its own and be useful? Can you create a Proof of Concept for testing a new product idea without breaking everything else? If the software doesn't have clear boundaries between its parts, the standard answer is: hmmm... not exactly. But where is the money? Looking at the following examples may help your business to earn more.
đźš— Module = Product #1: Uber
Such solutions are also used by the biggest players in the market. In the case of Uber, the core services were initially created as specific functionalities for drivers and passengers. When the company began expanding its product catalog to industries beyond transportation (such as Uber Eats), business capabilities were separated, which are now utilized by multiple products. These capabilities include: user accounts, route planning, payments, and matching passengers with drivers etc. Therefore, we have a level of products that we can compose of lower-level components—the capabilities provided by our system.
If Uber hadn't separated route planning and ride services from the actual transportation of people, it wouldn't have been able to easily introduce package delivery through its app. In this case, the app's architecture is, referring back to Heroes, a true goldmine. By composing capabilities (such as route planning and a fleet of cars), a new product could be created based on existing solutions without changing other parts of the system, like passenger transport.
You can think of it this way: if your business capability is transporting things with cars, you can leverage this potential for different products: a taxi-like service, food delivery, package delivery, or even moving services. While designing your autonomous modules, think about Software Architecture in the same way, to drive the development of the products in the direction of new business possibilities.
So it didn't surprise me when Uber once offered me the option to transport a package within a city instead of transporting myself. Imagine what would happen if the ride was strictly tied to the passenger? It would likely result in the same situation as our hero in the tavern: creating a "passenger ride without a passenger" model with unnecessary nulls.
You can read more about Uber's architecture in the article Introducing Domain-Oriented Microservice Architecture.
🎲 Module = Product #2: Heroes III Board Game
The Heroes III board game offers two ways to conduct battles:
- A simpler one, using cards, included in the basic game.
- A more complex version, played on a special board with 3D creature figures, more faithfully replicating the mechanics of the computer game. Available as an extension to buy.
Thanks to proper modularization and separating the battle mechanics from the rest of the game parts, as well as flexible rules (domain processes in the game), it became possible to offer additional products to new and existing customers. Heroes V also introduced combats between heroes, not only in scenario mode. This was possible because the battle mechanics were modularized and could be easily used independent of other processes. Similar practices can be applied not only in computer games. Do you see something like that in your domain?
👨‍💻 Developer == Business Partner?
As a software engineer, you can be more than just a coder, who may soon be replaced by AI, but a real business partner, opening up new possibilities. A software architect is paid to ensure that introducing new functionalities and potential requirements' changes aren't too expensive.
Often in product teams, decisions are made: "instead of endless discussions, let's do a Proof of Concept." Yet, no one do that, because the system's state does not allow it. The problem isn't the mythical "technical debt" (Technical debt isn't technical - be sure to watch this presentation!) understood as using outdated technology, but rather the tangled model, without proper boundaries.
Dividing and modularizing the system isn't just a programmer's inadequate desire: it must be paired with a deep understanding of the business domain. When you model, keep the primary goal in mind: autonomous modules. How you implement them and which technologies are used is not so important. So, how to divide to conquer?
We'll talk about that in future articles.
In the next episodes:
- Planning out the software, using EventStorming and Event Modeling
- Turning plans into code
- Making sure it's good quality before writing any code
If you want to read the next parts, sign up for my mailing list HERE.
Top comments (0)