Refactoring the Architect's role:

The autonomy that comes with microservices is very attractive to our customers. Sometimes it starts to become a double-edged sword of sorts. They realize that the power of autonomy comes with a great responsibility for the development teams and the organization in general. The need for a technical ear that hears as many designs as possible arises. Traditionally, that leads to architectural oversight. Then they gather a bunch of senior engineers and call them architects. Things start to get worse because nobody can really figure out what the right level of oversight is. The group gets viewed as an “Ivory tower” that’s always busy in meetings when needed. Now, they have moved smart engineers from coding to meetings, anarchy is breeding and nobody is happy. What’s going on here? What can we do?

In this talk, we’ll take a look at how to break some traditional molds and modernize the architect’s role. I’ll take you through a journey to explore some principles, forged through practice from real-world projects. You’ll learn strategies for mentoring development teams, scaling processes, and maximizing efficiency. With the right structures in place, architects can guide teams into the “pit of success,” as Scott Guthrie likes to put it. Together, we’ll strike down the walls of the ivory tower and raise up a new group of evolutionary architects. We want to make sure architects are viewed as peers and not as 10xengineers.