February 5, 2020
Software Architecture: The What and Why
What is Software Architecture?
As it is rapidly changing and evolving there has been much focus on “software architecture.” A search on the term will return widely varying descriptions, all attempting to clearly define it in the context of information management.
It is more instructive to go back to the root metaphor involved.
When most people think of “architecture” they picture someone sitting at a large slanted table drawing highly detailed illustrations with very precise measurements that specify how all the components of a building go together. Many would associate this drawing function as more of a design process, yet dictionary definitions of the word “architecture” barely mention design and instead focus on the action or process of building and construction. Used as a verb, to “architect” is to plan, organize, or structure.
These definitions are directly applicable to the process of building software.
Building Software; From Design to Construction
While some software tools, or applications, are built to perform a single job such as word processing or spreadsheet development, even these have a myriad of tasks and functions that work together to enable and facilitate their use. Larger software systems, such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and bespoke systems designed specifically for the operation of a particular company are comprised of many parts, each of which supports a specific operational function.
When designing either single-purpose productivity tools or broad operational platform systems, each of the different functions involved must be carefully defined in terms of purpose, operation, workflows, and outcomes. The relationships between each function to all others must also be defined including how and what information will be passed from one to another, quality checked, and used by each segment or module.
This directly parallels the classic construction model for architecture. The architect first discovers the purpose and functionality desired by the client for the new structure. They then define all the physical elements of the building and define how they fit together in relation to each other. How will people and things move through the structure and up and down the building? Instead of workflows, they illustrate how water, gas, electricity, telephone, internet, and more flow through the building and are distributed among the various rooms and facilities.
The Metaphor of the Monolith
Buildings are designed by architects to last. While there may be renovations at some time in the future, the intent is to describe, define, and design a structure that will last. In the context of software architecture, this approach has recently been referred to as monolithic. A monolith has a uniform, massive, inflexible character to it. The building and the software are designed to serve for a long time, often without change.
Traditional “monolithic” software is architected and then coded and built to run as one large platform. Most software developers provide updates and improvements to these on a regular basis. Sometimes these updates are meant to add new functionality, others resolve issues and problems, others improve security or other important utilities that serve the overall application. The interval between updates can be months at a time, even years depending on the application.
Two fundamental characteristics of the monolithic software architecture should be observed. One is that the entire application is updated or upgraded when the time comes.
The other is that if the upgrade fails, the entire application usually malfunctions ceasing all operation and all use. This is often referred to as a “crash.”
A New Approach to Software Architecture
Over the past several years it has become increasingly obvious that software needs to be more responsive to the needs of users. Since environments and other variables change so frequently it is no longer practical to anticipate that the original architecture of an application will remain unchanged for long. In fact, some companies are now using a new approach, Continuous Architecture, to achieve constant improvement of the software through constant development and constant deployment. The architecture of applications has become interactive and totally responsive to constantly changing requirements and constant discovery of new opportunities.
Supported by the joining of the software development team and the IT operations team into a DevOps environment, the workflow is simple to express in its most fundamental form. The foundational architecture is coded by development and deployed by operations. Operations then rapidly collects feedback from the users which is conveyed back to development who use it to inform the next round of improvements to the code. Once tested and approved the new code is then deployed by operations and the cycle begins again. And again.
In extreme examples, some companies are now delivering software updates several times each day.
Software Architecture is Continuously Evolving
In the context of building construction, architecture is viewed as the first thing that must be completed before anything else can be commenced. The construction crew needs the plans developed by the architect before they can pour a foundation, start building the frame, or do anything else.
In the context of coding, there are really two different architectures involved.
The first is similar to the construction metaphor in that the underlying structure of the system must be delineated before any other work can commence.
The second, however, never really ends. This is the ongoing architectural activity that rapidly and continuously provides highly frequent improvements to the original code. These changes must align with the overall architectural plan to fulfill the functional specifications of the system. They respond to the fact that software must be elastic, constantly responding to changes in the business and its markets.
