The Arcitura Education Patterns, Mechanisms and Metrics Master Catalog
Arcitura Education Inc. is a leading global provider of progressive, vendor-neutral training and certification programs. Arcitura has been supporting the educational development and certification of IT professionals for over a decade and in over 70 countries. Arcitura’s portfolio encompasses over 60 courses and 30 certifications that cover contemporary fields of practice, including Cloud Computing, DevOps, Blockchain, Machine Learning, Artificial Intelligence, Internet-of-Things, Big Data, Service-Oriented Architecture and Containerization. Arcitura exams are available worldwide via Pearson VUE testing centers, online proctoring and on-site proctoring. Digital certifications are issued together with digital badges via Acclaim/Credly. To learn more, visit https://www.arcitura.com.
This site is comprised of several hundreds of pages that establish a series of online catalogs of design patterns, technology mechanisms, metrics and tool definitions published in support of the following Arcitura certification programs:
- DevOps Specialist
- Microservice Architect
- Service API Design & Management Specialist
- Containerization Architect
- Blockchain Architect
- IoT Architect
- Cloud Architect
- Cloud Security Architect
- Cloud Virtualization Specialist
- Cloud Storage Specialist
- Big Data Architect
- Big Data Engineer
- SOA Architect
- SOA Analyst
- Service Security Specialist
- Machine Learning Specialist
- AI Specialist
The pattern, mechanism and metric descriptions were developed for official Arcitura courses associated with these certification programs. Some of the pattern profiles on this site are summarized versions of more detailed pattern descriptions provided in the courses. This site is an on-going work in progress, as new content and enhancements are being added on a regular basis. Please report any problems or errors to email@example.com.
What is a Design Pattern?
The simplest way to describe a pattern is that it provides a proven solution to a common problem individually documented in a consistent format and usually as part of a larger collection. The notion of a pattern is already a fundamental part of everyday life. Without acknowledging it each time, we naturally use proven solutions to solve common problems each day. Patterns in the IT world that revolve around the design of automated systems are referred to as design patterns.
Design patterns are helpful because they:
- represent field-tested solutions to common design problems
- organize design intelligence into a standardized and easily referenced format
- are generally repeatable by most IT professionals involved with design
- can be used to ensure consistency in how systems are designed and built
- can become the basis for design standards
- are usually flexible and optional (and openly document the impacts of their application and even suggest alternative approaches)
- can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied)
- can sometimes be applied prior and subsequent to the implementation of a system
- can be supported via the application of other design patterns that are part of the same collection
- enrich the vocabulary of a given IT field because each pattern is given a meaningful name
Furthermore, because the solutions provided by design patterns are proven, their consistent application tends to naturally improve the quality of system designs.
Note that even though design patterns provide proven design solutions, their mere use cannot guarantee that design problems are always solved as required. Many factors weigh in to the ultimate success of using a design pattern, including constraints imposed by the implementation environment, competency of the practitioners, diverging business requirements, and so on. All of these represent aspects that affect the extent to which a pattern can be successfully applied.
A pattern language is a set of related patterns that act as building blocks in that they can be carried out in one or more pattern application sequences where each subsequent pattern builds upon the former. The notion of a pattern language originated in building architecture as did the term pattern sequence used in association with the order in which patterns can be carried out. The extent to which different patterns are related can vary, but overall they share a common objective, and endless pattern sequences can be explored.
Most of the design patterns covered on this site are documented in a pattern profile comprised of the following parts:
- Requirement – A requirement is a concise, single-sentence statement that presents the fundamental requirement addressed by the pattern in the form of a question. Every pattern description begins with this statement.
- Problem – The issue causing a problem and the effects of the problem are described in this section, which may be accompanied by a figure that further illustrates the “problem state.” It is this problem for which the pattern is expected to provide a solution. Part of the problem description can include common circumstances that can lead to the problem (also known as “forces”).
- Solution – This represents the design solution proposed by the pattern to solve the problem and fulfill the requirement. Often the solution is a short statement that may be further followed by a diagram that concisely communicates the final solution state. “How-to” details are not provided in this section but are instead located in the Application section.
- Application – This part is dedicated to describing how the pattern can be applied. In can include guidelines, implementation details, and sometimes even a suggested process.
- Mechanisms – When applicable, a pattern will be associated with a list of common mechanisms that can be implemented to apply the pattern. Usually, some of the mechanisms will have already been referenced in the Application section. The application of the pattern is not limited to the use of these mechanisms.
Each pattern profile begins with the Requirement statement followed a table containing concise Problem and Solution statements, an Application summary, and an optional Mechanisms list. Some patterns have additional associations, such as with architectural models, reference architectures and tools. The pattern profile table is followed by corresponding sections that generally provide more detail. This online catalog provides summarized versions of pattern profiles. Complete coverage of patterns is provided in the associated course booklets and text books.
Compound patterns are comprised of common combinations of design patterns. A compound pattern can represent a set of patterns that are applied together to a particular program or implementation in order to establish a specific set of design characteristics. This would be referred to as joint application. Alternatively, the patterns that comprise a compound pattern can represent a set of related features provided by a particular program or environment. In this case, a coexistent application of patterns establishes a “solution environment” that may be realized by a combination of tools and technologies. When illustrating a compound pattern, a hierarchical representation is usually required, where the compound pattern name is displayed at the top, and the patterns that comprise the compound are shown underneath.
What is a Mechanism?
Technology mechanisms represent well-defined IT artifacts that are established within an IT industry and commonly distinct to a certain computing model or platform. The technology-centric nature of some courses requires the establishment of a formal level of mechanisms to be able to explore how a given pattern can be applied differently via alternative combinations of mechanism implementations. This not only standardizes proven practices and solutions in a design pattern format, it further adds standardization to pattern application options. Note that not all patterns are associated with mechanisms.