The technology changes required when implementing a microservice-based application are only one part of the equation – the business and organisation will often have to fundamentally change. In an ideal world, this shouldn’t be a problem, what with the rise of agile, lean and DevOps, but in reality this is not always the situation. In this talk we will share some stories of successful (and not so successful) strategies and tactics that we have used when introducing microservices into a variety of organisations over the past four years.
Target Audience: Architects, Developers, Operators, Project Leaders
Prerequisites: Basic knowledge of SOA/microservices. Previous experience of working within IT projects is assumed
You will learn:
- Participants will learn about the organisational impact of microservices, and explore why early adopters have shaped their organisations to smaller cross-functional teams
- We’ll discuss how many technology problems are actually people problems is disguise, and suggest methods on how these can be resolved
- Finally, we’ll highlight the importance of applying lightweight change management processes (without the management doublespeak), and suggest reading and techniques that can help with this
Join us for a whistle-stop tour of the business and people challenges that we have experienced first hand when implementing greenfield microservice projects and also breaking down monoliths. We’ll look at ‘divided companies’ vs ‘connected companies’, determine the actual impact of conway's law, briefly touch on the lean startup/enterprise mindset, dive into change management without the management double-speak, and look at the lightweight processes needed to ensure the technical success of a microservices implementation (e.g. DevOps, CD).
The main lessons we're keen to share are from observations on a couple of microservice transformation projects we have been involved in - some where teams have been cross-functional and aligned around strategic objectives, and some where they haven't. The latter proved much more challenging, as we saw single domain models being created and shared around the codebase, unclear service/context boundaries, and ultimately people tripping over each other.