Maybe one of the most infamous and crucial characters of the movie series which made geek = cool (thank you Cohen brothers!) was “The Architect”.
Everything happening in that virtual world was of it’s design and reflecting a structure which was designed to satisfy the needs of all (well…) of it’s “forceful” – some more than others – hosts, thus infamous.
But even the infamous Architect understood that it’s survival depends on how happy he can make his hosts to guarantee it’s own survival – I accept this isn’t the best metaphor but fits nicely in the 7 pillars:
Vison, Empathy, Collaboration; Adaptability; Autonomy; Governance.
Microservices implementation require a lot of re-thinking; re-engineering; re-code etc…
It’s not one single person to do it it’s an organisational shift with sponsorship and vision from above.
The Architect or even better the Architect Board are working with the business and the teams or squads to ensure the transition are done successfully.
Going from SOA or Monolith architecture to a Microservice Architecture will mean huge changes and challenges.
Your approach is key, gradual change can be made and implemented which will benefit and ensure it’s gradual success.
First things first, counter intuitively and sound sense is to identify 3 main areas, 1) Strategic Goals 2) Principles and 3) Practices.
Strategic Goals are aligned with the business outcomes and needs, it’s non-technical and influenced by the company heading and values to the high-level goals.
This will be naturally influenced by your organisation departments and divisions.
Principles aka Rules are influenced the identified and conceptualised goals.
Same good Principles are: size matters, “Fit a Poster”; “Fits in my Head” means small and easy to remember with a reduced nr, maybe 12 like recommend by Agile to ensure they don’t overlap or repeat themselves.
Golden rule very much like in Agile Methodologies, they should reflect the kind of culture you want and aligns with your goals, make sure people first over processed or tools, rule of thumb don’t push it or you doing it wrong.
Lets talk Practices, here it’s also influenced by the above and the main objective is to support the principles you have established, ex: if you are using containers than use best practices, agree to use RestAPIs for all communications; the lines of code MAX for a service; sizes of teams; etc.
As an Architect your main functions are, build the team and help and coach people to take ownership, ensure the vision and strategic goals are being executed, teach and coach how to do it opposed to do it yourself which ties in nicely with ownership.
Good practice is to also do a bit of coding with the teams opposed to just do meetings.
This will ensure you are spending time with the teams and aware of the progresses but also verify how well the principles and practices are practical and helping (or not) your teams allowing you to further change in the good of everyone.
There will be some trade offs which you have to be aware, with such a distributed architecture monitoring is a challenge to pinpoint issues and performance bottlenecks, this requires different skills and solutions since alerts can be an effect but not the cause build Continuous Improvement into your monitoring systems.
Interfaces are a great idea to save time but can create unwanted dependencies un-welcomed when you are building services which you want to decouple so control that integration and look for the tradeoffs.
Technical debt will happen and sometimes a team owning a service can find itself without the knowledge to handle the service when team members shift so watch out for this with a log or other preferred model.
A possible solution is to uniform the stack and create your own development on top of that stack, great if you are open sourcing your teams work which ties in nicely with excellence because it’s now public too.
Governance is crucial (yes you have to) keep documentation in a useful state and create a service template to ensure you make everyones life easier, has with everything this is important and relevant with what everyone believes to be the best principles.
Key point to mention, with many things and Governance specially it’s good to have your Architecture Board working with, the sum of knowledge is wiser than one.
With the board we can better understand Priorities; Direction; Needs (business/teams/skills); Conditions and Options which allow to better decision making, a more cohesive performance monitoring of the teams work and business success and progress specially if we are talking of large change etc.
I want to end with one note which is crucial and sometimes put as secondary from my experience.
Were there are trade offs there are limits.
One such which is pivotal to your success is the happiness of your teams, don’t loose sight of why you are doing this transformation and the business is nothing more than the reflection of an organisation and the people which make that same organisation, talent is hard to find attract and maintain if you don’t have a clear vision for it and you don’t want to end up with a Ferrari without parts or mechanics to keep it FAST!!!
