Modernizing Enterprise Software Applications: Enabling Architectural Direction (part 3 of 7)
Organizations are challenged to change and maintain applications that were built in the era of client-side application development governed by the desktop when centralized, multi-tier architectures were used to create entire applications on a single codebase. Meanwhile, customers and businesses seek the benefits from modern architectural trends such as containerization and cloud-based solutions, microservices and multi-tenant capabilities. With the additional expectation of improvements in user experience, legacy applications translate to impediments to effective modern development.
Challenges
A technical benefit pointed to by proponents of microservice architectures is avoiding the build-up of unconstrained complexity in such codebases. Enterprise codebases therefore often exist at the most challenging intersection: they have been built in a fashion that tends to more code complexity over time, and they have often been in development over a timescale where that complexity has had time to proliferate.
A monolithic application structure that is well matured can be an extremely good candidate for developing into microservices; its functional boundaries are understood, its business scenarios well refined, and so the hard delineations between services should be relatively easy to identify with success. Microservice architectures require these boundaries to be well understood as later changes to them present potentially larger hurdles than in a monolithic codebase.
At the same time, monolithic and legacy codebases often have baggage from the perspective of a modern microservice architecture. There may or may not already be well structured (if any) RESTful APIs. The APIs of an application can be thought of as the inventory of what a codebase is responsible for, and having these well understood can make it easier to reason about the ideal divisions of those responsibilities. If the front end is coupled with the back end and not represented through RESTful endpoints (or if the endpoints which do exist don’t allow for service division), this becomes another challenge for modernization.
Legacy code frameworks, or code spanning many different technologies, can also pose a technical challenge to host as part of a modern architecture, especially if they mandate concessions in messaging technologies or reliance on dependencies that limit hosting options.
Statistical Trends and Facts
Top challenges organizations expect to face include lack of visibility into end-to-end business processes that span multiple microservices (59%), error handling issues at the boundary of two or more microservices (50%) and communication between teams (46%) (Source: DZone).
The global cloud microservices market will grow at a rate of 22.5 percent, with the U.S. market projected to maintain a growth rate of 27.4 percent (Source: ResearchandMarkets 2019).
Nearly two-thirds of the organizations surveyed (63%) are building some (18%) or all (46%) of their applications using microservices (Source: DZone).
An additional quarter of organizations (28%) are considering using microservices for future applications (Source: DZone).
Of the dozens of Java frameworks which have competed for popularity, Spring has emerged as having >50% usage, with others in single figures. (Source: JetBrains).
Angular has had 5 major revisions, beginning with v4, between 2017 and 2019.
Key Questions to Consider in Your Current Architecture
No two complex solutions are identical. Solutions and businesses both have intricate histories, which intertwine on their journey to their present state, for better or worse. Every enterprise engineering organization puts serious thinking into ways they might navigate technical challenges and become more efficient. Finding a documented, understood and agreed-upon strategy is often challenging, and much of it may be passed as an unwritten culture between individual contributors rather than a roadmap between departments.
Business stakeholder interest in modernization is driven by a clearly visible link between proposed technical change and missed or thwarted business outcomes, past and future.
Practical nuances drive the implementation of modernization. For example, while it often provides possibilities for performance improvements, a heavily optimized specific solution may need thinking through more thoroughly if that solution relies on something holding back the rest of the codebase.
Key questions to consider as you consider modernizing your applications include:
How well understood is the need for modernization?
What drives technology modernization priorities in the enterprise?
To what extent does lack of modernization hurt development efforts?
What are best practices to retain and attract the right team and partners?
Outside of third party libraries and frameworks, how far does the architecture and code of your own solution hamper efforts?
Is your solution tested and testable?
Is the codebase organized, coherent and documented?
Is there an organizational agreement on what good will look like, or are there competing narratives that need to be resolved?
Is there good separation of concerns, between architectural layers but especially between the front end and back end?
If the front-end will require re-work, is there a coherence to design currently? Is there a documented design system in place (even if not yet adhered to)?
If you have started moving to microservices, are you incurring technical debt in the process? Do the boundaries drawn between the services still seem the right choices?
Can all developers and decision makers find answers to technical questions in architectural documentation?
How optimized (or over-optimized) is the current solution for performance?