Microservices Ready model step 2 – Organisation

Implementing a Microservices approach and architecture, might not only change the fundamentals of your thinking when it comes to IT architecture, you may also need to reconsider how to organise your teams and support functions to achieve the objectives.

One mayor reason for implementing a microservices architecture is often to shorten release cycles and time from idea/requirement to deploy. Microservices are supposed to decrease complexity and is often paired with the implementation of a ”DevOps” style of work.

With a monolithic architecture split into pieces with reduced dependencies, it is possible to release and deploy smaller chunks of code that operates independently and isolated from each other. This in turn makes it possible to release code more often and to move away from complex release cycles and deploy freezes.

Working ”DevOps” style with combined forces from development and operations, even makes it possible to go for automation of release processes, testing and deploys to production. It is not required to work ”DevOps” style if you implement a Microservices strategy, but it certainly creates an opportunity that many choose to explore (we will expand on the DevOps phenomena and possibilities in the ”DevOps” phase of the Microservices Ready Model.

For more reading on DevOps we also refer to our DevOps Ready through CAMS model with attached guidelines.

Teams, competencies, sharing and guideline based management

Apart from posing a great opportunity to work ”DevOps” style when you introduce a Microservices initiative, there are a lot of other organisational considerations to be made when entering this path.

• You must decide how to structure development teams that are to work with the development of Microservices. 
• What kind of competencies do we need in each of the teams and how do we ensure that we have access to the right resources. 
• Can we find them internally or do we need to look for external competencies to get started or to support our initiative? 
• If we decide that we want to do this with internal resources, what kind of training will they need and where to get it? 

As with any implementations of new technology or software product, we believe that planning and a clear strategy is the key to success. You should use the findings of the Proof of Concept phase to define how you want a team to be structured, define what competencies they require and establish a plan to achieve these skills. You must also decide on how to manage, guide and control your Microservices initiative. Within this area we believe that in order for teams to be really productive and innovative you should leave them as much space as possible. Establish a set of well defined guidelines and rules that are the foundation of the initiative and make teams adhere to these.

Guidelines and joint key architectural principles are key so that you do not create an architecture and code base that you can not maintain nor monitor.

Apart from that we believe that a coaching management style best allows teams to innovate and deliver on tasks, without being affected by to much management control. Working with Microservices (and modern management), the results and adherence to guidelines are more important than exactly how it is done.

In our opionion it is also very important to establish a culture of sharing amongst teams. If one team innovates on a smarter way to do things, they should find it natural to share findings with other teams. The same of course also goes for when identifying obstacles or required changes in guidelines or methodology.  

A few organisational take-aways...

So to summarize our input on the organisational aspect when implementing a Microservices strategy and architecture, here are a few take aways…..

• Go for smaller, self driven teams.
• Define a set of guidelines that everyone has to adhere to. Not to many and not to few to avoid a Microservices architecture running out of control. Observe that it is absolutely crucial that all teams follow the define guidelines. If it turns out some guideline is wrong – alter it – instead of having teams override it.
• Adopt a coaching management role instead of a controlling one.
• Define what competencies shall be in each team and create a plan to make sure they have it.
• You may very well combine traditional Developer and Operation roles in one team to work ”DevOps” style.
• Establish a result focused culture with a sharing attitude.
• Coach, mentor and alter on the fly if required. Be prepared to have an active, curious and open minded leadership!

Learn more about our Microservices Ready model here