The Need for Speed: Moving fast when architecting in a microservices environment
By: Navdeep Singh
Tags: Agile, Agile Architecture, Microservices, Transformation

Image by Arek Socha from Pixabay

If you’re environment is anything like mine mine we’ve got some things in common: we move fast, we collaborate, and we deliver. Being an architect and working in a fast-paced organization where delivery matters most is never a dull moment. It’s highly challenging and the need to bring compelling and innovative solutions to market with speed is a way of life. Moving fast, focusing on timelines while maintaining quality, and delivering to an architecture strategy can feel like competing objectives but they are not. Architects are at the epicenter of making these work in harmony, bringing together objectives which on the surface seem to bump up against one another but in reality need to be weaved together. I put together some things I do — the methods to my madness so to speak — as I architect solutions, stay practical, and meet aggressive business needs. Hope you find these useful in your day-to-day adventures.

A line of business head just sent an email to several product owners detailing a business opportunity with projected high revenue. It’s a new segment where being first to market is crucial to capitalize on the opportunity. Within six (6) weeks a first release needs to be in production and be positioned to quickly take on new features which are already being discussed. You’re the architect in charge, where to start? Everyone’s adopted agile so this is a piece of cake, right? Before you breathe that sigh of relief let me tell you this is hardly the case. Following an agile delivery method alone does not mean you’re going to move fast. Moving fast is an art and a science requiring key ingredients spread across people, skills, and ways of working.

The scenario above and the need to move fast describes my daily professional life. Having been in prior roles where agile teams could not get out of first gear I have adopted fundamentals which architects must do to enable product teams to move fast. I’ve learned valuable lessons along the way, dissecting each and every initiative I’ve been a part of to find ways to do better, move faster without sacrificing quality, and keep to an overall strategy. Being the architect in charge means I have to lead, do, and deliver by coming up with an architecture plan across products, drive discussions to closure by making key design decisions, and provide multiple teams with clear details of the solution to be built. Having to do this in a microservices environment raises the complexity where domain boundaries and integration contracts must be clearly established and adhered to. If they are not, the thought of moving at speed while optimizing for scale, agility, and flexibility will be, to be blunt, a pipe dream.

Having to solve real world business problems where time matters is invigorating and the rewards of making business happen are highly gratifying. Architects play a critical role and must act with speed to market as a priority. Development teams and product owners will look to them to define the strategy, make decisions, and articulate a concrete solution spanning multiple products. In this article I want to narrow in on the key things I do daily to move fast and deliver product architecture using microservices while managing technology risks.

Now let’s roll up our sleeves. When a need like the above comes forward the first job of the lead architect is to work with product owners to do an impact assessment, defining a baseline of what capabilities need to be delivered as well as which products and microservices are impacted. Being fluid in a microservices environment brings many challenges and this baseline will bring an understanding of the business need, required features in the initial launch, and a list of impacted microservices covering those needing change and those to be built. Be sure to eventually document all of this in agile epics because what happens next will be a series of discussions and negotiations across product teams to break epics down into stories, enabling detailed architecture solutioning and parallel development.

Over the years I have very deliberately adopted a way of working and a set of architectural practices geared for high speed delivery using microservices that avoid the traps of having an organically grown so-called “architecture”, service boundaries not aligned to business capabilities, getting stuck in analysis, and not enabling delivery. What I don’t want is an architecture that is happenstance, not tangible, or worst case brittle and inflexible. It must be consumable by those on the ground and implemented to its specification. The job of an architect is to not simply hand something over and walk away, their job is to be there until products go live, to observe how their solutions work in production, and to make them better in the next iteration. Here are some of the top things I personally do which I’ve fine-tuned to deliver microservices at speed and with precision:

Invest in understanding the business process by detailing the process and data flows, and all integration points. This sounds like a no-brainer but there’s much more to it. Don’t be quick to draw something conceptual and then shift to designing and coding believing it’ll get you to the finish line faster. Start by getting a deep understanding of how the processes work and all the end-to-end touchpoints. Stay at the physical level, being abstract will keep you away from the important details required for solutioning. You may have to start at the conceptual level with boxes and lines but very quickly shift into tangible views that show the details of the business flows, services and components involved, data flows, and all points of interaction. Ask questions about the process and the “what if” conditions, drawing out what needs to happen when things don’t work as expected. Piece together the architecture in parallel, revisit and iterate over the process with the product owners and key stakeholders until there’s a solid working version which can be used for the next steps.

Strictly adhere to the domain model. As you work through the business process, have that ever-so-important domain model close by to direct your decisions on service boundaries and domain data models. The domain model might need to be extended or changed, be sure to keep it up to date. This is one of those non-negotiable items that if you don’t get right you’ll have a messy architecture that’s complex and difficult to change. It’s critical to get microservice boundaries accurate by defining what they do, what information they own, and how they interact with the other components of the solution. Ask deep questions to product owners and business users, drawing out clarity on process details so that domain boundaries can be kept crisp, data ownership and needs are clear, and microservices adhere to the business capability model.

Be ruthless but not reckless. Ruthlessly determine what the minimum viable architecture (MVA) solution needs to be in order to satisfy the initial release. The goal is to develop the simplest solution that will be scalable and flexible enough for future expansion. You’ll have to make some key tradeoffs and know when to fall on your sword and when to let things go. Be decisive, clearly define the must have architecture elements over those which can wait until later. Remember, don’t strive for perfection because perfection doesn’t exist, leads to analysis-paralysis, over-engineering, and will slow you down. You can always come back and iterate on the initial architecture. Avoid the trap of building for requirements which are not yet a priority or do not exist.

Define API contracts early and iterate. Develop these alongside discussions on the process flow and iterate quickly as you define microservice interactions. Detail the resources involved and what operations will need to be supported in the initial release. They will help with discussions that bring clarity to the services that need to be built, how they will work together, and what the boundaries will be. The data needs, including what information needs to flow between each microservice and what data each will own, will also get drawn out. Once things settle the API contracts and specifications will be critical artifacts for enabling teams to work in parallel, providing SCRUM masters and lead developers with important pieces of information to create user stories and for sprint planning. Make sure these artifacts provide answers; if questions still remain keep at it until they are closed. API specifications can even be used to create skeleton code and prototypes, which can be useful in certain situations. Investing in the API contracts will pay back dividends as they inform multiple teams how their microservices fit into the overall solution and will be key enablers for parallel development.

Immediately plan for the fast follow. Last but definitely not least architects must always think a few steps ahead. If you’ve done everything I’ve laid out above you should have a list of the features which won’t be a part of the initial release but must come shortly thereafter, you should have a list of things you ruthlessly did not put in the initial launch but need to be addressed (including technical debt), and you should already be thinking about the next iteration of the architecture solution. I typically start conceptualizing the next version of my architecture halfway through the solutioning for the initial launch and will be slowly drawing details of the next iteration. Keeping a couple of steps ahead and in lockstep with the business will prepare you for the next phase and gives a bit of breathing room to plan and start solutioning.

So there you have it. Sounds easy, right? I know it’s not, however I can assure you these items have worked for me and will work for all architects. Architecting with microservices in a fast-paced environment is challenging at multiple levels and must be met with high collaboration, deep focus, and tangible solutioning. I’ve been doing the above successfully for a number of years within complex transformations involving legacy modernization and when having to build new systems from the ground up. Your architectural output must be directly consumable by product teams so keep it practical and explicit. Create those API specifications, draw those process flows, create detailed microservice designs, and model that data. Find what works for you in your environment and make business happen.