The Importance of Software Architecture

Many developers begin developing by unknowingly using the concept of Separation of Concerns (SoC).  They dedicate their time to develop software by designing and developing features (concepts) with as little overlap of functionality as possible. This approach is how I once programmed when I was a developer.  It provides instant gratification.  Unfortunately, this methodology succeeds for only very trivial applications.  The approach is completely inappropriate for large-scale or enterprise-level solutions.

 

The Purpose of Software

The purpose of a software application is driven enviably by the developing organization.  The goals are generally driven with commercial requirements and the ultimate solution must deliver an acceptable ROI.  In most cases, the system’s future return must be promoted to gain buy-in before any investment is allocated.  And in many situations, the architectural design must be leveraged to demonstrate the value and viability of the future system. 

 

The Value of Architecture

I parallel the need for software architecture with the construction of a physical structure –specifically…  I like to relate every system I design as a Tree House, a Home, or a Skyscraper.

 The Tree House Architecture…  As a father of 2 children, I enjoyed the assembly of a multi-level, tree house.  I simply fastened boards repeatedly using a level as needed to ensure horizontal floors and vertical walls.  The effort never required pencil, paper, or really much thought.  Similarly, I have developed applications with the same approach –no advance design, just coding.  Unfortunately, the demand for some of these applications exceeded my expectations and brewed into the inevitable catastrophe.

 The Home…  While it might be possible to create a home with no plans or design, every family appreciates the architecture of a well designed house.  The general contractor must properly lay a stable foundation while considering all components of the house like plumbing, electrical, rooms and walls.  The GC must also allow some flexibility for the homeowner to acclimate their living conditions within the structure.  For example, while the home’s design must predetermine the location of the kitchen, the homeowner has the opportunity to select the appliances and the exact location of the kitchen table.  When designing the kitchen, the architect must enforce enough structure to enable reliable functionality (the proper operation of the oven and dishwasher) while offering the future owner to determine where they want to place the silverware.

 The Skyscraper…  An enormous building relates directly to the enterprise application, demanding considerable design prior to digging the first shovel of dirt.  An architect must respect abstract concepts like the mission and vision; consider al needs, desires, and demands from all relevant stakeholders; encompass all functional requirements; and design to achieve all quality attributes, like scalability, responsiveness, real-time availability, maintainability and/or reliability (often referred to as the ‘-ilities’).  Understanding and achieving the appropriate architecture demands a substantial effort, a focused team, and dedication from all stakeholders.

 

Listening Is Key

The architect must begin by considering a diverse pool of concerns from all stakeholders (users, developers, management, investors, customers, etc).  It is during this initial gathering of information that often forms fundamental flaws in a system.  By neglecting the insights from a key individual, the architect may fail to incorporate a core attribute for the end solution.  Although many circumstances may contribute to design flaws, I believe that the primary issue that surrounds the inability to actively listen to others.  People naturally want to explain their thoughts to support their intentions.  But, this is not the activity for the architect at this phase.  A related problem is the inability for the architect to communicate his or her intentions. –But, we’ll save that issue for a later discussion.

 

What is Software Architecture

At its core, software architecture is a compiled distillation of needs and expectations from all stakeholders.  From its definition, we can recognize that the architecture of a software application will never be flawless.  This is because software always evolves.  While software continues to be used, it is never complete.  Why is software never complete???  Because stakeholders (anyone who is affected by the software) will change their minds, some stakeholders will depart while others will join (Yikes… even after the system is released).  So how do we shoot a moving target?

 

Shooting a Moving Target

There are 3 tools that I use to enable sound system architecture: Pillars, Design Patterns, and Modeling Criteria.  At the most abstract level, an architect should incorporate a set of Pillars throughout the entire system’s design.  A pillar (by my definition) is a central, foundational, abstracted concept that supports the operation and reinforces the mission of the system.  Because each pillar sustains crucial functional support, a pillar can never be removed.  For example, during the discovery of stakeholder’s needs, the system architect may uncover that the solution must allow for a customizable, role-based security model and all actions must be logged and comply with FDA regulations.  The concepts would be 2 pillars of the new system.  Pillars should be documented in concise, understandable terms and leveraged as a litmus test against every designed task.

The concept of a design pattern involves a common reusable resolution to a commonly occurring problem. The concept and use of design patterns has gained popularity and for good reason.  Design patterns speeds development, increases quality, and lessens maintenance efforts by improving readability for programmers who are familiar with the repeated pattern.  Because this concept is well documented, I will not dig into the details relating to the various patterns.

 The final concept that must be incorporated to deliver a robust, scalable and reliable solution involves modeling criteria which must be pre-determined, documented and applied consistently within all designs and code at its lowest level.  Modeling criteria supports the key aspects surrounding quality assurance which facilitates “Fit for Purpose” and “Right First Time.”  Examples of modeling criteria that I often apply include:

Atomic Components (tasks must completely succeed or completely fail)

Loose Coupling (changing one component does not affect the other component)

Open/Closed Principle (components may be opened for extension, but closed for modification)

Dependency Inversion (high-level components should not depend on low-level components)

 

Conclusion

Software will constantly evolve throughout its entire life.  Do not attempt to stop the evolution. Rather record key principles surrounding the project to architect the best solution.  As a final remark, I relate software architecture with the design of an airplane.  The wings of a plane maintain sufficient structure to lift the craft into the air.  At the same time, the wings are designed to flex 22 degrees up and 18 degrees down to prevent a total failure during turbulent conditions, protecting not only the craft, but also all stakeholders. Architects must understand and address all discoverable needs while incorporating a fine balance between structure (for functionality) and flexibility (for customization & user acceptance).  By applying Pillars, Design Patterns, and Modeling Criteria, an architect can achieve a proper design to deliver a scalable, maintainable, and reliable system.