Evolution of Monolithic Systems

Think of traditional organizations in which business analysts, developers, testers, and operations staff operate in separate functional teams. These teams are dependent on each other at a very low level. Even though they may be working toward the same goal, they will inevitably have different priorities. They will also have different processes and

Each year, it took longer and longer to ship features to customers, and the risk of even small changes causing major problems kept growing. In 1998, developers could make changes and deploy them immediately. By 2004, pushing code changes into production required hours, even days, to be deployed.39 Teams were no longer able to solve Layer 1 problems

As the software stack for any development effort has exploded over the last 10-plus years,7 organizations with strict tool standards have been at a distinct disadvantage, as their process for adding new tools has been too slow to take advantage of rapid advances.

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.