In the course of an Architect's career, you kind of build a repository of tools, a toolbox if you will, of odds and ends that you have picked up over time. Often times, these are simple things like icons that you find particularly effective, a presentation from a colleague that demonstrates an effective tactic, a couple of white papers, a PDF of TOGAF or insert-methodology-or-framework-here, etc.
Recently, I started a search in an effort to add to my toolbox, this time looking specifically for identified patterns for infrastructure architect. Rather early in my search, i came to the realization that while I have patterns all around me, many of the core references I had hoped to leverage seem to do a poor job identifying them as such.
If you go to Microsoft and you want to find patterns, there are thousands of resources for patterns - if you are searching on MSDN for programming related material. Do the same search of TechNet material and you will either note a null response set or more likely a set rife with assets from the patterns and practices team, which are more application or extensibility related.
Want specific implementation patterns for components of Exchange? SQL Server? ISA?
I've found the secret, friends. Start with a good resource on strategies for quality attributes and you will gradually come to recognize many of the tactics which you use to implement various qualities are in fact, in their own way of set implementation, patterns.
Falconic Note: I just finished reading a great resource on Architecture that I would highly recommend to anyone pursuing an industry standard architecture credential, including specifically the MCA. Software Architecture in Practice by Len Bass, Paul Clements, and Rick Kazman. Yes, I said software architecture but don't let the title fool you. Sure, as an infrastructure architect, there is going to be a fair amount of information in here that you will never use but there is also a wealth of information in here about identifying and managing stakeholders, letting quality attributes drive your tactics and therefore your overall design, how to use UML to communicate information about that architecture, etc.
Its a little light on methods, patterns, and information about industry standard frameworks and methodologies, but think of it as a building block before you get into those more detailed - and messier - subjects.
As I am looking at the tactical guidance for a strategy like Availability, it strikes me that some of the pieces floating around in my head actually coalesce into a pattern! We all know Redundancy or Cloning? Also known as Scaling out, you simply add more of the same resource ideally to provide multiple points which can handle an identified function in the case of a fault of some kind causing a failure in one of the components. If you think about it, there are certain ways to implement Redundancy which have models of implementation which are going to be consistent no matter what brand or software, etc, the actual components are composed of.
Implementing Network Load Balancing? The way it works will probably always be a base set of functionality. A virtual IP address (still called a VIP even if its on a physical adapter) provides an interface that obscures n number of nodes which will handle some measure of the distribution of the designated traffic provided to that address. I can put a hardware network load balancer in there or I can use software NLB. I can use NIC teaming or load balancing. I can have my switch do it for me. I can change the number of nodes behind the VIP from 2 to 42. I can put Windows in there or Linux or whatever on the nodes themselves behind the VIP. The skeleton of functionality remains. A vip controlled by some measure of functionality abstracts access to one or more nodes providing an identical service.
If we go by the 1996 book the Pattern Oriented Software Architecture, patterns are:
"expressing a fundamental structural organization 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."
We can break it down then. Using Network Load Balancing provides a fundamental structural organization. A service (the virtual interface) provides an abstraction layer for two or more subsystems providing identical functionality to the consumer accessing the service. The service uses some measure of algorithm to identify which abstracted subsystem should accept the presented message and/or return the expected functional response.
Update, Some Links to Assist
There are plenty of resources out there for architecture. There are still many when you search for infrastructure architecture. It would do a great deal more for the practice of architecture were more effort made to build a collection of enterprise and solution level infrastructure patterns similar to what our brethren in software development are now provided by Model-View-Controller, Model-View-Presenter, Enterprise-Service-Bus, and others.