Frameworks, Patterns, and Methodologies
A couple years ago, during the earlier days of my architecture research, I was often confused by three topics – frameworks, patterns, and methodologies. While I would not consider myself an expert on these topics, hopefully this article will suffice as a jump start for anyone whose understanding is still in need of some clarity.
Frameworks
Frameworks, as least as they relate to the computer sciences, are in essence a model. They are a representation of and typically a usable structure for implementation in a given scope. Usually embodying best practices or fundamental primitives based on best practices, frameworks can be used to follow a widely accepted behavior or produce a more predictable output. Frameworks are typically created to support long term behavior and thus support implementation techniques such as component reuse or foundational repositories from which reuse can occur. Frameworks can exist in any of the major architecture domains – business, data, application, technology – or in the case of FEAF or TOGAF act to organize entire supersets of behavior. Frameworks organize through interface or usage constraints defined by the model. Another example of a framework, are common software libraries, where they place organizational and structural constraints on the modules which leverage them.
Examples of architecture frameworks: TOGAF Content Framework, ITIL, and EA3 Cube
Patterns
Patterns found their way into IT via Christopher Alexander, a building architect, whose ideas were adapted to the world of software engineering by the Gang of Four in Design Patterns: Elements of Reusable Object-Oriented Software in 1995. Defined as “an idea that has been useful in one practical context and will probably be useful in others,” their concept was that if architecture and design in the physical world could extrude some valuable insight about shortcuts to good design, then software engineering could as well. This idea has largely not been adapted to systems architecture as is evidenced by this quote from TOGAF, “Patterns for system architecting are very much in their infancy.” It could be said that one of the reasons for this is that frameworks tend to act as a macro-pattern, and patterns themselves are often found in more local application, such as in specialized design patterns.
Examples of architecture patterns: Client-Proxy Server, Layered Architecture, and Pipe and Filter Architecture (TOGAF on TADG)
Methodologies
Methodologies, unlike frameworks, are not organizational in nature and are typically not found in architecture domains. Unlike patterns, they are not useful examples, though they may contain examples. Methodologies are typically a process and are always towards some particular and predictable end. Frameworks, as in the case of TOGAF, might contain methodologies (ADM) but they do not typically contain frameworks, though they may prescribe their use. Methodologies are about “what you do?” not “how you do it?” which is more of the case for frameworks and patterns.
Examples of methodologies: ADM, SDM, PRINCE2
As I’ve written this article, I have found (which is really the desire for this blog to begin with) that my understanding is less clear that I had hoped it was. I feel as though I have only done a small amount of justice to defining these terms, establishing them in respect to one another, and giving examples. Please comment with any additional thoughts or corrections. I’d love to hear your feedback.
