Introduction
Patterns are visual models to base designs and solutions on. Different patterns provide different assumptions, but in general, they all represent a simplified ideal.
They vary in size and scope, but they tend to focus on a way to fix a problem. Whether you have those problems and thus, whether you need a given pattern is something to remember. Fixing problems you don't have does give you more problems...
Why use Patterns?
Good examples of patterns can be found everywhere. Some really simple, basic ones which are fairly ubiquitous are things like 'the wheel', 'knives' or 'a campfire'. There are well understood, documented ways to make these things, which have been known for most of civilisation. You can try to build your own versions, but these patterns are well refined and understood.
We use patterns for this reason. People who needed them before you have thought about them and figured out the wrong ways to go about it, and eventually written good, working ways. Over time, people improve on them, and the idea gets better.
Architectural patterns are templated ways of acheiving certain things, which we know are safe, successful and easy to look after, which do the 'thing' that we need.
Where do I find Patterns?
Everywhere.
But thats not a very helpful answer. Google is great, you can literally search for them, but you often come up with all kinds of interesting things. Some ideas:
- Vendors provide reference architectures for their products. Microsoft, oracle and Amazon all have good examples of successful, proven ways to use most of their products, either together or independantly, in a myrid ways, to fit your need.
- Research. You can work on your own patterns, based on your own problems. Finding corroborating 'evidence' that others came to a similar conclusion is a good way to verify your thinking. But 90% of problems are not unique.
- Tutorials and training materials. Often, these are produced by experienced individuals, so when they show you have to use a library or technology, they will be working to a 'known good'. Which is a pattern.
The key takeaway here is that most problems you encounter have a fix which is good enough for most people/companies. You don;t need to innovate everywhere; its tiring and expensive. Save your A game for those times its needed and build your designs ont he shoulders of those who came before you.
Pattern Benefits
- Reducing work and risk. If you can reference the work of others, it can be faster to design and they'll provide things like assumptions and risks to help you reduce the risk and time to deliver your own projects.
- Lowering costs. Using existing patterns removes the unknowns and the guess work. Whilst you may feel a bit less 'expert', knowing when someone else has a better idea than you is a mature point of view, which will save your projects time and money.
- Simpler collaboration. Its much easier to explain whats happening to someone, if you can talk in a language they understand. If they have experience in the area, then they may already be familar with it.
Risks of using patterns
- There could be a better option out there, which meets a business requirement.
- I tend to find that this is a false start. If you can build on the proven model and simplify the business, the outcomes will be bettter. Do take the time to understand why the business is doing something differewnt though, and make sure you can mitigate that.
- It can be very uninteresting to implement other peoples patterns all day.
- Actually, this is a good thing. You're not paid to have fun ;)
Anti-patterns
The opposite of a pattern is an anti-pattern. Often, these are as informative; learning what other people tried and what didn't work can be a better explanation than what did!
For some good example anti-patterns, look at: Scrum.org, they have some good examples.
Template
As always, here's a pattern for recording patterns, to try save some mental load. As always, this has been stolen and butchered, thank you Internet for providing examples and apologies to any uncredited authors.
Overview
Outline the pattern and its purpose. Keep it short and sweet.
Illustration
Draw a picture! It really does help.
Description
Explain the probklem it solves, the pattern and common usage.
Benefits
Why is this pattern good? What does it do, and what do you get?
Concerns
Are there drawbacks? Coudl the pattern be misused or introduce extra concerns or complexities?
Examples
Show examples of usage, they also help illustrate the possible.
When to use
Show good use cases and directions. the aim is to support colleagues to make decisions or avoid asking for help!
When to avoid
If there are good cases where the pattern seems compelling, but won't be, outline them.
Approach
Explain how to implement or approach the pattern and problem.
References
Provide references! Linking your work to others builds a body of support and concensus, which supports the pattern and use.
There are examples on this site, just click on the 'Patterns' tag, wherever you see it.