A redesign of an existing large application always causes a big impact on an organization. Not only the IT department will have to adapt change, but the business will be impacted as well. Even when the change is requested by the business, it will not be accepted more smoothly and there will be resistance anyhow.
Therefore, any redesign of a monolithic application must always be approached carefully and well overthought. Take time to decide the evolution, take time to introduce the change and to let it absorb by the organization so that the evolution will be embraced by the whole organization.
When the monolithic application has grown into one of the pillars of an organization, it will be challenging to introduce change as the impact will be anywhere on every internal team business, IT, and possibly external stakeholders will be confronted with it as well. The guidelines in this blog are based on such a pillar of an application and the efforts to introduce the evolution, taken into account the sensitive nature and the dependencies all around the enterprise.
Align the approach for architecture evolution to the nature of the organization
If the organization is very technical driven, keep in mind to speak the same language as the developers. Explain the benefits of the language they understand.
An organization must be prepared for change, it must be shaped and teased to start accepting new ideas. It’s necessary to be open to other concepts, think more out of the box and to look outside of the company. This way, you’ll be able to accept new modern principles, learn to live in the future and learn to challenge modern technologies. It’s important to analyze new methodologies and be more open in general for new things.
This can be organized in different ways e.g. participate in events, trigger people to present findings on new concepts, challenge ideas with external knowledgeable people, listen to experiences from other companies who have been in transition, etc.
Open up discussions and spread the word on new concepts or methodologies
In an organization, there are always some key persons who are respected for what they have achieved in the past, and for their knowledge and initiatives. These are typically strong-minded people with a very good in-depth knowledge of the applications. Therefore, they are easily considered as leaders. Those people must be identified and involved strongly in defining the next evolution. They will be key to accept change, and once they are convinced of the right changes and a good evolution, a change will be accepted more easily by the organization itself. Everything is based on trust; if a trusted person is all right with the evolution, it must be good and beneficial for the whole organization. Boundaries become blurred and the road to renewal is paved.
Identify the key persons that will support the evolution and evangelize the change
The people and the culture of an organization will set the pace of change. It’s very difficult trying to force it and to speed things up. Every type of culture has its pace and an organization can have different speeds over different departments. IT management can indicate that a new architecture is necessary for the future, but the business side does not see a direct advantage. It does only see the costs, not the short-time added value. Also, the development teams are not convinced that another solution could be an improvement over what has been conceived years ago. They will tell that everything is running fine, the way it is today.
Alignment across departments and roles can speed up the acceptance of change
Each organization’s culture defines an evolution of its architecture
Each organization has its specifics in different areas. Those specifics contribute to a determinative factor in accepting change for an evolution of the architecture of existing applications.
An IT organization can be driven by a developer mindset who has a big interest in open source. This typically leads to a culture in which developers have the power, and in which software creation is a very important factor. The developers have the power to build what they propose as the solution for the requirements, based on what is already in use in-house. Architecture practice is typically not that strong in this culture and most cases, architecture decisions are taken by lead developers, based on a profound technical perspective. The danger here lies in the fact that delivering software artefact is the most important thing and it might be used as KPI for management to verify the performance of the IT organization. Furthermore, it might be used for accountability towards the business too.
Although delivering software artefact is the most important aspect, it will not only be difficult to build a vision, but it will also take the necessary time to define the next evolution in the architecture, introduce change and make it happen. It will disturb the hardened daily routines, such as technical design, development effort, work break down, sprint planning, testing, releasing, etc.
Concrete business needs that affect the future
Introducing change for the sake of changing something specific, will always fail in the long run. Change always comes with a large investment over several years and with an intrusive impact on the entire organization. For that reason, it should be supported enterprise-wide and for the right purpose.
Surfing on all IT waves will not be accepted as a good reason, as IT must support business and they should find solutions for what the business wants, not the other way around. Business can be triggered by IT to think about new channels and new ways to perform the business. But at the end of the day, the business will decide the budget and the investments that can be made by IT.
Following all trends is not realistic for most business, as it typically applies to specific industries and popular use-cases, which don’t apply to a lot of common scenarios for internal business processes.
IT drivers alone are not strong enough to start a major evolution. They are a response to business needs, and business will not accept them as they cannot be mapped directly to real business concerns. IT exists because it has to facilitate the business with their needs, not the other way around. Defining the business needs would be the first step but deciding the IT drivers is also an important additional step. Both steps form the baseline to define the evolution of architecture.
- Without clear business needs, it will be difficult to persuade the organization to go along with the evolution of architecture, to define the future;
- Without clear business needs, it will be difficult to persuade the organization to provide a budget for a large investment, to realize the future.
Support from the business is key
The support from the business is a crucial element for success over the years. Business alignment has to be acknowledged and supported continuously. For difficult decisions with high impact on the organization, the responsibilities will move up to higher management and C-level decision making persons. In each transformation at some point, critical decisions must be made to continue with the evolution. These can not only be made by IT but need to be backed up by the business.
With clearly identified business needs, it is more convenient to convince the business to embrace evolution and to support the process of change.
- Without support from the business, decisions will not have any weight and will not be carried by the organization;
- Without support from the business, important decisions will be stalled, as responsibility will not be carried.
IT requirements trigger new concepts in the architecture evolution
Every monolithic application has technical debt, even the ones that have been created with strong quality assurance procedures and architecture governance validations. The level of technical debt in a monolithic application is a parameter to identify the risk of quitting the evolution, which indicates the urgency of change. It’s one of the parameters in detecting a burning software platform. When we have to deal with a burning platform, the foundations must be tackled as soon as possible; there is absolutely no time for a delay. For a non-burning platform, we have the option to focus on the boundaries of the application first (exposure of data and functionalities). So, we could provide a solution for the business needs, and in a later stage even tackle the foundations.
- Know the state of your monolithic application for defining the architecture evolution approach.
The to-be architecture is the transition architecture for the next to-be architecture
When the required change could not be defined as drastic, the to-be architecture is just an evolution. It does not cause a complete shift to other principles, but the to-be architecture can be considered as a transition architecture to something else. Meaning that level of evolution is all right and in line with the use case. Another evolution will have to be considered in the next phase, after several years. It may not be the focus at this time.
Take it step by step, avoid a big bang evolution and prefer an iterative evolution in architecture, as it will be more controllable and gradually proved by the organization. Gradually the new foundation will be established, and it will be a more natural process to accept change step by step.
In the example we mentioned above, we will focus on the integration aspect first. By exposing data we’ll form insights around the concepts of distributed computing, abstraction with interfaces, functional decoupling before tackling the application architecture renewal.
- Transition step by step towards a to-be architecture by simplifying change into smaller incremental evolutions.
Backup evolution of architecture with rationale
A new architecture is nice, though, it takes time to decide all the individual components that are required. This is the result of a process in which many people are involved, in which a lot of discussions did happen, and in which a lot of decisions were made. It’s really important to keep a record of the decisions that were taken, and especially why they were made. This in order to explain the underlying rationale. An important part of the process is the alignment among the people that are involved in the decision of the new architecture. We have to make sure that everyone has the same interpretation on all the aspects of the new architecture. We must avoid at all costs, that practical implementations are making wrong architectural choices, and that projects deviate from standard solution patterns. So, we need to describe the architecture evolution as a reference for architects and projects, to build software components, according to the new way.
- The rationale must be formalized in the form of architectural decisions and positioning of architecture choices;
- A good way is to describe the evolution in a reference architecture.
Create the right time yourself
There is no way to know in advance when will be the right time to start executing. A lot of aspects have to fall into place at the same time. Several important aspects have been discussed in this blog and all these aspects need to be tackled to evolve into a state in which they can be interpreted as “the right time”. An organization must arrange “the right time” by composing a momentum and by working towards a milestone. Sometimes it takes multiple efforts to get to the right moment. That’s not necessarily a bad thing; it means that one or multiple aspects were not completely ready yet. As long as we keep learning from this experience (reasons for resistance) and keep adapting things in the right direction for the next approach, by re-aligning the focus on the concrete organization concerns.
- Building up momentum to speed up for the right time by preparing an organization for evolution;
- The time is right when all the aforesaid factors are in a state to accept change and evolution.
Choose your battle wisely and be selective
When the time is right, it means that the realization of the new architecture can begin. But we are not there yet! The blueprint has been made but we need to learn how to read the plans, how to interpret the concepts and how to build what we need. So, now is the time to prove the new architecture in real-life, during a full software development cycle, to convince the rest of the organization of the benefits of the new concepts. It’s very important to have success on the first projects. This way, you’ll gain credibility and trust. The selection of the first projects is very important, as we need to build up the success in order to continue with the evolution. This way, it can be spread out over the entire enterprise.
“Choose your battle” means that you have to be selective in the problems, arguments, and confrontations in which you get involved. Instead of fighting every problem, you can save time for the things that matter. This means that you have to fight only the most important battles and that you have to let go of the rest.
Find yourself a project that is not complex so it can be realized in a couple of months. You have to find something that will be accepted by the enterprise and that has a clear benefit for everyone who will be involved. For the organization itself, it’s important that it has to be realized in isolation and that it will not impose drastic changes in the organization yet. It has to prove an important aspect of the new architecture.
- Not everything is important, focus on the big important things;
- Every battle takes time, make the best use of the available time.
Conclusion:
Always look forward; the concerns of today will be the problem or constraint of tomorrow. Try to understand the concerns correctly, in order to know if they will become important. Start acting on the important ones today.
Please share your insights or feedback on the elements we talked about in this blog (and in our previous ones of course)!
Some more integration blogs for you
ALWAYS LOOKING FORWARD TO CONNECTING WITH YOU!
We’ll be happy to get to know you.
