Event storming is worth a shot and here is few reasons why.

Having a chance to work with well-established startups from the e-mobility sector, Bartek gained invaluable knowledge on the industry requirements. On his path, he was given the opportunity to work on numerous EMSP applications and CPO platforms. Bartek is also our Head of Delivery.

Bartłomiej Łazarczyk

Most developers already had the chance to hear or read about Domain-Driven Design. Long story short, this approach is meant to help in modeling complex domains by offering precise tools and encouraging the use of specific, domain-oriented ways of thinking. It is a powerful methodology that works perfectly well with greenfield projects. But what about a legacy system that was, in addition, poorly designed and maintained? The cost of introducing this approach to the entire company is huge, takes a lot of time, and requires some training courses (not only for developers). Thankfully, there is a simple technique invented by Alberto Brandolini called 

. This is a good starting point for discovering Domain and introducing DDD.

Recently, we have started to implement the Domain-Driven approach together with one of our clients, and our goal is to integrate processes for discovering domains based on different Event Storming workshop variants. In the wake of a few sessions completed so far, we have reached some insights, and we would like to share some of them in this article.

First, let's focus on the workshop itself and its most popular variant, Big Picture Event Storming, with its basics and how to facilitate it. The main goal of this workshop is to gather all people that have a business, domain, or technical knowledge in one place and model the current understanding of the system.

You might say that there is nothing special about it, right? There are many other workshops and techniques that accomplish the same, so what makes Event Storming special?

The biggest advantage that speaks in favor of Event Storming is the clear, easy, and structured way of communication between employees from different company units. And because of that, we can naturally stimulate our participants to start a dialog, discussion, share thoughts and, most importantly, to agree on the language and discover it with us.

To perform this workshop and make it successful, you need three key ingredients:

The right people - a greater variety of the group, may color the final view by reducing bias, but be sure to invite only those people who have the most influence or knowledge about a given subject and care about the problem. They will be your domain experts. Developers with long service can be useful experts too, but they need to understand that the event should be considered as business-related.

A good location - the room needs to have at least one long wall and be large enough to accommodate gathered people and give them some space.

An experienced facilitator - you need a person or two who will ask the right questions, timebox every phase, and be able to explain all the rules and stages clearly so everyone would understand them.

As I wrote before, the room needs to have a long, straight wall on which you will be able to stick paper rolls. The bigger the wall, the better. At least at the beginning, all the participants should have space to stand and walk, so you also need to move all the seats to the place or corner, which is not easily accessible. The next important thing is a table with a lot of sticky cards in different colors, a few markers and a board with a legend of what each card means.

Sticky cards are the best tool used in the meeting. In the Big Picture variant, we can differentiate between five types of cards.

Orange cards represent an event and are the main building blocks in our process. To be more precise, this is an event relevant from the domain expert perspective. Events should always be phrased at past tense. Example: Report was generated, Charging has stopped.

The yellow card represents people involved in some event or process. You can treat it as an actor as well. Remember that the goal is not to specify people for each event but to accentuate the involvement of someone outside of the system. Example: Portal user, Support team member

The violet card represents the system involved in some event or process. It can be either an external or internal system. The same as in the card for people, the clue here is to emphasize some external involvement. Example: Third party API, Database

The red card represents a hotspot. This is used for marking a place with the lack of proper knowledge, something that is not working well or to mark a place of disagreement between participants. This is a sign that we need to take a deeper look into it later. Example: Generating report takes to long

The green card represents an opportunity. It can be used for specifying something that is already working quite well, something that we can improve, or some other handy ideas. It can be a good alternative to the hotspot card for an attendee who prefers resolving problems rather than complaining. Example: Delivery reception can be automatized

Up to this point, we have a place to organize the workshop, we have the tools - but what is the process itself? To quickly answer this question, there are five different phases in this meeting:

