Building a city and developing software are more alike than you might expect. How can lessons from the former ensure success of the latter? Read on to find out.
Imagine a city from a bird’s-eye view – you see various buildings: huge skyscrapers, blocks of flats, or single-family houses. Parts of the city differ from each other; some are more technologically developed while others are more traditional. Complicated buildings in the center are created by experienced architects, while the houses in the suburbs are often designed by less advanced constructors. However, all elements have a role to play in order for the whole city to function well.
Such a city is like a software development project, with the buildings representing grouped business processes, which we can call business modules. Creating a prosperous city is a big challenge and the same is true for a software development project. Both in a city and business some parts generate more profit than others. For both a city and a project created from scratch (so-called “greenfield”), we have greater freedom of choice when designing the architecture and choosing the tools we will use (the technology for an IT project or heavy equipment in the case of construction) than if our work is aimed at extending or rebuilding the existing city or system, and we must consider the existing constraints. In both cases some of the biggest challenges are to set boundaries, adjust the budget and choose developers.
All these concepts and problems of the city can be translated into an IT project. In the following subsections, we will try to present specific tips and techniques that will lead to the successful construction of both a city and IT project.
You’ll find four fascinating in-depth articles similar to this one in the “5 Steps to a successful software development project” ebook.
Business value first
Before diving deep into specific techniques that help projects smoothly advance, let’s take one step back and focus on the foundational element that should be the basis of all the subsequent processes: the business value and its maximization on all stages of work.
Both IT projects and cities have to bring value to their creators. What’s important to remember is that the bigger the project, the more elements to be created. Thus, work should be planned in a way that delivers benefits as soon as possible and enables gathering feedback before development is finished, to be sure that it meets end users’ demands. So, while I won’t even try to guess the idea behind your projects, you can still follow some universal rules and practices to make the most out of this process.
Large cities usually have highly developed areas near their centers, where their inhabitants generate economic activity, as well as calmer outskirts that play an important role in a city’s ecosystem, but do not directly contribute to its profits. When it comes to software, we can distinguish such variety as well – each of the modules (you can learn how to determine these in a latter subsection) plays a role in the whole system, but some of them affect the business value more than others.
The impact on the whole system, and potential for maximizing value, is what determines the order in which the modules should be created at all stages of the work. Clearly, when building a city and IT project one has to start with the infrastructure necessary for development. But before starting on the infrastructure, it is necessary to plan the stages of work so that value can be maximized.
So how can we translate “maximizing value at all stages” into real actions? Imagine a housing estate where, apart from a block of flats, a park with an entertainment area for residents is planned. In the beginning, the developer will focus on building the residential area that will allow him to earn money Business value first Before diving deep into specific techniques that help projects smoothly advance, let’s take one step back and focus on the foundational element that should be the basis of all the subsequent processes: the business value and its maximization on all stages of work. 7 from selling the flats and enable people to move in. Next, the developer will create the park. This should start with planting trees, paving paths, and setting up benches while leaving the construction of the attractions to the very end. Why? The semi-finished product may be enjoyed by the inhabitants while still being „under construction”, so this sequence of work allows the developer to deliver value to residents even before all the construction is done.
And what about a software development project? There is more flexibility, due to the nature of work, but rather than theorize, let’s look at an example of a system built for a delivery company with a complex model of courier availability. This availability will be affected by many factors – location, the technical condition of the cars, the number of couriers, etc. thus making it time-consuming to build, but at the same time essential for end-users. Therefore, we should implement the associated modules first, while, for example, the registration, email notifications, or even the possibility of entering couriers into the database can be done at a later stage. Why? These functionalities can be replaced by inserting them directly into the database, or we can import the data from an excel file because, from the point of view of end-users, it is not critical. What about registration and notifications? At the start, we can afford to make some compromises, and instead of building a tailored module, we can use available services which, despite not being a perfect fit, will allow us to use our system much faster and thus „buy us time” to prepare a custom module. For example, setting integration with Google Authorization, instead of building a custom registration system, will shorten the time-to-market and allow the app to make money while we develop it further.
Read also: Software development models
This approach has a lot of advantages, especially in a project’s initial phases. Decreasing the pressure associated with the deadline and focusing on the most important modules, rather than working on all of them, allows us to fine-tune the functionalities and prepare comprehensive automatic tests, which ensure the most important modules operate correctly.
But what’s most important is creating the possibility for the business to present a demo version to users and gather extremely valuable feedback to develop the project further and/or introduce adjustments. As that’s an important part of Agile software development, we can’t omit it here. 8 Recent years have shown that planning in a waterfall manner is not as effective as an iterative and incremental Agile approach. To illustrate this, we can use the example of a housing estate again (city-building can be Agile too, even if the course of iterations is clearly longer – think about how the place you’ve lived in has changed in the last 20 years). Not precisely naming the park attraction was not an accident – depending on the inhabitants’ needs this could be a fountain, sports field, outdoor gym, or a playground and there’s no better way of establishing their needs than by simply asking those buying flats what they need.
Additionally, thanks to the modular architecture, when the application goes into production and begins to make money, or receive additional funding, we can not only add more functionalities, but also change the modules in which we made compromises for tailored, custom versions because the coupling between the modules is minimal.
The person responsible for planning the work in a way that allows the team to provide the greatest possible business value at a particular time is the Product Owner (PO). Similar to a construction manager, POs are a source of business knowledge for the team because they know the requirements and look at the product from a business perspective, while still understanding the technical side of the project. POs create a link between developers and a business and are responsible for preparing the plan at the beginning of development, managing its ongoing evolution, establishing priorities during the whole project lifecycle and introducing all essential modifications whenever necessary, assuming it is done in an Agile manner.
But even the best POs, shouldn’t try to handle everything on their own. Effective planning and prioritization provide the team with guidance, facilitate understanding and ensure development that generates the biggest value; it should include all participants since a collective understanding and combination of different points of view are the best construction site strategies. This allows us to smoothly transfer to the practical part of this article, where I describe how to effectively prepare for launching a software development project.
Since I’ve already mentioned modules few times, let’s start with them. At the beginning of building, whether a city or an IT project, we should focus on the individual elements necessary for its proper functioning.
In the case of a city, the elements could be a variety of buildings that occupy a specific place, have specific sets of features, and, importantly, are separated from the rest – like a shopping mall, apartment building, or town hall. In an IT project, such a structure is a „module” – by definition, it’s a group of functionalities that realize business processes within one context, separated from the rest. Designation and subsequent construction of modules is the responsibility of developers, but this can’t be done without the knowledge of the business domain and continuous, close cooperation with business representatives throughout the project.
Many battle-tested methods allow effective module designation and management (these are described in later subsections), but to maximize their potential all modules must match a key requirement – they must be autonomous. This means that decisions made within one module, and the business rules contained therein, should not affect other modules. Let’s illustrate it with a city building metaphor once again – autonomy in this case means that changes within a particular building shouldn’t disturb the rest of the city. That is why after the designation of modules, we can verify their autonomy by examining the number of connections between them, as shown in the diagrams below.
The product module presented in the middle is not autonomous because there are a lot of dependencies between it and the other modules. In such a situation, a change in product characteristics may, for example, impact the order module, and that’s exactly the opposite of what we want to achieve. Therefore, we should change the boundaries of the modules.
In this example, it is enough to divide the „product” module and merge its relevant parts with the other modules.
Of course, a situation in which the module will be completely independent is impossible because it would mean it doesn’t communicate with the others at all.
Therefore, this is not our goal either – we should focus on reducing the dependencies to the necessary minimum that allows a system to fulfill its purpose while making maintenance easy. Modules prepared in such a manner will usually communicate through a few events, as in the picture below.
A system outlined according to these principles can be called „modular” and we should aim for this when creating a project. Modularity not only makes developers’ work easier and more efficient, but also brings great value to a business. Just as companies must react to market changes (the faster, the better), so too IT systems (often the pillars on which a business is created) must be built in a way that allows them to be adapted to shifting environmental conditions. Having a sufficient degree of modularity ensures that adjusting a solution to current needs is not only possible, but also achievable without major obstacles. This allows us, for example, to remove a part of a system or extend it with minimal interference with other elements, significantly reducing the risk of failure and costs of implementing new functionalities. How to translate it into a city building? Imagine the above-mentioned shopping mall. It’s connected with other buildings at a level that enables necessary communication (in this case roads, sidewalks), while still being an independent construction. If it would need to be remodeled to serve a new purpose or simply be modernized, this would be possible without affecting (or affecting to a minimal extent) the rest of the city and its functioning.
Due to modularization, it is also easier to organize the work of individual developers because each of them can work on their own module. What’s more, it’s much easier for people joining a project to understand a single, independent module.
A good practice is for developers and business departments to set the boundaries of the modules at the very beginning of a project, which will save many hours of work at later stages and thus reduce development costs. How? By using techniques such as Event Storming and Ubiquitous Language.
The first method that can be used to boost the chances of success is Ubiquitous Language.
However, before defining this term, it is worth identifying the people involved in an IT project. On the one hand, there are non-technical business representatives, on the other hand, developers, proficient in technical issues, but often not so familiar with the business domain. This sometimes leads to a lack of understanding and creates complications that could be easily avoided. The remedy for this problem is Ubiquitous Language – a unified, specific language that supports communication between software developers and domain experts. Let’s illustrate it with an example from the construction site – if we were to refer to the color of the paint used with a broad term such as violet, each painter could choose a shade which, although it would fit this term, would be unlikely to match the architect’s vision.
Therefore, according to Ubiquitous Language rules, the color should be precisely defined – e.g., by a number or the specific name of the paint to be used. Over the years, more and more elements of the construction process were unified, thus making mutual understanding easy and the use of Ubiquitous Language natural in this environment. At the same time, the flexibility of software development projects increases the possibility of potential misunderstandings between people involved and therefore this language should be used in all documents, tasks, conversations, meetings, post-its, boards – literally everywhere. In addition to increasing understanding between all stakeholders, it is also important to notice the decrease in communication ambiguity. This allows us to create a system in which every party understands all the principles of its operation. One of the best practices is to create a dictionary of terms regularly used in a given industry/field at the beginning of a project so that developers can refer to it at any time. Such material also helps speed up the process of introducing new people to a project in later stages, as they will understand the business and code that is already written using domain-specific terms.
It is also crucial to stick to the established terms throughout the project lifecycle because redefining something and changing the word that defines a given element will entail renaming files and code associated with that element throughout the whole system and may lead to avoidable misunderstandings. Ubiquitous Language should be as varied and precise as possible. The choice of words is critical because if we use terms that are too general or ambiguous, developers can create an invalid model of the business process which is very expensive to change as it often requires modifying the project structure and automatic tests. An example of such a word is „user” which, depending on the context, has a different meaning and in each case should be modeled as a separate entity.
As you can see in the graph below, the Delivery Department will name the recipient “Receiver” and will only be interested in the address, while the Payment Department will refer to the person as „Payer” and consider the balance and account number and the Authorization Department will use the term „Subject”. Detection of ambiguity and clarification is a difficult art, but it saves a lot of time on corrections and, as a result, creates a system tailored to business needs. Module boundaries can be set using vocabulary if, in the context of a business process, keywords like “billing”, “invoice” or “item” are unambiguous. In such a scenario all entities defined with the same term must be created within a single module, but when the term used to describe a particular thing changes, we should set boundaries and think about a new module. Changing a term is easily noticeable when using Ubiquitous Language during an Event Storming session at the Big Picture level.
Just as when building a city and starting work by marking the borders of individual districts, likewise in the IT world, before starting work, you have to set the boundaries of the modules.
We already know what modules are and how to make communication unambiguous, but how to design modules? To refer to our metaphor, developers (builders) must know what modules (buildings) will be in the system (city) to correctly determine the boundaries. A proven way to share your vision with developers is to apply Event Storming. This technique has many levels and can be used at different stages, but for the purposes of this text we will focus on the most general, which also is the most important for a business, called „The Big Picture”. First described in 2013 by Alberto Brandolini, this technique has been increasingly gaining in popularity.
Just as various elements of our life can be described as a sequence of events, so too can IT systems – after all these are digital models of real business processes. This is what Event Storming helps us with – translating the operations of our system into a sequence of actions that happen in a specific order.
To clarify the goal of this process, let’s go back to the construction site for a moment. As the goal of Event Storming is to achieve an in-depth understanding of a process (consisting of so-called “events” that should happen within the system) it can’t be directly translated into construction, but the general purpose, which is sharing an idea among the team and verifying assumptions, is more than valid. In this case, Event Storming may be, for example, an opportunity for the stakeholders to describe to the architect what functions the buildings are to perform, consult with the builders about what is possible and work out a preliminary outline based on which a detailed plan will later be prepared. In this case, it will also be important to start with the general matters (in case of one building that might be defining its main function, i.e. office) and later moving to more specific elements (like determining the communication routes and traffic volume on them, including enough corridors or verifying if the necessary number of emergency exits is included in the project).
Knowing the main objectives of Event Storming, let’s focus on an IT project again. To effectively use this technique, it should be done according to a few basic rules. First and foremost – participants in the session. All project stakeholders should be involved in Event Storming – PO, PM, Developers, Administrators and UX/UI designers. This is particularly important during the first few sessions, after which the number of participants can be reduced. Meetings usually take place in conference rooms, but it is important to prepare boards and more than enough post-its, the use of which we will describe below since there’s nothing worse than running out of cards in the middle of a brainstorming session. Additionally, it is worthwhile for the participants of the session to remain standing, which is a proven method of increasing concentration.
The session itself consists of sticking post-its describing events in the order corresponding to the process on the board (assuming it represents a horizontal timeline). The cards can be stuck by each participant and apart from outlining specific events, these can contain questions, references to discussions, the resulting information, or even uncertainties that need to be solved at later stages. That is why it is so important that everyone involved in the project takes part in Event Storming. Different people will look at the process from different perspectives and thus take other aspects into account. Let’s illustrate it with an example. A business representative stuck a post-it describing an element of the business process, the development team nodded and declared they can deliver it, but then a member of the IT department stopped further work to ask about the required network infrastructure. It turned out that the module couldn’t be implemented with the current infrastructure, requiring either a change to the infrastructure or this module, and the team had a chance to plan the best scenario.
Event Storming also optimizes the process itself. For example, it might turn out that an employee who rewrites data from two spreadsheets for eight hours a day may not be needed because developers can automate this work in no more than a week. As you can see, a few hours of Event Storming session is a great way to save a lot of resources. Moving the cards on the board does not generate additional costs compared to the problems that would have arises from obstacles found during work or processes which could have been easily upgraded.
Event Storming is also an opportunity to build relationships between business and development teams – during the session people have a chance to get to know each other, observe how the other side works and bridge the gap between departments. This enables more fluent cooperation at a later stage of work and eliminates some of the potential communication problems that may hinder progress and impact the overall quality of the software. During the session, the previously described Ubiquitous Language is also created and used, which, as we mentioned, is a crucial element of the professional software development process.
After shaping a part of the system using Event Storming, we have a bird’s eye view of the business processes taking place in it. At this stage, we can handle the determination of the modules, using the Ubiquitous Language developed during the session. Looking at the business processes, the team should pay attention to the links between them and based on these, decide if the processes are so closely related that they must be included in the same module, or whether dependencies are low, and these can be separated into two modules that communicate by an event bus. Establishing the boundaries at an early stage of the project will considerably speed up development because developers will know how to arrange all project components. Having everything conceptually organized and structured, the project will be transparent, so the risks of mistakes will be minimized. This reduces the costs of developing a system and increases its stability.
Whether building a city or developing an IT project, you can’t, nor shouldn’t, ever try to plan everything right at the beginning. Looking at the cities we love to visit and systems that make our lives easier, we can notice how numerous elements connect to create the final effect, how they change and develop over time, and that all the elements and improvements combined make us want to either plan another trip to our favorite districts or open the app again. So, a certain level of flexibility is necessary to ensure providing end-users with what they really want in an Agile manner and, as a result, achieve your desired results.
To make the most out of such an approach, one needs to ensure an understanding among everyone involved and an architecture that allows for modification (adapting to changing market conditions) and improvements.
Modular design, prepared during the event storming workshops using ubiquitous language, will allow you to maximize business value at every stage of work, increase development efficiency and allow for later changes and expansion with minimal interference with what was done before – and that’s what you should remember after reading this.
The right people are essential to building cities and developing software. Use the contact form below to get in touch with our experts – we’re eager to share our knowledge and help you find the best solutions.
About the authorKamil Bączek
A software engineer with extensive experience developing projects for the financial industry in international teams. Kamil is passionate about systems architecture and capable of combining business requirements with software design. Focused on creating value for his clients, Kamil believes that „an IT system reflects developers’ understanding of business”.