Frederic P. Brooks, Jr in “The Mythical Man-Month” describes how companies should plan to build their software over three time to get it right. The first is to figure out the real business problems. The second to fix what you got wrong the first time and the third to correct what you fix in round two but were right in round one.
Sam Newman in his book “Microservices” talks about how it is better to build Microservices from a brown field monolithic application than starting out green field. Strangulating the monolithic means, you have already figure out many of the business problems and you need to discover the seems to extracted and pull out a give bounded context into a microservice. Not a small task but you at least have a better understanding of the business and have likely made some mistake already. Starting out green field, you have little real world knowledge of the business problems and will like get the seams wrong. This mistakes can be very expensive to fix.
Eric Evans describe in his Book “Domain Driven Design” how his concepts provide the greatest benefit to large enterprise projects where small project may gain little benefit.
Sander Mak in an article titled “Modules vs. microservices” suggest that in my words “thinking that ever enterprise application uses a Microservice architecture is a bit like saying every problem is a nail and all I have is a hammer.”
Using Brooks idea and blending in the ideas of the others to understand an evolution to your company’s enterprise software. Plan that you will build every software application over three times.
The first time you should act as a scientist create a hypothesis and forge ahead. Do not spend a lot of time on the specifics speed and learn the business problem rules the day. Always keeping the problem small and if you can’t easy reason about the problem it is too big. Following the principals of SOILD will go a long way in helping in the transition to round two Quality and security are always important but speed of learning the business is more important at this point, remember you will throw this out round one.
The second-round focus on starting to define the bounded context and seems of the domain and improving quality of the software and architecture design. You are now more of an engineer. If round one is right you will be able to migrate from the old code to the new round two coding standards and architecture with easy.
We are now at round three. This is where you are wearing the more of the architect hat and need to make choices base on real past experiences of the size and ability of your team and company to how you architect the software.
Remember not every company is a Netflix or an Amazon. The miscalculation of this could result in as big or bigger problems than if you did not keep a grip on resume writing. (The act of using a technology because you want to say you used it.)