Architectural Pattern - Revision history

User at 22:23, 2 December 2022

2022-12-02T22:23:33Z

Show changes

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T13:49:49Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 16:10, 29 May 2020

2020-05-29T16:10:57Z

User: An architectural Pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, their responsibilities, and includes rules and guidelines for organizing the relationships between them.

2018-12-03T20:16:40Z

New page

An architectural Pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, their responsibilities, and includes rules and guidelines for organizing the relationships between them.<ref>Definition of Architectural Pattern [http://www.nyu.edu/classes/jcf/g22.2440-001_sp06/slides/session8/g22_2440_001_c82.pdf NYU.edu]</ref>

An architectural pattern is a concept that solves and delineates some essential cohesive elements of a software architecture. Even though an architectural pattern conveys an image of a system, it is not an 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 a business risk. Some architectural patterns have been implemented within software frameworks. Countless different architectures may implement the same pattern and share te related characteristics. Patterns are often defined as "strictly described and commonly available".<ref>What is an Architectural Pattern [^https://en.wikipedia.org/wiki/Architectural_pattern Wikipedia]</ref>

[[File:Architectural_Pattern2.png|500px|Architectural Pattern 2]] 
'''Figure 1.''' source: [https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013 Towards Data Science]

'''Architectural Pattern: Background'''<ref>Architectural Pattern: Background [https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/system-architecture/architectural-patterns mitre.org]</ref> 
"A key aspect to 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.''' 
[[File:Architectural_Pattern.gif|400px|Architectural Pattern]] 
'''Figure 2.''' source: [https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/system-architecture/architectural-patterns MITRE]

'''Comparison of Architectural Patterns'''<ref>Comparison of Architectural Patterns [https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013 Vijini Mallawaarachchi]</ref> 
*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.'''

[[File:Architectural_Pattern3.png|500px|Architectural Pattern 3]] 
'''Figure 3.''' source: [https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013 Vijini Mallawaarachchi]

'''Architecture Patterns in Use'''<ref>Architecture Patterns in Use [http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap28.html opengroup.org]</ref> 
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.
*1, 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.

[[File:Architectural_Pattern1.png|700px|Architectural Pattern 1]] 
'''Figure 4.''' source: [http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap28.html The Open Group]

*2. The IBM Patterns for e-Business web site (see IBM Patterns for e-Business) 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 pattern:
**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 portal, 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.

'''Architectural Styles vs. Architectural Patterns vs. Design Patterns'''<ref>Architectural Styles vs. Architectural Patterns vs. Design Patterns [https://herbertograca.com/2017/07/28/architectural-styles-vs-architectural-patterns-vs-design-patterns/ Herberto Graca]</ref> 
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 organise 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 localised, they have less impact on the code base, 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 localised 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 Style]] 
[[Architectural_Principles|Architectural Principles]] 
[[Architectural_Risk|Architectural Risk]] 
[[Architecture|Architecture]] 
[[Architecture_Description_Language_(ADL)|Architecture Description Language (ADL)]] 
[[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]] 
[[Architecture_Driven_Modernization|Architecture Driven Modernization]] 
[[Service_Oriented_Architecture_(SOA)|Service Oriented Architecture (SOA)]] 
[[Software_Architecture|Software Architecture]] 
[[The_Open_Group_Architecture_Framework_(TOGAF)|The Open Group Architecture Framework (TOGAF)]] 
[[Design_Pattern|Design Pattern]] 
[[Enterprise_Architecture|Enterprise Architecture]]

===References===
<references/>

===Further Reading===
*Software Architecture Patterns: Understanding Common Architecture Patterns and When to Use Them [https://www.oreilly.com/programming/free/files/software-architecture-patterns.pdf Mark Richards]
*Using Architecture Patterns to Architect and Analyze Systems of Systems [https://www.sciencedirect.com/science/article/pii/S1877050913000318 Roy S.Kalawsky, D.Joannou, YTian, A.Fayoumi]
*Are MVC, MVP and MVVM really architectural patterns? [https://medium.com/brq-techblog/are-mv-something-really-architectural-patterns-abc36c1ed821 Anderson Badari]

← Older revision		Revision as of 16:10, 29 May 2020
Line 1:		Line 1:
−	An ~~architectural~~ Pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, their responsibilities, and includes rules and guidelines for organizing the relationships between them.<ref>Definition of Architectural Pattern [http://www.nyu.edu/classes/jcf/g22.2440-001_sp06/slides/session8/g22_2440_001_c82.pdf NYU.edu]</ref>	+	An '''Architectural Pattern''' expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, their responsibilities, and includes rules and guidelines for organizing the relationships between them.<ref>Definition of Architectural Pattern [http://www.nyu.edu/classes/jcf/g22.2440-001_sp06/slides/session8/g22_2440_001_c82.pdf NYU.edu]</ref>

@@ Line 1: / Line 1: @@
-An '''Architectural Pattern''' expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, their responsibilities, and includes rules and guidelines for organizing the relationships between them.<ref>Definition of Architectural Pattern [http://www.nyu.edu/classes/jcf/g22.2440-001_sp06/slides/session8/g22_2440_001_c82.pdf NYU.edu]</ref>
+An '''Architectural Pattern''' expresses a fundamental structural [[organization]] schema for [[software]] systems. It provides a set of predefined subsystems, their responsibilities, and includes rules and guidelines for organizing the relationships between them.<ref>Definition of Architectural Pattern [http://www.nyu.edu/classes/jcf/g22.2440-001_sp06/slides/session8/g22_2440_001_c82.pdf NYU.edu]</ref>
-An architectural pattern is a concept that solves and delineates some essential cohesive elements of a software architecture. Even though an architectural pattern conveys an image of a system, it is not an 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 a business risk. Some architectural patterns have been implemented within software frameworks.  Countless different architectures may implement the same pattern and share te related characteristics. Patterns are often defined as "strictly described and commonly available".<ref>What is an Architectural Pattern [^https://en.wikipedia.org/wiki/Architectural_pattern Wikipedia]</ref>
+An architectural pattern is a concept that solves and delineates some essential cohesive elements of a software [[architecture]]. Even though an architectural pattern conveys an image of a [[system]], it is not an 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 a [[business]] [[risk]]. Some architectural patterns have been implemented within software frameworks.  Countless different architectures may implement the same pattern and share te related characteristics. Patterns are often defined as "strictly described and commonly available".<ref>What is an Architectural Pattern [^https://en.wikipedia.org/wiki/Architectural_pattern Wikipedia]</ref>
@@ Line 33: / Line 33: @@
 '''Comparison of Architectural Patterns'''<ref>Comparison of Architectural Patterns [https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013 Vijini Mallawaarachchi]</ref><br />
 *Layered pattern
-*Client-server pattern
+*Client-[[server]] pattern
 *Master-slave pattern
 *Pipe-filter pattern
@@ Line 39: / Line 39: @@
 *Peer-to-peer pattern
 *Event-bus pattern
-*Model-view-controller pattern
+*[[Model]]-view-controller pattern
 *Blackboard pattern
 *Interpreter pattern
@@ Line 51: / Line 51: @@
 '''Architecture Patterns in Use'''<ref>Architecture Patterns in Use [http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap28.html opengroup.org]</ref><br />
-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.
+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.
-*1, 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.
+*1, 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.
 [[File:Architectural_Pattern1.png|700px|Architectural Pattern 1]]<br />
 '''Figure 4.''' source: [http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap28.html The Open Group]
-*2. The IBM Patterns for e-Business web site (see IBM Patterns for e-Business) 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 pattern:
+*2. The IBM Patterns for [[e-Business]] web site (see IBM Patterns for e-Business) 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 pattern:
 **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
+***[[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
+***[[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
+***[[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.
+***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 portal, collaboration ASP, etc.
+**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]] portal, 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.
@@ Line 73: / Line 73: @@
 '''Architectural Styles vs. Architectural Patterns vs. Design Patterns'''<ref>Architectural Styles vs. Architectural Patterns vs. Design Patterns [https://herbertograca.com/2017/07/28/architectural-styles-vs-architectural-patterns-vs-design-patterns/ Herberto Graca]</ref><br />
 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 organise 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 localised, they have less impact on the code base, 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:
+Architectural styles tell us, in very broad strokes, how to organise 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 localised, they have less impact on the code base, 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 localised problem.
+*A [[Design Pattern]] is a way to solve a localised 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.
@@ Line 100: / Line 100: @@
 ===Further Reading===
-*Software Architecture Patterns: Understanding Common Architecture Patterns and When to Use Them [https://www.oreilly.com/programming/free/files/software-architecture-patterns.pdf Mark Richards]
+*[[Software Architecture]] Patterns: Understanding Common Architecture Patterns and When to Use Them [https://www.oreilly.com/programming/free/files/software-architecture-patterns.pdf Mark Richards]
 *Using Architecture Patterns to Architect and Analyze Systems of Systems [https://www.sciencedirect.com/science/article/pii/S1877050913000318 Roy S.Kalawsky, D.Joannou, YTian, A.Fayoumi]
 *Are MVC, MVP and MVVM really architectural patterns? [https://medium.com/brq-techblog/are-mv-something-really-architectural-patterns-abc36c1ed821 Anderson Badari]