Architectural Style

Architectural style has emerged as a common means for specifying the highest-level principles underlying the organization of software systems.  It was developed at Carnegie Mellon by Mary Shaw and David Garlan and appeared in the book titled “Software Architecture: Perspectives on an Emerging Discipline.” (ref.)  An architectural style defines systems in terms of a pattern of structural organization.  More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined.  Examples of architectural styles are:

• Blackboard
• Client–server model (2-tier, n-tier, cloud)
• Database-centric
• Distributed computing
• Event-driven architecture (Implicit invocation)
• Front end and back end
• Monolithic application
• Peer-to-peer
• Pipes and filters
• Plug-in
• Representational State Transfer
• Rule evaluation
• Search-oriented architecture
• Service-oriented architecture
• Shared nothing architecture
• Software componentry
• Space based architecture
• Structured (Module-based)
• Three-tier model

Architectural styles differ in how componentization is implemented.  In defining your style there should be absolutely no ambiguity on these points:

• Identity - how a component (or object) is identified and referenced
• Behavior - how a component supports a well-defined behavior and provides an interface to it
• Realization - how a component comes to exist and maintain its behavior and identity

Care must be taken to select an architectural style that best supports an application’s non-functional requirements.  A style should not be selected because it is the current favorite buzzword.  For example, Service Oriented Architecture (SOA) using WS-* technologies is good for open loosely-coupled integration to external companies using short-term small-packed request/response interactions but is poor for an embedded integrated set of applications that run within a company. 

An application should apply a style consistently throughout but may in some cases be muddied due to a need to interface to system that uses another style (e.g. a C/S system that needs to interface a MOM system).  The large-scale structure and fine-structure style may have differing styles.  All these situations should be clearly identified.

Considerable research into the alternatives should go into the choice of an application’s architectural style as it is the most important decision in regard to the design of the system.  A clear statement should be made defining the overall architectural style that is to be applied to the system along with the supporting rationale.  An example of this would be:

The large-scale structure of the system is built on stateless components, oriented around a uni-directional dataflow paradigm, on top of an asynchronous publish/subscribe message infrastructure using queues at the publish site, not a central hub.  Each component is loaded at system startup and remains in existence till system drain & shutdown.  An operations management component shall monitor the state & workload of each component and will take appropriate automated action as needed or escalate to an operator.  At the same time, the fine-scale structure of the system is based on an object-oriented language with code that employs inheritance, abstract classes, interfaces, object references, and design patterns.