I enjoy discussing the ideas behind microservices quite a lot (typically here on Voxxed!), and one of the recurring questions I get asked is ‘how do the business and organisational factors affect the implementation of a microservice architecture (and vice versa)?’ Check out twitter conversations or the panel discussion from the recent muCon microservices conference for examples of this question. The purpose of this article is to provide pointers to several books I have found useful in developing my understanding of how best to answer this question.
Understanding the Business is Important
Although I’m a techie at heart, I’ve grown more interested in the business and organisational issues over the last few years, and have come to appreciate that I need to better understand these topics in order to build the correct software. I’m sure many people who are investigating microservices have stumbled across the often quoted Conway’s Law in relation to the impact the structure of an organisation has to the design and implementation of software, and although this is a very useful rule to remember, it is really only the tip of the iceberg.
Rather than simply answer the question of what impact the business and organisation has on the implementation of a microservice architecture (and vice versa), I wanted to share with you a series of books that have helped me form an answer and also provided further insight. In each of the brief reviews below I’ll attempt to highlight my key takeaways.
As there are quite a few recommendations I have decided to divide this article into three parts. The first post will look at the business drivers and requirements associated with the decision to move to a microservice architecture, and the associated implementation. The next post will examine the organisational communication challenges that emerge when teams begin to develop small inter-operating services. The final post will attempt to address the ‘big picture’ organisational technical issues, such as the DevOps philosophy and the need for architecting correctly for encapsulation, scale and comprehension.
I bought this book while attending QCon London last year, and it has been a great read. It discusses the difference from a business perspective between the traditional ‘command and control’ enterprise-style ‘divided company’ and the emerging autonomy-driven service-based ‘connected company’. The core of the book provides suggestions and techniques on how to move from one to the other. There are clear parallels between the business drivers of an organisation and the choice of whether to implement a monolith or microservices, and much of the advice offered here is directly applicable for analysing, designing and implementing software.
Anyone reading this book will instantly recognise the ‘connected company’ archetypes, such as Amazon, Netflix, Spotify etc., which are also often referred to as the ‘DevOps Unicorns’. Whatever you may think of the companies, it is difficult to argue against their recent success, and this book provides a useful insight into several of the approaches and patterns used within these organisations to not only increase velocity, but also deliver what customers want.
Examples of the key trends discussed are the move from a hierarchical to holacracy-based management structure, and the move away from division of labour focused into specialised teams towards ‘fractal’ autonomous work units (the famous Amazon ‘two pizza’ team, or a Spotify ‘squad’). Gray summarises that the ‘divided company’ is predictable in stable environments, and the ‘connected company’ is adaptive in uncertain environments. This is great food for thought as to whether the microservice architecture is appropriate to your business. Of course, there is no silver bullet, simply an appropriate solution to a given problem.
The book is divided into five parts. The first examines the motivations of the principles behind operating as a more connected company. Part Two defines what a ‘connected company’ is, and Part Three continues by explaining how a connected company works. How to lead a connected company from a managerial perspective is discussed in Part Four, and the book concludes with a guide on how to move towards becoming a connected company.
Part Three of the book really shines in relation to the organisational factors involved in designing and building microservices, and Gray discusses the nature of the connected company being based on systems, how to handle the inherent complexity, and the need for loosely-coupled/highly-cohesive autonomous work units he has named ‘pods’ (note the similarity with Kubernetes!). He also discusses the need for platforms to support the work of pods, and here the microservice analogies stack up nicely. This chapter alone is worth the price of the book.
The discussion of these topics is a great primer to learn how to determine if your organisation would benefit to the move to microservices e.g. are you competing in a market where ‘speed wins Moscow’ and the ability to adapt is paramount to survival. If you do decide microservices are for you, then this book will provide a great introduction to some of the challenges you may face from a human and organisational perspective, and will also offer very useful guidance.
This is a superb book for understanding the role of a Business Analyst (BA), and why it is essential. An overview of the entire range of approaches and techniques including the investigation of business issues, modelling processes, defining requirements and producing business cases. In my experience it is essential that members of the tech team within a business understand exactly what problems the business as a whole is trying to solve, and also how the current associated solutions have been implemented. If you don’t understand the business problems, how can you possibly know that a microservice architecture is the correct solution?
The book begins with defining what business analysis is, and then discusses the core competencies of a BA. Chapter 3 launches into the requirements for strategic analysis, defines the business analysis process model, and provides investigation and modelling techniques. I have found these techniques extremely useful in understanding a business and capturing how the people and processes currently map to any deployed software and other systems.
There are several chapters on stakeholder analysis and management that provide great explanations and implementation guides to techniques such as MoSCoW requirements prioritisation and RASCI responsibility matrix charts. I personally use these techniques extensively when attempting to introduce new processes and ways of working into an organisation, or when delivering new methodologies of implementing of software.
The book concludes with several chapters discussing approaches to gathering, managing (documenting), modelling and delivering requirements, which I have found very useful when engaging with stakeholders during the implementation of ‘DevOps’ methodologies and microservices (or indeed any new software development approaches).
This is an awesome little book that explains the science and implementation behind a technique named ‘impact mapping’. The key premise with impact mapping is very similar to Simon Sinek’s ‘Start With Why’ (also highly recommended), and attempts to ensure that a business focuses on the ‘why’, ‘how’ and ‘what’ in this order, when designing and implementing software. This book is very much focused on understanding and defining the ‘impact’ of the business and the software it creates, which is essential for understanding the key drivers that determine whether a microservice architecture is appropriate.
The aim of impact mapping is to help create better plans and roadmaps that ensure alignment of business and delivery, and also enable easy adaptation to change (an often cited benefit of microservices). Impact mapping sits alongside current trends in software development including goal-oriented requirements engineering, frequent iterative delivery, agile and lean software methods, lean startup product development cycles (build, measure, learn) and design thinking.
I personally have found that many of the trends mentioned above are complementary to implementing a microservice architecture. As the correct definition of the strategic goals is arguably vital to the success of a company then learning about impact mapping provides a high return on investment. I have also found that the implementation of microservices does require more rapid and iterative feedback between developers and the business stakeholders, and any tool such as impact mapping that facilitates effective collaboration and shared understanding is always useful
The author of the book, Gojko Adzic, is quite a prolific speaker and author, and if you haven’t come across his work before I recommend you pop over to his website.
The primary purpose of the ‘user story mapping’ technique is to build a shared understanding of what you are attempting to build a why. Although very similar to impact mapping, user story mapping is conceptually closer to the tactical approach (as opposed to the strategic impact) on how to define and capture the requirements for the software you are building. I have found user story mapping extremely valuable for capturing requirements, and also in guiding the logical groupings of functionality (‘bounded contexts’ in Domain-driven Design parlance), which is very useful when implementing microservice architectures.
The book begins with an overview of user story mapping, and then moves on to provide guidance on how to plan to build less, learn faster and finish on time. All of this content is directly applicable on how to approach the design and implementation of a microservice-based architecture. There is a great discussion of how to define a ‘minimum viable product (MVP)’, how to prototype to learn (and how to validate your learning), and how to build the product iteratively. I have found these techniques very useful when implementing microservices, especially the notion of prototyping ‘disposable’ services that are small enough to allow them to be thrown away when the associated learning have been accomplished.
The core of the book focuses on providing techniques and methodologies for creating effective user stories, dividing problems appropriately, and how to create shared understanding through the software development team. The book concludes with approaches for planning work ‘Refine, Define and Build’, undertaking the work, and ensuring that validated learning is achieved from everything you build.
I have already mentioned this book above, but as it is a classic I wanted to mention it again. Adrian Cockcroft (of Netflix fame) recently proposed at Dockercon that microservices are ‘loosely coupled service-oriented architecture with bounded contexts’, and this book introduced the term ‘bounded contexts’.
The core premise of the book is that it is essential to correctly model the business processes within any software deployed. The use of a ‘ubiquitous language’ throughout the business and tech team is thoroughly discussed, as the creation and use of entities, aggregates and value objects, and dividing the business process model into bounded contexts of logically grouped code. This book is essential reading for anyone looking to understand the motivations of splitting a code base into a collection of encapsulated contexts (archetypal ‘microservices’?) and also techniques on how to model and implement this.
It could be argued that before an organisation can properly implement (and leverage) a microservice architecture the notion of agility (XP, Scrum etc) within the SDLC must have fully been embraced alongside DevOps-inspired practices (continuous delivery, automation, infrastructure as code, monitoring etc). This book will provide a great primer to the foundational DevOps methodologies from a business perspective.
Many organisations are now embracing ‘Cloud Computing’, whether it be private cloud created within an internal data center, public cloud such as AWS or GCE, or a hybrid of the two. Microservices, DevOps and Cloud are also often packaged together as the holy trinity of agile software delivery, and this book provides a superb business-oriented overview of cloud computing and the deployment models available.
Topics covered include cloud service models (SaaS, Paas, IaaS etc), architecting for the cloud, data and security considerations, SLAs and monitoring, and the organisational impact of the cloud model.
Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology
A lot of the motivations for microservices came from the service-oriented architecture (SOA) approach, and so it makes sense to understand the drivers for SOA from a business perspective. This book attempts to meet this goal, and it does so quite successfully.
Topics discussed include SOA business modelling, design and construction, governance and organisational impact, and the business case for SOA.
We Want Your Recommendations!
If you enjoy this article or want to share additional material, then please do get in touch via the comments below or via Twitter, and don’t forget to stay tuned for the upcoming parts two and three of this series.