A Logical Architecture of the Creation Patterns

Here I present 19 creation patterns to help you turn a vision into a holistic, strong technology strategy. They bridge the gap between an idea and an executable plan that has taken all key aspects into account.

The following is a kind of logical architecture of the 19 creation patterns. They are divided into five categories, starting with the broadest scope and narrowing from there, each of which corresponds to a chapter in this part:

• Analysis

• World

• Industry

• Company

• Department

Figure II-1 illustrates the logical architecture of how these patterns work together.

Figure II-1. The set of creation patterns all together in a logical architecture

This architecture is organized into concentric shapes representing increasingly narrow scopes of influence, impact, and relevance. This should help you to match the problem to the set of applicable patterns. The divisions are not strict; they’re just a guide. Consider this a visual table of contents for all the patterns relating to creating your technology strategy. It’s meant to act like a high-level, logical system architecture. Its purpose is to offer you an overview of the patterns all together and show where they operate in their different spheres. It gives you a quick reference point to select the tool that might help you for the job at hand.

Your boss might simply ask you to “make a technology strategy,” because she felt she didn’t have one, or didn’t know what it was, and thought it would be a good idea to create one. This has happened to me several times in my career. In these cases, you need to ask clarifying questions about the concerns she expects you to address, and the scope of the recommendations she expects, so that you aim at the right level.

Consider the following situations.

You need to make a strategy to upgrade the online database. In this case, you’ve got a clear, localized, specialized problem. But it may have high impact if things go wrong. So you’ll need a plan, and you’ll need to contact some folks in different organizations if you miss the cutover window. So maybe this is a small project, and you only need to employ the MECE, Logic Tree, Stakeholder Matrix, and RACI patterns, along with elements of Principles, Practices, and Tools, to make your plan.

Or, you’ve been asked for a strategy to migrate from your home-grown legacy billing system to a new off-the-shelf product. This is a larger project that has impact and constraints outside your tech department and requires more analysis and understanding of your application portfolio and trends in the industry.

Maybe your boss asked if your software development method is right, or if you should switch to a new architectural model. These are larger problems, and you should expect to employ many or all of the patterns in the scopes of Department, Company, and Industry.

If you’re the CTO, CIO, or Chief Architect, or you’re on the enterprise architecture team and have been tasked with creating the technology strategy for your company, expect to employ all the patterns here. This work will take weeks and involve a lot of reading and writing and refining.

You don’t design software by opening the classic Design Patterns book and dutifully making one component for every pattern. It’s the same here. Use what pattern you need when you need it, and they’ll be different for different strategy problem scopes.

But unless you’re creating an overarching, multiyear strategy for your entire technology organization, you don’t need to use all of them all of the time. That would be overkill, incredibly time-consuming, and silly. Of course, keep this book around as a reference and use the ones relevant for the scope and type of the job at hand.

Now let’s look at the patterns.