Natural Alignments of Styles and Methods
This is the last post in a brief series on how applications are developed, with a focus on development methods and architectural styles. There’s a natural alignment between certain methods and styles—an alignment that can be found between waterfall and monolithic applications, along with agile and microservices. These are just two examples. I explore these examples of natural alignment in this final post of the series.
Waterfall and Monolithic Applications
The waterfall method and the monolithic application were, and may still be for many companies a natural pairing.
Why did waterfall become the method of choice in the early days of computing? The waterfall development model originates from the manufacturing and construction industries. Both are highly structured physical environments in which after-the-fact changes are extremely costly, sometimes impossible. Because the waterfall method was developed in a time before no formal software development methodologies existed, this hardware-oriented model was adapted for software development. In 1985, this method was even adopted as a formal requirement by the Department of Defense.
What exactly is a monolithic application? Consider this from TechTarget.com: “A monolithic architecture is the traditional unified model for the design of a software program. Monolithic, in this context, means composed all in one piece. Monolithic software is designed to be self-contained; components of the program are interconnected and interdependent rather than loosely coupled, as is the case with modular software programs. In a tightly coupled architecture, each component and its associated components must be present in order for code to be executed or compiled.”
History is the past, what about the present? Is this pairing still used? The answer is yes. Why? There are, of course, many reasons. Consider the company that uses this pairing because the people have confidence in the method and commitment to the monolithic application as it aligns with their long-standing software and hardware investment, which supports their high transaction volumes. There are many examples like this, however other companies that have been driven to seek new ways due to competition and technology changes.
Agile and Microservices
In many ways, agile methods (there are more than one) are a reaction to waterfall. Agile has the goal of more rapid change and it comes with tactics like scrum project management, which has a goal of delivering new software capabilities in 2 to 4 weeks. The need for speed comes from the fast pace of business in many industries. It is also driven by the basic human need to make things better, change, improve, save time and be more efficient.
Microservices, as well, are a reaction. They represent a refinement or an alternative to the approach offered by the service oriented architecture. The true nature of the microservices architectural style requires study. How small is micro? How do these small units coordinate and communicate when messaging is necessary? There’s a lot of software engineering when it comes to microservices.
Pairing agile with microservices is a natural combination, but both present challenges on their own, so combining them require an even more experienced and confident team. Prove it to yourself—follow the links in this post and then reflect on combining them. You will quickly see the challenge.
Where Do We Go From Here?
Because of IT’s long history and rate of change, new methods keep arriving and evolving as do ideas about what architectural style will create applications that can be easily maintained while performing well in the hands of clients. It’s great to have so many alternatives to consider for future applications.