Software Engineering

Software architectural approaches
Every architecture can be viewed as a series of progressively detailed descriptions 
of the software product. The layers of the architecture provide a means of compart-
mentalizing aspects of the overall problem/solution space. This concept has been 
described as peeling the onion, in which a layer of the architecture is considered 
before diving below the surface to the next layer of detail. This provides a reasona-
ble approach for describing the resulting architecture to stakeholders by introducing 
them to the architectural solution incrementally. For example, a book is composed of 

---

117
Developing the software product architecture
chapters; chapters are comprised of sections; sections are comprised of paragraphs; 
paragraphs are comprised of sentences; and sentences are constructed from words. 
The book is meant to tell a story with each chapter providing a basis for the follow-
on chapter in which the story progresses toward its conclusion. Reading ahead to see 
how the story ends causes readers to miss many of the valuable aspects of the tale 
that are intended to make the story more complete, satisfying, and enduring.
Developing a software architecture establishes a structural foundation for the soft-
ware product. Every element of the architecture fulfills a purpose and its reason for 
existing defensible; otherwise, it should not be included in the solution. The purpose 
for each element of the structural configuration or physical architecture must be trace-
able to an element of the functional architecture, a specified software requirement, 
and a stakeholder need. However, this does not mandate that the architectural solution 
be devised in a layered approach. Additionally, if the software architecture is permit-
ted to evolve incrementally or iteratively, the stability and durability of the software 
architecture may erode over time as new features or enhancements are incorporated. 
Therefore, the initial software architecture must be derived in a manner that accom-
modates the software requirements intended for the first release of the software prod-
uct while establishing the foundation for product evolution and future extensions.
It may be prudent to adopt an architectural development strategy that is driven 
by critical-path or risk-reduction analysis. Critical-path analysis recognizes that the 
software product must be designed to enable one or more essential or crucial data 
processing operations. This approach establishes the data processing scenarios, 
behaviors, and structural elements necessary to enable the most important data pro-
cessing objectives. The secondary or less important data processing objectives are 
then integrated into the architectural configuration in a manner that is most effi-
cient, effective, and pragmatic. Risk-reduction analysis focuses the establishment of 
an architectural configuration around the data processing operations that resolve the 
most challenging aspects of the solution. This provides an initial emphasis on tackling 
the most difficult and precarious design endeavors to establish a feasible technical 
solution. The remainder of the functional and structural elements can then be inte-
grated into the architectural configuration in a manner that is efficient, effective, and 
pragmatic. Both of these approaches explore a limited architectural solution in depth 
to establish an underlying architectural framework for the entire software product.