Architectural Patterns: A Pattern

We have often in the past struggled with the process of establishing some architectural patterns.

It is probably one of those things, that if you try to find a use for it, you will fail, but one day it will suddenly be obvious.

One of my esteemed colleagues was working on an audit of a Disaster recovery capability for one of our business units.  During the course of his work he was mapping out the locations of all of the servers and the links, and since this was a high availability solution, when he was done he had drawn a picture representing a typical high availability solution, with links to a disaster recovery site for replication and clustered servers for redundancy and load balancing etc.

We decided to abstract the drawing he had made to a more generic view, listing instead of the actual server names, simply the roles they played, like “Application Server”, “Web Server” etc.  Abstracted a bit further we had a picture of what a typical high availability solution should look like in our environment.

It was a simple job to extrapolate from there what a “Continuous Availability” solution and what a Regular and Budget solution should look like.  So what we had now was a set of “Deployment Patterns” for solution hosting.  From Low-end to High-end requirements.  Next we gave them names and described their defining characteristics.  The “Budget” offering would have daily backups and if it failed we would order new hardware with up to 3 weeks of lead time. Each pattern inherited more characteristics as they became clear: Recovery time objectives, Recovery point objectives, Availability targets etc.

So now when we refer to a Bronze deployment or a Silver Deployment, everyone should immediately have in mind the same set of characteristics, and pricing level.

Then we publish a nice little poster describing the patterns we have discovered.  Patterns are discovered, not created.  Standards are created, but patterns usually already exist.  We know what “Should” be done in a given set of circumstances and what typically “Has been” done before.  The trick is seeing how things relate to one another. “Ahh, these are different types of hosting deployments, and they have different levels of availability requirements.”

Another point to note is that patterns come in sets.  We have a set of hosting patterns, a set of monitoring patterns, a set of integration patterns.  We cannot sit down with the objective of creating “Architectural Patterns” without an understanding of their objectives.

In Pattern-Oriented Software Architecture: A System of Patterns, (F. Buschmann, R. Meunier, H. Rohnert, P.Sommerlad, and M. Stal, John Wiley and Sons, 1996) three types of patterns are noted:

  • An Architectural Pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.
  • A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes commonly recurring structure of communicating components that solves a general design problem within a particular context.
  • An Idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

From the Book above and some adaptations of other pattern concepts I have adapted this Pattern for Patterns:

  • Name: A meaningful and memorable way to refer to the pattern, typically a single word or short phrase.
  • Problems to be solved: Describes the problem to be solved, with reference to the goals and objectives as appropriate.
  • Pre-context: The conditions relevant to the pattern that exist before the pattern is applied.
  • Principles: Adopted rules, policies and predetermined modes of action for the pattern.
  • Solution: A description of how the problem is solved.
  • Products: Example products which can be used to implement the pattern.
  • Resulting context: The conditions that result after the pattern is applied, including resolution of competing forces.
  • Resulting context owner:    The enterprise client who owns the benefits of the resulting context. Typically this would also be the owner of the requirement for this functionality.  This may be a role rather than an individual e.g. “Operations Manager”,”Integration Committee” etc.
  • Examples: Sample applications of the pattern.
  • Rationale: A description of why the solution is solved in a particular way – possibly describing the key trade-offs made between competing forces.  For example:
    • Security, robustness, reliability, fault-tolerance
    • Manageability
    • Efficiency, performance, throughout, bandwidth requirements, space utilization
    • Scalability (incremental growth on-demand)
    • Extensibility, evolvability, maintainability
    • Modularity, independence, reusability, openness, composability (plug ‘n play), portability
    • Completeness and correctness
    • Ease of construction
    • Ease of use
  • Related patterns: Related patterns are predecessor, successor and alternative patterns, which provide similar solutions.
  • Parent pattern: If this pattern is completely contained within another pattern, the name of the containing pattern.
  • Sub-patterns: Patterns which provide specialised behaviour yet are completely contained within this pattern.
  • Known uses: Known applications of the pattern.
  • Immediate predecessor patterns: Other patterns that contributes to the immediate pre-context of this pattern, i.e. They give inputs that are critical to the functioning of this pattern.
  • Immediate successor patterns: Other patterns that depends on this pattern for their pre-context, i.e. This pattern must provide inputs to these successor patterns.
  • Security considerations: Security aspects that must be considered for the pattern.  Does this pattern treat sensitive data or have capabilities that should be secured.

The Names of the various Patterns should be used in a “Framework” or Navigation matrix that will help a user to select the appropriate pattern for their particular use.  An Example of this is a set of Monitoring Patterns that we have created.  The Framework indicates monitoring “objectives” (SLA Management, Operations Management etc) as column headings and the “activities” (Instrumentation, visualisation, correlation etc) as row headings.  At the intersection of each pair is a pattern name.  Find the point in the matrix that best matches your specific intentions and you will have a specific pattern or set of patterns indicated for your business or technical problem.  It is really important to have this navigation structure in place to help users find their way through a potential maze of options.

Some Resources:

This entry was posted in Challenge, Management and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *