Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture (Addison-Wesley Signature Series (Vernon))

When the team has decided on modules first, and when deployment options start out as simple as possible, that approach puts them on solid ground to make decisions based on empirical information at the most responsible time.

Assertion: Those who want to build good software that innovates must get this communication–learning–innovation pathway right before trying anything else.

Even so, problems will occur when trying to apply Bounded Contexts with distributed computing before the teams have a good reason to, or when trying to understand the strategic goals and solve business problems using single-process modularity first. Such a bias will likely lead to over-engineered technical approaches, putting too much emphasis on t

Planning too far ahead will lead to conflicts in goals and execution. Going too far too fast can lead to purposely overlooking debt or forgetting to record it. When under heavy pressure, the team might fail to care for debt sooner than later.

The greatest innovations have come from relentless experimentation coupled with continuous improvement.

Early on, it is best to choose a deployment option that supports fast experimentation, implementation, and delivery. This specifically points to using a Monolithic architecture in the early stages, because trying to solve distributed computing problems before the business problems are understood is an act of futility.

As an example of using a methodology or process execution framework, Scrum identifies four primary reasons to place an item in the product backlog: Features Bugs Technical Work Knowledge Acquisition It’s disappointing that Knowledge Acquisition is consigned to last place, because it should always be in first place. How can a team place a new featur

Conway’s Law doesn’t leave anyone guessing about how to make organizational communication structures work for the greater good. As the conclusion of Conway’s paper states: We have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.

The quickest way to deliver the best outcomes for users is by driving in the straightest possible lines of incremental improvement. Select from the best service-level architecture and deployment options based on full knowledge of need and purpose.