Goals

Development of complex distributed software systems is not an easy task that requires quite a lot of investment. So, why do it? Here are some of major business reasons:

• Improve business agility – time to market for products, features, fixes
  • Shorten time to market by releasing small and often
  • Increase velocity by delivering many features all the time
• Decrease investment into software development
  • Decrease wasted effort, time
  • Simplify and improve the maintenance of the codebase, which accounts for the biggest chunk of system cost

Problem

Most software systems are built as monolith – a very interconnected, interdependent collection of components and modules, which increase complexity of the implementation with time, while hurting business agility. With the move to distributed system development it is crucial to understand how not to fall into the same trap – there is a lot of negative feedback from teams trying microservices and running into cross-service dependencies, issues with data ownership where one service does something to the data of another service, distributed transactions, etc.

One of the aspects that may not be overlooked when going into distributed software development (microservices as a potential implementation technique) is team structure, source code organization and ownership.

Most engineers and teams are used to organize their team structure following layered approach. So you end up with DBAs who rule relational data stores, Middle Tier team(s) who work on implementing business logic and maybe even application logic (unless that’s another layer that’s managed by other team), Front-end team(s), Integration teams, etc. You get the picture.

What is the normal development and release process with such team organization? It is heavily reliant on cross team coordination of schedule and implementation, various integration efforts, testing and QA, “over the fence” sort of mentality that becomes a real issue in any non-small organization. What are the chances of business ability to release small and often? Quite low as you understand.

Solution – Feature Teams

Over the past few years microservices became a very popular buzz word that attracted a lot of engineers and business people alike for these exact reasons – promising to deliver development experience that addresses business needs of agility, cost and value.

Once your organization is in a distributed software realm it really needs to start some major re-organizational efforts. Development teams can no longer be implementing bits and pieces of the functionality asked by the business – they really need to become self sufficient, autonomous and own the full vertical of the implementation of a feature. Without such re-org an organization is simply not going to be successful in development of any complex distributed software system.

Development must revolve around features – top to bottom, so one team can start it, work on it independently, complete and deliver it. A single team owns that feature. That sense of ownership is a great positive for everyone – business can expect teams to do their best to make it work as the feature implementation is the reflection of their professional abilities; development teams take pride in their work, feel a sense of accomplishment, deliver real, tangible value to the business.

Team structure should be based on features. A single team owns and builds code for front-end, middle tier, integrations, back-end. They own it all, they don’t ask anyone else to do their part in order for this team to be successful. And this brings us to another point – how a team can be autonomous, independent? What if the feature they are tasked to build needs some other service? Well, it’s time to look at the foundation of distributed software systems – Service Oriented Architecture (more here). It is this architectural style that gives us a concept of autonomy, ownership and encapsulation – an SOA Service. So, if a team owns a Functional SOA Service implementation, they become really autonomous, independent and able to deliver features asked of them. Each feature, most likely, is going to be an implementation of a DDD Aggregate that belong to the Functional Service the team owns. There is no need to involve any other team – even when consuming another service’s contract the coupling is much lower and promotes independence.