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

A business capability answers the “What?” question regarding the means by which the company will generate revenues. A substantive question with regard to a business capability is “How?” Impact Mapping, discussed in Chapter 2 in the section “Strategic Delivery on Purpose,” explains driving software deliverables starting with the question “Why?” By t

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

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.

“Domain expert engagement is to architecture as end user engagement is to feature development. You should find that end users and domain experts are your most treasured contacts in Lean and Agile projects”

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

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.

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.

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.

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