To benefit from our long, carefully prepared paper board, we need to draw a small timeline at the top of it, explain what each card means, ask everyone to think about some events happening in the system, write down an event on the orange card, try to stick it somewhere on the timeline and do it again and again until everyone runs out of ideas. It’s easy as that! Nevertheless, we often run into a problem with starting to stick cards. In that case, you need to encourage everyone or place an example card yourself to show that it’s just placing a card on the board, nothing more. Since it’s chaotic exploration, the location on the timeline does not have to be 100% accurate but will be helpful during cleanup. This phase should not take long; if you see that no one is writing anything on the cards for more than a few minutes, you can just finish this phase. In the end, it should look more or less like on the image below.

After chaotic exploration, of course, we need to do some cleanup and sort out all the events we have gathered on the board. Unfortunately, it’s not as easy as it sounds. Some parallel processes will surely come up, people will try to kick all events around, and a lot of confusion will happen. To make this phase nice and effective, we can introduce some structure at the beginning. There are quite a few good strategies, but we highly recommend specifying a few pivotal events and introducing swimlanes. We ask our domain experts to choose up to four-five most significant events in the flow. They don’t have to be perfect; it’s enough if the other sequence of events is depending on some pivotal event and cannot happen without its occurrence. That will create a framework on the board, which makes sorting other events easier by determining whether they happen before or after a given pivotal event. We can introduce swimlanes for all sequences of events that can occur at the same time. When everything is put in order, it’s good to make a walkthrough from the first card to the last and assure everyone that they did a great job.

In this phase, we ask our domain experts to specify a few people and systems which play some role in the events. We need this information to have a full picture of the serious dependencies in the given system. It may also point to a place where there is no full control in the system, or where constraints and conditions are present.

So far, we have quite gained a lot of data about our domain, but still, it doesn’t feel as solid and detailed as it should be. To encourage our participants to be more creative and take a different perspective, we should spend more time on the backward walkthrough phase. In general, we need to ask someone from the audience to read out loud all the events starting from the last card. What is different now is that we ask additional questions like:

Is there something more happening between X and Y?

These questions will make domain experts think in different ways, stay focused, and not take something for granted. As a result, we will have new information and more details - and therefore, new events, new flows, and new structures. The most important rule here is to discuss and fill the magic gaps between events if they are apparent. There might be a situation when an agreement cannot be made due to a lack of knowledge. In that case, marking it as a hotspot is a good choice.

The last phase could be optional, but the overall picture of the system will gain a lot from that information. We would like our domain experts to specify hotspots - aspects to improve, and opportunities - ideas to introduce. After that, we organize short voting by drawing an arrow near the most important hotspot/opportunity in the system. This information is a very important sign that in any further discussion, we need to dig deeper into this area and try to solve this problem. We can also prepare a simple metric for a given hotspot/opportunity so it can be expressed with numbers, and as we know from our experience, numbers are intrinsic for business.

As you have already seen, this workshop is not so complicated from a technical perspective and probably could be performed by anyone who knows its rules. However, just as in real life, details play the biggest role. Some obvious behaviours and attitudes are often forgotten in effect, so here are a few tips that came along with practice.

Event Storming is all about the people and their knowledge. The goal is to have as diverse and useful a group as possible. To achieve that, a simple stakeholder mapping technique comes in handy. We need to find a person who knows the system and the company quite well. It can be a Product Owner or someone from the management board. Then, together, try to determine potential participants on a simple figure with two axes: influence and interest. For simplicity's sake, we can divide the figure like in the image below and map people into those areas. The conclusions are self-imposed.

Remember to make the goal of the workshop clear to everyone, especially in the Big Picture variant. People often tend to lose their track if they don't narrow the scope a little by having an explicit reason for carrying out the workshop. That may result in many wrong, or irrelevant events, so unnecessary confusion could happen by accident in further phases.

