As network organization is evolutionary and must be constantly adjusted to actual value being delivered you must have evolutionary architecture. Both approaches are aimed to decompose “Big Ball of Mud …”
Even though i think it is essential for network organisation company structured in any way will benefit from this type of product architecture.
You can read more about that in this great article – https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture
Microservices meet this definition because of its strong bounded context principle, making the logical division described in Evan’s Domain Driven Design a physical separation. Microservices achieve this separation via advanced DevOps practices like machine provisioning, testing, and automated deployments. Because each service is decoupled from all other services (at the structural level), replacing one microservice with another resembles swapping one Lego brick for another.
“resources are often divided into silos despite the fact that virtually everyone working in the field acknowledges that solving the problem requires cross-discipline collaboration.”
Quote from the book – Liberating structures
Why do we still divide organization into functional siloses?
- Build multi-functional team.
- Pick up the problem/challenge/value.
- Define whom it’s important for.
- Define dependencies.
- Define success/failure criteria.
- Slice it.
- Give it to the world.
- Retrieve & analyze feedback.
- Keep #6, #7, #8, #9, #10 – cycle short.
Depends (not important)
- Process you use – less is more. underestimated cost of spreading heavyweight process accross users.
- Tools you use – bottom up standardization normally works much better. but would be interesting to make an investigation how/if tools standardization really helps.
- Planning – as lots of work is invested into making a plan, people try to a void changing it to match the reality.
- Various definition and templates – often do not match real work even before being issued.
- Roles descriptions – typically defined for people below high level management.
p.s. Tayloristic organisation defines “not important” as highly important
Organising yourself as a network of multi-dependent teams helps to solve following constraints and increase effectiveness of product development
People from different functional areas must be a part of the same team to eliminate all possible “cross departments” activities
Toyota have long eliminated this constraint through their Obeya concept, and unique matrix structure.
Capacity of Bottlenecks
Often certain teams in the company can become a bottleneck as lots of others start to depend on them. Providing options for teams in different stages of development gives needed flexibility and possibility to act according the situation.
Delayed Decision Making
Building structure around function silos and skills forces you to increase additional layers of coordination or start more projects which automatically leads to more communication points and less efficiency. additionally temporary nature of projects breaks ownership mindset. Organising around value forces you to:
- think long term as there is no end, but continuous value delivery
- focus on relevant problems, especially if options are given to others and they can abandon your service
- build in ownership and quality as things will not be passed to someone else
What other constraints you face? Do you find these common?