Architectural Pattern
An Architectural Pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, and their responsibilities, and includes rules and guidelines for organizing the relationships between them.[1]
An architectural pattern is a concept that solves and delineates some essential cohesive elements of software architecture. Even though an architectural pattern conveys an image of a system, it is not architecture. It is a general, reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design patterns but have a broader scope. The architectural patterns address various issues in software engineering, such as computer hardware performance limitations, high availability, and minimization of business risk. Some architectural patterns have been implemented within software frameworks. Countless different architectures may implement the same pattern and share related characteristics. Patterns are often defined as "strictly described and commonly available".[2]
Figure 1. source: Towards Data Science
Architectural Pattern: Background[3]
"A key aspect of enterprise architecting is the reuse of knowledge. In most organizations today, the experience gained while doing a similar endeavor in the past is rarely utilized, or grossly underutilized while dealing with a need today. Through better utilization of experiences and knowledge from the past, one can obtain major strategic advantages." Pattern usage is an excellent way to reuse knowledge to address various problems. One of the reasons why "experience gained while doing a similar endeavor in the past is rarely utilized" is because problems and their solutions are not expressed in a form suitable for reuse. Patterns provide a form for expressing technical solutions in the context of business problems and capturing them as reusable corporate knowledge assets. In 1979, the (building) architect Christopher Alexander published The Timeless Way of Building, which describes a way to organize common solutions to architectural problems using patterns. In the early 1990s, software engineers began applying these ideas to systems architectures. Here is an example of a layered enterprise architecture expressed in Alexander's format:
- Name
- Layering
- Context (situation giving rise to a problem)
- Systems need to evolve to accommodate changing user requirements and new technologies
- Managing change in complex systems
- Problem (set of forces repeatedly arising in the context)
- Applications built as monolithic structures
- Changing one part propagates costly changes everywhere
- Migration timelines are long and expensive
- Solution (configuration to balance the forces)
- Structure a system into layers
- Each layer is a "black box" with well-defined interfaces
- Implementation details of each layer are hidden behind the interface
Figure 2 illustrates the Layering pattern.
Figure 2. source: MITRE
Comparison of Architectural Patterns[4]
- Layered pattern
- Client-server pattern
- Master-slave pattern
- Pipe-filter pattern
- Broker pattern
- Peer-to-peer pattern
- Event-bus pattern
- Model-view-controller pattern
- Blackboard pattern
- Interpreter pattern
The table given below summarizes the pros and cons of each architectural pattern.
Figure 3. source: Vijini Mallawaarachchi
Architecture Patterns in Use[5]
Two examples of architecture patterns in use are outlined in the following subsections, one from the domain of an IT customer enterprise's own architecture framework, and the other from a major system vendor who has done a lot of work in recent years in the field of architecture patterns.
- The US Treasury Architecture Development Guidance (TADG) document (see US Treasury Architecture Development Guidance (TADG)) provides a number of explicit architecture patterns, in addition to explaining a rationale, structure, and taxonomy for architectural patterns as they relate to the US Treasury. The TADG document contains the following patterns.
Figure 4. source: The Open Group
- The IBM Patterns for e-Business website gives a series of architecture patterns that go from the business problem to specific solutions, firstly at a generic level and then in terms of specific IBM product solutions. A supporting resource is IBM's set of Red Books. IBM defines five types of patterns:
- Business Patterns, which identify the primary business actors, and describe the interactions between them in terms of different archetypal business interactions such as:
- Service (a.k.a. user-to-business) - users accessing transactions on a 24x7 basis
- Collaboration (a.k.a. user-to-user) - users working with one another to share data and information
- Information Aggregation (a.k.a. user-to-data) - data from multiple sources aggregated and presented across multiple channels
- Extended Enterprise (a.k.a. business-to-business) - integrating data and processes across enterprise boundaries
- Integration Patterns, which provide the "glue" to combine business patterns to form solutions. They characterize the business problem, business processes/rules, and existing environment to determine whether front-end or back-end integration is required.
- Front-end integration (a.k.a. access integration) - focused on providing seamless and consistent access to business functions. Typical functions provided include single sign-on, personalization, transcoding, etc.
- Back-end integration (a.k.a. application integration) - focused on connecting, interfacing, or integrating databases and systems. Typical integration can be based on function, type of integration, mode of integration, and by topology.
- Composite Patterns, which are previously identified combinations and selections of business and integration patterns, for previously identified situations such as electronic commerce solutions, (public) enterprise portals, enterprise intranet portals, collaboration ASP, etc.
- Application Patterns. Each business and integration pattern can be implemented using one or more application patterns. An application pattern characterizes the coarse-grained structure of the application - the main application components, the allocation of processing functions and the interactions between them, the degree of integration between them, and the placement of the data relative to the applications.
- Runtime Patterns. Application patterns can be implemented by run-time patterns, which demonstrate non-functional, service-level characteristics, such as performance, capacity, scalability, and availability. They identify key resource constraints and best practices.
- Business Patterns, which identify the primary business actors, and describe the interactions between them in terms of different archetypal business interactions such as:
Architectural Styles vs. Architectural Patterns vs. Design Patterns[6]
It is important to reinforce the idea that Architectural Styles, Architectural Patterns, and Design Patterns are not mutually exclusive, they are complementary although, they should be used only when needed. The key difference is the scope. Architectural styles tell us, in very broad strokes, how to organize our code. It’s the highest level of granularity and it specifies layers, high-level modules of the application and how those modules and layers interact with each other, the relations between them. A pattern is a recurring solution to a recurring problem. In the case of Architectural Patterns, they solve the problems related to the Architectural Style. For example, “what classes will we have and how will they interact, in order to implement a system with a specific set of layers“, or “what high-level modules will have in our Service-Oriented Architecture and how will they communicate“, or “how many tiers will our Client-server Architecture have“. Architectural Patterns have an extensive impact on the code base, most often impacting the whole application either horizontally (ie. how to structure the code inside a layer) or vertically (ie. how a request is processed from the outer layers into the inner layers and back). Design Patterns differ from Architectural Patterns in their scope, they are more localized, they have less impact on the code base, and they impact a specific section of the code base, for example: a) How to instantiate an object when we only know what type needs to be instantiated at run time (maybe a Factory Class?); b) How to make an object behave differently according to its state (maybe a state machine, or a Strategy Pattern?). In conclusion:
- An Architectural Style is the application design at the highest level of abstraction;
- An Architectural Pattern is a way to implement an Architectural Style;
- A Design Pattern is a way to solve a localized problem.
- Furthermore, a pattern might be able to be used both as an Architectural Pattern or a Design Pattern, again depending on the scope we use it in, in a specific project.
See Also
Architectural Style
Architectural Principles
Architectural Risk
Architecture
Architecture Description Language (ADL)
Architecture Development Method (ADM)
Architecture Driven Modernization
Service Oriented Architecture (SOA)
Software Architecture
The Open Group Architecture Framework (TOGAF)
Design Pattern
Enterprise Architecture
References
- ↑ Definition of Architectural Pattern
- ↑ What is an Architectural Pattern?
- ↑ Architectural Pattern: Background
- ↑ Comparison of Architectural Patterns
- ↑ http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap28.html Architecture Patterns in Use ]
- ↑ Architectural Styles vs. Architectural Patterns vs. Design Patterns
Further Reading
- Software Architecture Patterns: Understanding Common Architecture Patterns and When to Use Them
- Using Architecture Patterns to Architect and Analyze Systems of Systems
- Are MVC, MVP, and MVVM really architectural patterns?