October 2nd, 2018

Solving What’s Off About Monolithic Applications

Developer Support
Cloud Solution Architects

In this post, App Dev Manager Mark Eisenberg speaks about the resistance to change which is one of the main reasons we see organizations battling with monolithic applications.


Previously in this space, I laid out the case for why we are still trying to solve the challenges of monolithic applications. In short, we are resistant to change and without change there can be no improvement.

Effecting change is hard and is a process. Our natural tendency is to drift towards what we know because that is where we are comfortable. Strong leadership is the most important factor in successful change. The beginning will be consensus building, but strong leaders will be required to keep the group moving in the right direction. Groups won’t self-organize in a new direction.

First, a series of questions have to be answered. The answers need to be factual. Regardless of the answer, it has to be explainable with facts, not opinions.

Applied specifically to the challenge of monolithic applications, here’s the list:

Do we need change?

This seems obvious, but in the real-world it is not. Monolithic applications are not necessarily wrong. They are easier to build and if their lifetime or scope do not require the agility offered by newer techniques then perhaps change is not required. Answering this question brings clarity to the overall goals of the change effort.

What change is needed?

This question is the most fun to answer, but is also the most frustrating. There are many options and opinions. But one factor is very clear. ‘Everyone is doing X’ is not a useful decision criteria. If the team decides that a microservice approach is the correct approach there must be clear reasons that can be explained in non-technical language why that decision was made.

Do we understand the change?

This one is hard. It has become acceptable to make unsubstantiated statements as facts. A well known example is the widespread use of the statement “everyone has their definition of the cloud”. Setting aside the semantic nonsense of the statement, how can a group effect change if everyone has their own definition of that change. It is critical for the team to fully understand that nature of the effort.

Do we understand the risks?

Risk analysis is key as it makes the team aware of its discomfort with the change. Confronting the risks and owning them gives the team confidence to face the challenges.

Do we have the right people?

It’s all about the people. The resistance to change is human nature. Leaders and team members alike. Assessing the team is simple. If they can demonstrate an openness to changing how they do things you are on track. If team conversations consist of why things must continue to be done the way they are being done success will be a challenge. But leadership is the real key. Effective change is a collaborative process and management’s primary team facing role is keeping the team within the agreed upon boundaries. But of equal importance is securing and managing executive sponsorship. The team is pushing hard against their own instincts for the betterment of the organization. The organization must support them and insulate them from organizational winds that look to disrupt their efforts.

The answers to these questions will tell you in advance whether you can succeed. Remember, it is reasonable to conclude that you don’t need change. However, if you conclude that you do NEED change, but you CANNOT change that is a problem. But if you conclude that you NEED change and you CAN change, make sure you change. Don’t make it change in name only. Change without change is not change at all.

Author

Developer Support
Cloud Solution Architects

Microsoft Developer Support helps software developers rapidly build and deploy quality applications for Microsoft platforms.

0 comments

Discussion are closed.