A good facilitator is priceless and makes a huge difference during the workshop. Leading a workshop is a skill that demands time and experience to be improved, but fortunately, we have some advice on that matter (especially useful if you're just getting started).

At first, keep the meeting and rules in scheduled bounds and don't allow too much freestyle. Boundaries trigger creativity and require mental effort. The next thing is about too specific questions during the Big Picture Event Storming. Not everything is important and necessary at this level of abstraction. More details should be discovered later when the scope is limited, and we have a clear goal to deliberate specific aspects. When something is not clear, just mark it a hotspot.

The last and most important thing is to focus on the language that springs out during the discussion. Domain-Driven Design puts linguistic differences first, so try to pick up details and attributes up as much as you can. Ubiquitous language is necessary to appoint subdomains, and there is no time to write down everything that has been said.

If you gather people from different company units, they could have their own definition of an event. It is really important to have a common understanding that events should be relevant from a domain expert and from a business perspective. An event should not be connected to some implementation and technical concepts because it's highly probable that it doesn't reflect the problem and domain. Often, it is far and away from the business-related issue, especially when you are considering a legacy system that wasn't designed in a Domain Driven way.

Do your best to specify good pivotal items. Ask as many detailed questions about chosen events as you can, e.g., "Are there some events that cannot happen if this event has not occurred?", "Is it necessary for some processes to start and go on?", etc.

This will speed up the cleanup phase, and in the future, it can point to a moment when the language is changing. Pivotal events often come with new processes that could be related to different subdomains.

It's hard to book at least three hours in everyone's calendar. It's even harder to stay focused and feel good during such a long meeting. Proper timeboxing and breaks are a must. Spend your time, more or less, in these proportions:

Chaotic exploration: about 10-20% of time

Enforcing the timeline: about 30-40% of the time (cleanup takes some time)

Backward walkthrough: 30-40% of the time (most of the details come up here)

Hotspots and Opportunities: max 5-10% of time

People would love to see the result of spending their precious time on discovering their domain. Also, from the perspective of a software architect, you need to have a better overall view and possibility to manage it without effort. Digitizing it seems to be the best solution, and for that, we recommend an online tool called Miro. It has a feature to capture sticky cards and convert them to online notes, which can save a lot of time.

Now that we have finished the workshop, everyone is completely exhausted but also satisfied with what they have achieved. And then they ask the important question: What is going to happen next?

The answer is simple. Now it's time for the domain architect to discover and validate the subdomains. We have a big picture view of the whole system, but we don't understand it yet, we cannot tell what exactly is happening underneath, what problems there are, and what exactly we want to solve.

We need to determine emerging subdomains. It's not easy; some even say it has more in common with art and intuition rather than logical patterns and equations. What's more, there are dozens of heuristics and techniques for doing it, and none of them are universal.

Nevertheless, here are a few worth mentioning.

This can be a good entry point for further considerations. Each organization has different units that can reflect different subdomains. Unfortunately, business processes, which are a part of the core domain, often cross different departments, so we cannot rely on this heuristic much.

It's a common situation that within one company unit, there are few domain experts responsible for different issues. This is a clear sign that we may expect different problems in one place and may need different subdomains.

Probably the most important and practical heuristic, which assumes that words and terms have a different meaning in different contexts and subdomains. Company products have different meanings in the sales department and different meanings in the warehouse department. If we don't focus on the language, we risk failing to see these various perspectives, life cycles, and issues separation.

If some aspect comes with huge business value, it should probably be a separate subdomain. You can be almost pretty sure that this aspect is connected with the core domain, the company determinant.

Many business processes often involve different subdomains. Establishing factors that highly influence the process may point to a change of involved subdomain. Finding that might require introducing a clear chronology and asking for more details about what is happening between two events.

Recruiting senior software developers by example.

After founding Solidstudio, Pawel was an originator in terms of pursuing expertise in eMobility. With the build-up of a solid knowledge-base on industry’s needs & wants, he now keeps a close eye on products’ development. He’s also hugely responsible for the business’ side and designs the business models for our products.

Paweł Małkowiak

 is always a challenge; this challenge can also grow depending on the candidate’s expertise. The technology involved in the role is not particularly important, what matters is the talent on offer from the candidate. If you know that only senior or exceptional skills are required then there’s one important question to ask yourself: do I really need to check their coding skills?

This, however, is a rather limited approach. Additionally, if this person has worked with the specific technology for several years, they must have succeeded in the recruitment process previously. Therefore, in this situation, how do you dig deeper and determine if the candidate in front of you is correct? Is there a particular approach you can take to uncover the candidate’s best qualities? And how can you encourage them to demonstrate the experience they have gained throughout their career?

As I can’t give definitive answers which will suit every software company, the only thing I can do is share my current approach for recruiting strong candidates for solidstudio.io.

A few weeks ago, I posted an article which looked at the pros and cons of testing algorithm skills in the recruitment process. In this new article, however, I want to look at whether designing a distributed system is a good task to set during an interview for a senior developer position. Everything here is based on my experience and the dozens of interviews I have conducted within our company.

Before we look at the required task, I just want to clarify why I feel that designing a distributed system is such a crucial skill. Sure, many people will state that the knowledge required can be learned relatively easily. However, I believe that listening to the candidate’s experience in building these systems provides a fantastic insight into their talents.

Let’s take a look at an example of my approach. In conceptual design, even the simplest problems may require highly sophisticated solutions. This is why I ask candidates to design straight-forward functionality:

Imagine you own a website that serves content to its users. Everything is there — content, design, security and scalability — so it’s now time to make some money! Your business model is to display sponsored links in a given section of the page. You get these links by fetching them from an external system — let’s call it system B. Once a user is logged in to your site, you need to ask System B for a link to be shown to this user. As time goes by, links change as the user’s preferences are likely to change as well.

System B will only pay for links to be displayed that are relevant to that individual user. Therefore, after showing the link, you need to update System B with information about user, link and timestamp. Now comes the tricky part: System B is not very reliable — sometimes it is available, sometimes it is partially available and sometimes it is not available at all. Your job is to maximise profit without exposing the failures of System B to your user.

The good thing about this task is that the amount of variation in solving it is almost endless. Moreover, you can see how candidates gather the required information regarding the system. If there is more than one recruiter in the room, one can be a product owner that verifies all assumptions and the other can be another developer to provide some healthy discussion about the system.

Now that we understand the task, let’s talk about the benefits of solving it during a recruitment session. We’ll start with technical feedback first:

- we can easily measure the experience of the candidate. The task also provides a simpler approach towards the quantity and quality of similar problems experienced in previous roles.

- the candidate’s approach to modern system designing is demonstrated and provides a vast insight into their methods. A candidate stuck with an MVC model has little to do, so this provides little insight.

- the solution can involve caching, queues, different kind of storages, synchronised and unsynchronised communication. These are all concepts which require a broad field of knowledge.

Solving this task can also help to uncover some insights about the candidate’s soft skills:

- mitigating developer or product owner role-playing can give provide an idea how the cooperation may work while working on actual projects.

- the more questions asked, the better. Gathering requirements, be they functional or non-functional, are critical in developing good software. A candidate that follows this approach has a greater chance of becoming a successful developer.

- embracing failure. In almost all the scenarios and solutions to the problem, there can be an issue that causes the designed system to fail or not meet the requirements. The manner in which a candidate reacts can give valuable insights about their work approach and how they handle tough situations.

The greatest benefit of this task is that the scenario can be pushed or challenged almost endlessly. Every time that a problem is solved it can be replaced with another. Alternatively, you can start to talk and ask questions from different perspectives and focus on other parts of the system.

Developing elegant and innovative solutions to the problems present can indicate that a candidate is the right fit for your software house. And, in most of the cases we’ve experienced, the candidate had no issue with the next step of the recruitment process: a coding task. However, when you’re looking for a senior software developer, a coding task is something that you simply cannot skip, so it’s vital that this skill is tested.

Where is the design?

True cost of software outsourcing - how can you meassure this?

Software development outsourcing is the term used when a technology company is hired to create and build a business’ IT systems. A hugely beneficial practise, outsourcing in this way can help small to mid-sized companies in particular not only gain a competitive edge, but significantly reduce costs and implementation time.

While the premise of software development outsourcing is quite simple and its benefits clear, finding a reputable company to deliver such services can be a challenge. Google ‘software development companies’ and the result is seemingly endless pages of vendors offering their services at competitive rates. So how do you know which of those developers will properly fulfill your needs and offer true value for money?

Knowing what to expect from a vendor, from both a service level and cost perspective is vital before choosing the best 

 for your business. There are a number of considerations that will help you identify a reputable software development company, all of which are detailed here, plus how much you should expect to pay for such services.

Software development outsourcing: What to consider

Outsourcing software development involves a significant level of trust from both parties to work successfully. More often than not, a business will have to share confidential and valuable data in order to get the IT systems it requires. Any reputable software development company will understand this and offer a service that not only meets a brief from technological perspective, but a human one too. To find a tech partner who will do just that, look out for vendors with the following attributes:

 – A reputable software development company will be sympathetic to their line of work being highly specialised, and will therefore help clients form requirements, ask difficult question and make sure all parties are completely clear on the business’ objectives

 – Making sure a software development company has the right skillset to fulfill technical requirements is vital, as any gaps in knowledge could lead to costly delays. A close look at a vendor's portfolio will give a good indication of whether the team possesses the correct skills, across the most relevant technology.

 – The more senior a team, the more business-orientated it is. A good way to gauge experience levels is to look at ‘Meet the team’ pages and see what percentage senior developers account for.

 – While a project might need multiple developers input, it’s a good idea to choose a vendor who will assign developers to one project at a time. Not only will the sense of ownership help increase a developer’s output, but means each project has one firm point-of-contact.

 – Any software development company worth it’s weight will help a client see past the ‘now’ with any technical requirements, and offer the expertise to scale a project up or down as needs and situations change.

 – Developers are in high demand globally, but that shouldn’t mean waiting long periods for projects to get off the ground. At Solidstudio, development can start in a matter of weeks, with the initial planning phase up and running in a matter of days.

 – A quality software development company will stay in regular contact with clients for a project’s entirety. At Solidstudio, weekly and biweekly calls are standard practise. Clients are also invited to join internal communication channels and are welcome to dial into daily standups if they so wish.

 – The last but one of the most important considerations of all. A quality software development company will be completely transparent at every stage of a project’s progression. From planning and implementation, to costs and potential issues, any work completed should be visible to the client, at any point. Be wary of talk of or signs of further outsourcing from within the vendor – this is also a major red flag.

Software development outsourcing: How much should it cost?

So now you know what to look for in an outsourcing software development company, the next big question is how much should it cost? Giving an exact figure here is almost impossible for two main reasons; firstly, because every project will have different requirements. And secondly, creating a digital product is a process of constant change, and therefore an estimate provided at initial contact stages could easily change (sometimes significantly) as the project evolves.

In order to get a realistic estimate, the best first step is to spend a good amount of time considering what your product requirements are and drawing it up into a project specification document. This should broadly outline how the required software should function, in both the short and long term, which will help vendors understand what level of work and seniority is required. It will also help avoid any misunderstandings in the development cycle and costly delays.

After sharing this document and an initial consultation with your chosen vendor before any work is carried out, you should expect an estimate based on an initial assessment of how much work is involved and the level of seniority it will require. Solidstudio has a track record of smaller end-to-end software development projects over a three-month period, as well as bigger, on-going projects and so can quickly offer very accurate initial estimates. These would include costs for:

It is worth reiterating costs can (and almost certainly will) change as a project evolves. Be wary of low estimates, cheaper estimates don’t necessarily offer the best value, and can often include hidden costs that soon add up. Reputable software development outsourcing companies will be completely transparent when it comes to costs, keeping clients abreast of any changes, and ensuring to check before undertaking new work that might add to the bill.

 is often best suited to IT outsourcing. This pricing method means fees are configured based on the amount of time spent on a project, combined with the cost of the effort (materials) used in the process. Solidstudio works to an hourly rate structure of $40-75, depending on the level of seniority required, with management overlay kept to a minimum.

For more information on software development outsourcing, or for an estimate, contact the Solidstudio team!

True cost of outsourcing - how can you meassure this? Read our article to find out.

Software development outsourcing: what to consider and how much does it cost?

Guide to hiring an offshore team for product development.

Hiring an offshore team for product development.

 is of the most effective strategies companies use to achieve strategic business goals. For product development to work, organisations need to build a strategy that involves quality design, reasonable action plan, and well-charted stages of development. Only once all these elements are in place, the company can start looking for the best offshore partner to help realize this goal.

In the context of product development, an offshore company works as an extension of your internal team. Working in accordance with a development plan that you can easily share and communicate helps to keep everyone on the same page.

But why are so many businesses choosing offshore product development companies to help them out?

Benefits of offshore product development.

As local economies become globalized, many organisations consider offshoring product development to take advantage of the most talented workers on the market.

Offshoring product development comes with many different benefits:

It’s cost-effective - by outsourcing the task of developing a product, you’ll be saving up on all the costs associated with sourcing, attracting, and hiring new candidates for the job. You won’t have to spend time on recruitment, onboarding, and training new employees. Moreover, by teaming up with an offshore product development team you’ll be saving up on office space and equipment.

It helps to save time - outsourcing the entire process of product development saves the time and energy of your internal resources. By having someone else build the product, your team gets to focus on the bigger pictures.

It gives you access to top talent - by expanding your talent pool to the entire world, you get the opportunity to work with highly-skilled experts in the industry. Offshore teams often have extensive experience in their field and may have previously worked on similar projects, offering you insights into problems that might arise. Moreover, you get access to a ready-made team that has experience working together already - they have tools and processes in place to make the product development process smooth and successful.

Choosing the right product development outsourcing partner.

It’s essential to partner with an offshore company that is experienced and trustworthy. That means you need to do some research, develop a clear vision for the product you want to build and review the portfolios of potential partners.

It’s smart to create a list where you compile all the critical questions you’ll have for your potential partner. Here are some examples:

Is the vendor experienced in creating products for other companies?

Do they have a quality management system in place?

How do they approach communication, and in particular project transparency?

How much control will you have over the process and team?

What were your vendor’s biggest success and failure over the last year?

Check the company’s portfolio of case studies and references. Be sure to ask for contacts to previous clients and ask them about their impressions. A professional product development company will share these details with you right away - after all, there’s no reason to hide if they did a great job.

Sometimes a face-to-face meeting might be necessary to understand the culture of the company with which you want to team up. Why not travel to the vendor’s office? Have a look around, meet with account executives and project managers, talk to the staff and get the general feeling of the atmosphere at the company.

Key factors to consider while hiring an offshore product development company.

It’s possible to build an effective working relationship with an offshore team - but only as long as you prepare for that type of collaboration. With some careful planning and a thorough vetting process, you’ll hire a partner who will help you bring your product development project to success.

Here are some best practices to get you there:

 - make sure that your internal team has a clear understanding of why you’re entering a partnership and what your objectives are. You can focus on core business processes or simply reduce the workload of your in-house team. Once you know the goal and scope of your project, you’ll be more prepared to hire an offshore team that can help you succeed.

 - lack of communication is the most serious pitfall of offshore collaboration. That’s why you need to check that the offshore team has solid communication tools and processes in place. Consider how working in different time zones may affect your ability to reach the team during business hours. Remember to be clear about your expectations in terms of communication.

 - understand the cultural differences and customs of the target country to which you’re outsourcing. They may impact your collaboration. That’s why so many organisations are partnering with companies located in Central European, and especially in Poland - the professional culture is similar to Western standards.

Are you looking for a highly experienced product development team? Get in touch with us, we’ve developed a broad range of software products and have the skills to create yours in the best possible way.

Discovering complex domain with Event Storming

18 MARCH 2020 • 16 MIN READ