Microservices: Renaissance of the Architect
Microservices: Renaissance of the Architect
Let's look at the changes microservices have caused in architecture, the role of the architect, and in organizations as a whole.
Join the DZone community and get the full member experience.Join For Free
Learn the Benefits and Principles of Microservices Architecture for the Enterprise
Microservices architectures have brought their share of new patterns and organizational questioning of projects. Since Sam Newman's book "Building Microservices" was published in 2015, much has been said and done. I thought it would be interesting to list a few points of influence that microservices might have had on the way people do architecture, as well as sharing my opinions with you.
New Patterns and New Ways of Doing Things
A number of patterns and practices have emerged or become popular with the rise of micro-services. Circuit Breaker, Saga, CQRS, and others. You can see a nice list on microservices.io site in case I forgot one. We can thus thank this architecture for having created, shaped, and popularized these "good" ways of doing things.
We can also thank it for having helped to popularize Domain Driven Design, allowing us to put developers and business analysts at the same table.
By decoupling the code very strongly, microservices have made it possible to push the capacity of an architecture to evolve even more than before. Indeed, by cutting the services so finely, it is possible to modify a backend without breaking everything, and this allowed us to think about going further. This pushed us to switch from the "Design to Build" logic to the "Design to change" logic. Indeed, in the rapidly changing world in which we find ourselves, wanting to frame and manage everything is no longer possible. This logic is very different from the previous logic of the "whipping father" architect that the projects may have felt. The architect's posture is no longer to say what to do, but rather to say how to do it. From the architect "Command and Control," we move on to the architect "Leader," in the sense that he pushes people to do the best they can, rather than ordering them to do it. This leads to new modes of governance.
Governance, Decentralization, and Coaching
As the architect's posture changed, so did his role and place. What I particularly like, at the moment, is to see the reactions of the projects and my clients when I tell them that I put myself in an Architect Coach posture. It feels like a revelation and relief to them that an architect "sells" this posture to them. This strengthens my convictions, but it also redefines the associated mode of governance. The architect is no longer in his ivory tower, but is seen as a companion and facilitator. It is then the projects that make and appropriate their architectures (and really put them in place), the architect being there only to deliver the projects. In a certain way, the architect must be the Socrates who gives birth to the projects of their architecture.
Of course, it remains the architect's role to state the "forbidden," but rather than saying "That's what you have to do," he says "What should you do? And should we do it now?"
What Remains to Change, According to Me
Microservices architectures have made a significant contribution to project architecture, but I really believe that it's a bottom-up force that will go all the way up to the company architects.
In my opinion, two things remain to be changed in this area. Since I was talking about infusing architecture into projects, I wanted to see if there were EA tools that could be easily shared with everyone. For ease of reference, I looked at the latest analysis from 2017 of a well-known large analyst firm. All publishers remarked that their tools were complicated to use, including for EA experts. For me, the enterprise architecture should be shared to all via tools manipulable without real training. Define an architecture, a process, and KPIs; all this should be easy to define. For the moment, this is clearly not the case, and we find ourselves choosing between a complex tool or Excel and Powerpoint.
The other point that I think needs to be changed is the place of the enterprise architect in an organization. How can the Executive Committee make decisions without consulting an architect who knows the company? "Let's do a great digital transformation project in six months!" And I'm hardly exaggerating what I've heard. In antiquity, the architect was in direct contact with decision-makers and defined architecture, hired the right people to do the right job, and supervised the quality of the work. Without taking the place of a project manager, the architect must, in my opinion, be listened to much more by decision-makers.
As we can see, architecture has evolved well under the impetus of microservices, among other things, but also of the various changes experienced by our profession. Let us not forget that the architecture of buildings is a multi-millennial subject. Computer architecture doesn't have a century. The path to full maturity is still long, but so exciting! What changes do you see coming?
Opinions expressed by DZone contributors are their own.