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.

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.

Why do large systems disintegrate? The process seems to occur in three steps, the first two of which are controllable and the third of which is a direct result of our homomorphism. First, the realization by the initial designers that the system will be large, together with certain pressures in their organization, make irresistible the temptation to

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.

In the end, making some decisions early on is irresponsible. For example, settling upfront on architecture, such as using Microservices, or trying to create generalized solutions and modeling abstractions, is wrong. These decisions should be postponed until we prove that those choices are justified and necessary.

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

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.

This is a good place to introduce the idea of using an engineering model approach to software development as opposed to the contractor model. First consider the typical contractor model. Under this model, whether used by employees or actual contractors, developers must be given accurate tasks to work on, and they must not fail in even small ways. T

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