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
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,
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:
....tasks must completely succeed or completely fail
....changing one component does not
affect the other component)
....components may be opened for extension, but closed for
....high-level components should
not depend on low-level components
ConclusionSoftware 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.Gordon BlackwellTechnology & Entrepreneurial EvangelistRaleigh, NC"Some see things and ask Why... I dream and ask Why Not..."Author Unknown
Sign In or Register to comment.