Here is a sketch of the mental model I use when thinking through how to address a space with prescriptive guidance:
At a high level, it’s a “stack,” and by having a model of the stack, you can choose how far up the stack to go:
- Domain Knowledge – This is about breaking the problem space down into useful nuggets. The most useful nuggets I’ve found are: frames, application types, qualities, hot spots, design guidelines, principles, patterns, and capabilities. Frames would simply be mental models or ways to look at the space. Hot Spots are areas within the problem space that get a lot of attention, either because they create a lot of pain, or create a lot of opportunity, or they are simply high use. Qualities would be quality attributes like security, performance, reliability, etc. These cross-cutting concerns shape the solutions within the space.
- “Blue Books” – This is a way to package, share, and scale the expertise within a given domain. It’s a collection of the key principles, patterns, and practices for that domain, packaged into a cohesive whole. This action-guide, or prescriptive guidance, creates a bird’s-eye view of guiding principles that help govern solutions within the space. By sharing the common application types, hot spots, frames, deployment patterns, technology maps, etc., it creates a way to make sense of the problem domain, and serves as a firm foundation for more specific solutions. It’s like the driver’s guide for the space. See The Power of Blue Books for Platform Impact. They have been the most effective way I’ve been able to transfer large amounts of know-how to the developer and architect communities.
- Playbooks – These are like thin “Blue Books.” A playbook can be used to target a specific scenario or set of scenarios. These are effectively “thin” Blue Books. They build on the generalized guidance and make it more specific, by walkthrough through instances or examples to light up the guidance.
- Knowledge Base (KB) – I’m a fan of a “thin guide” + “thick KB” approach. The knowledge base serves as a clearing house for the nuggets of insight and action within the domain. They are more of a random access collection of useful solutions or insight into key concepts, without having to be packaged into a guide.
- Tooling – There are many ways to provide tooling. The ideal scenario is to have flexible tools that codify the patterns and practices by having better defaults, starter templates, starter code, guiding principles, baselines that can easily be tailored, etc. Ideally, the tooling is connected to a live stream, where it can continuously evolve based on the knowledge from the community. For example, “building code” would be very specific guidelines, such as technology recommendations or scenario-based patterns. Ideally, these can turn into either rule-checkers or at least provide support for manual inspection.
- Community – This is where the magic can happen. By providing enough of these raw materials in the form of mental models, principles, patterns, etc. it’s easier for folks in the trenches, thought leaders, and anybody with a passion in the space to build on the knowledge and stretch and evolve it into new directions, and continue to advance the knowledge in the domain. A key to enable this though, is having places to go where people feel like their contributions can actually make a difference, and help influence or impact the greater good.
One thing I didn’t explicitly show in the model, is the idea of media, such as videos and slides, and train-the-trainer material. To really get adoption, the media and train-the-trainer material help spread the word. They make it easier for raving fans to adopt and to help spread, as well as to help teach others.
Together, all these parts work to create a “platform” and an “ecosystem” for prescriptive guidance. While it’s not a hard and fast model, it has helped me both figure out the opportunities, as well as evaluate competition, and it helps me see where various types of deliverables fit into a bigger backdrop for impact.