One-Slider

Challenge: You need to pull together the huge and diverse volumes of analysis work into a simple summary that you can use to inform teams and executives of the strategy.

Solution: You need to create a single slide that forces you to crystallize and succinctly state your strategic goals, the initiatives or practices as propositions that follow from them, and the supporting culture you will develop and encourage.

Recall that early in the book, I stated that a strategy must work together hand in hand with execution and culture in order to succeed. This slide is a distillation of how you can keep those three ideas front of mind and communicate them to your teams.

The One-Slider, as I use it, pulls together in one place each of our three aspects of strategy, execution, and culture. It might look like Figure 8-1.

At the top you state your vision. This is an aspirational statement describing what you want your organization to look like in the mid-term or long-term future. This should be a one- to three-year time frame. Less than that won’t give you time to do anything advancing enough. More than that, and you’ll be befuddled by changing forces.

Next, all of your three or five strategic goals should follow as propositions that support and help realize that vision. This is where you will allocate resources, and your estimation of the best way to get to that desired vision.

Next you state the initiatives or practices. This is the execution part. These should be specific, and each will likely be defined as its own project or program and involve cross-discipline teams.

Figure 8-1. The One-Slider summary

The One-Slider does not include all the rich detail you have worked on throughout this book. That material should go in additional slides after this summary slide. Make one slide for each initiative you’ll execute, and show how that decomposes into more localized specific actions and deliverables. They should include specifics about the toolset, and meaningful metrics, as we saw in “Scalable Business Machines”.

Figure 8-2 shows what your initiatives spreadsheet should look like.

Figure 8-2. The initiatives

You have headers for initiative, actions, and deliverables along with the named accountable role that owns that deliverable. The initiatives come directly from your One-Slider, and this represents something at a high-enough level that you can crank it out quickly as a communication tool, but it doesn’t represent all the detail of, say, a Work Breakdown Structure.

This isn’t yet a project plan, but is a transition toward it to ensure that you are not just talking about these things in your teams, but that you can do just enough to have a token document for executive buy-in. Then you can manage the creation of the work as a project. Of course, you can add a column for due dates and so forth. If you have had a kick-off meeting and everyone is ready to start working, and you find yourself wanting to add much more detail, it’s probably time to turn it over to the PMO, transfer it into whatever project management tool you use, and schedule regular meetings to get updates from those with deliverables.

Finally, along the bottom of the summary One-Slider, you have the culture piece. This is not separate for each initiative, because it’s all-encompassing and you can’t go creating distinct cultures for different cross-functional teams in the same world. There is the one culture, and you want to be explicit about what culture you want to form. I hope by now it’s obvious that if you find yourself stating empty platitudes here, such as “winning teams,” you are not digging deep enough. Make only statements as claims that someone else could reasonably argue against, put a stake in the ground, and be proud and go after it.

I hope it goes without saying by now too, but make sure that each section of the slide, and the comprehensive slide altogether, is MECE (see “MECE”).

Use Case Map

Challenge: You have a burgeoning, large system design that represents one of your strategic initiatives. You need to decompose the idea further into practical use cases of value to an end user. You need something to share with an extended team to ensure their alignment and buy-in with the initiative.

Solution: Make a set of Use Case Map slides, one for each major use case. You want to think through the use cases from a customer perspective to ensure it is outcome focused and not merely activity based.

Figure 8-3 shows an example.

Figure 8-3. The Use Case Map

This map has five components:

Customer outcome

Here you state the business benefit that this use case aims to achieve for customers. This is stated in clear, measurable terms, reusing the outcome aspect of the SBM (see “Scalable Business Machines”).

Features

Here you list one or more bullet points of the major features of the system. You will later use these to map to epics. It is something at the level an architect or tech lead can design further. Together, these describe a complete, usable, independent system as an output, as we saw in “Scalable Business Machines”.

Data components

These are the sets of data that are required to realize the output of this use case or to measure the metrics. This is high level in terms of data types, third-party data, or major kinds of data you’ll need to purchase or siphon off the shopping system, gain access to from the data warehouse, or retrieve from third-party APIs.

System components

These are critical, big components of the software or process system you’ll need to create. They may exist already as services, or you may need to refine or reuse some component. They’re the building blocks of the system that are differentiating, complex, necessary, and important.

Customer success measure

These are the metrics, stated like SMART goals, with measurements you can aim for and later verify.

Note that this is particularly helpful in making sure you are thinking in a way that makes your use cases clear, measurable, and valuable as an outcome for customers.

From this stage, you or someone in Product can decompose your Use Case Map into a set of Agile epics or team features to begin transforming the strategy into architecture plans and executable project.

Directional Costing

In technology we get asked for estimates all the time. Everyone jokes about how bad we are at estimating when we will deliver some software module. That’s for a variety of reasons, but an important one is that estimating is hard because we typically think only of the main parts of delivering something, and not the many auxiliary aspects that can take as much time or more. We think of how long it might take us to write the code, and don’t think of how we’ll write it again a different way when we’re unhappy with the first time, handling errors gracefully, instrumenting, writing tests, writing documentation, doing deployments, clarifying requirements, executing builds, refactoring, profiling, browser checking, fixing some broken windows we discover along the way, coding for the six important alternate paths that weren’t accounted for in the stories, learning a new framework, performance improving, and then hooking it up to the bigger deliverable. Writing the code itself is probably 33% of the work, even for a developer. Never mind the time we spend doing a load of unrelated things.

Projects often take two or three times longer than what we say they will. When 80% of the cost of a software project is intellectual labor, that’s a serious financial problem for our leaders.

But the bad news is that as woefully poor as we are at estimating time, we’re worse at estimating costs. That’s because we’re further away from the money, we’re less used to talking about it, and we don’t understand the nuances or even many of the terms nearly as well as we do our software discipline.

The good news is that the best executives tend to understand that the world isn’t black-and-white, that estimates can be defined in stages and in ranges. An executive or salesperson asking for a single, definitive estimate early in the project is actually the sign of a clueless leader, and less the sign of a truly deficient architect who estimates badly. Put another way, a leader asking you for an estimate on the basis of a single-sentence description of a complex problem might deserve open contempt. A leader asking you how much this software project will cost to build can be met with, “I don’t know. How much does science cost?” Refuse such idiotic questions. Much of our problem is that we don’t refuse them—we throw out a number and shake the date tree until a fake deadline falls out—and the executive believes us (or pretends to for other motives), so all of a sudden we’ve chained a team of otherwise good people to a death march.

It’s easy for me to say that you should refuse such questions, but the fact is that this has happened to me countless times in my career. We get backed into a corner. Some executive has a board meeting or the salesperson has a customer meeting or there’s a quarterly review—there are always wonderful excuses—and like an addict, they just need one quick number, one little estimate; they promise this is the last time they ask for an estimate like this, and this time it will be different and they won’t hold us to it, but they just need an idea. This is a dysfunctional relationship that sets a lot of people up for failure. But you can improve it.

There are two things to do to improve this situation we somehow constantly find ourselves in: give a really good estimate or give a much worse estimate. Either of these is desirable, as long as you’ve set expectations properly.

Estimate Template

You’ll be estimating things a lot. Remember that you don’t want to solve only the local problem, but to do just a little bit extra to help scale yourself and the overall organization as well. That means that when we get asked for an estimate, we do it, and then we also want to create a template we can reuse.

To create a good estimation template in software projects, consider these factors: the labor and the data centers.

There are two kinds of labor: the development teams and the supporting cast. Let’s start with the development team. Make a list of who is on your typical development team. I like to use the Margarita Mix team as a standard atomic unit: it’s 4 parts developer, 2 parts testers, and 1 part analysts. So you can say a development team is seven full-time employees (FTEs). Find out the blended rate you use from your PMO or business operations folks. Let’s say it’s $70 per hour. Here’s some third-grade math that will get us a long way: 7 people × $70 per hour × 40 hours per work week × 2 work weeks in a sprint = $39,200 per sprint. Let’s round that up to $40K. That’s the cost of a sprint.

Figure 8-4 gets more refined about the internal rate for the different roles. Your company may use some value that’s fully loaded or not or the same blended rate, or Finance may have a rate sheet they use for doing these kinds of calculations. Use whatever is easy and close at hand for directional costing—it’s more important to be quick at this point than it is to be perfect.

Figure 8-4. Labor costs

Now we can turn our attention to what we know about the work itself. We look at the entire body of work as we understand it at this stage. You’re looking for two things: what must be done in serial, and what can possibly be done in parallel.

Front-load the big blocks that are likely to be “showstoppers”—things that could sink the project if they don’t go well. You want to short-circuit the spending if you can, and don’t put off finding out that something critical is impossible or delayed or different than anticipated. You’re designing the project just enough to be able to determine how many teams you can run in parallel. That will give you the number of sprints you need, the number of teams, and the anticipated duration. Let’s say you can keep 10 teams busy, working on different aspects of the project so as to not interfere with each other. And if you had those 10 teams, the project would take 30 sprints. So you do some more math like this: 30 sprints × 10 teams × $40K per sprint = $12M.

Next you’ll need to account for those auxiliary players, which is a bit trickier to do, since we usually have them only part time, their work is not divided up so neatly into sprints, and it’s hard to see their direction relative to the work and therefore how much of their time we’ll need. We’ll have to consider these roles: Architect, Database Administrator, Networker, Scrum Master, and Project Manager. Put these in your spreadsheet and provide a simple calculator. Let’s say that we’ll need 25% of each of their time for the duration of the project. That would be 5 people × .25 × $70 per hour × 60 weeks × 40 hours per week = $210,000.

So our labor cost is around $14.2M. Figure 8-5 an example of how you might view those in a spreadsheet template on a summary page that you can pop into a deck quickly. This gives you the best of both worlds by showing the details and sets of assumptions as to how you got here, as well as recalculating when those assumptions change and giving you the quick answers that executives will ask about. You can get more sophisticated later and divide the world into capex and opex, but for directional costing, this is good for now.

Figure 8-5. Directional costing summary

Now let’s consider the data center business. If you’re using a cloud provider, it will have costing spreadsheets that make this sort of thing easy. For example, the AWS Cost Calculator helps you plan out the fees you’ll be facing monthly, which is great because it makes all the costs clear. You can fill it out quickly, get a number, and plug it into your directional costing spreadsheet.

The point of this pattern is not to mislead you with respect to the many sophisticated frameworks out there for estimating work. It’s to say this: a lot of times what executives need is not a perfect number, but a directional cost. They really do want a rough ballpark and don’t expect it to be perfect. They want to know if it’s more like $1M or more like $10M.

So sometimes it’s more helpful to produce an estimate quickly, even if it’s not that great. Executives are used to big numbers and tons of ambiguity. So being able to tell them the project is likely around $25M all-in is useful, even if it turns out to cost a bit less or a lot more than that. They are calculating things other than what they are asking you about. They are wondering if they should do the project at all. But they may be thinking of buying a company, and if they can buy a whole company with this capability for $50M and get it today instead of two years from now, and get all their talent and revenue now, then that might be a better option.

Which is to say that while the rough estimate may be maligned, it’s often useful—as long as everyone has the same expectations around it. The Directional Costing pattern turns out to be more about setting proper expectations than about nerdy project management math. There’s a time and place for that, and it’s pretty well understood. So I lay out a different take on it here, in the hopes that this is useful too.

Priority Map

The Priority Map, shown in Figure 8-6 is a simple guide to help you prioritize your Use Cases (see “Use Case Map”) or your strategic initiatives as in your One-Slider (see “One-Slider”).

This pattern provides you with a mental map to quickly guide you through all the angles of both risk and opportunity as you prioritize strategy efforts and major projects during strategy season or big shifts. This won’t be useful for prioritizing sprint backlogs or anything like that, but that’s not what we’re after here.

The map shown in the figure is not the only one you could draw of this kind, but it’s a good start. You could use the Priority Map in conjunction with the Growth Matrix (see “Ansoff Growth Matrix”), Investment Map (see “Investment Map”), or a spreadsheet you devise to score each of your strategic initiatives across all of these items, weight them, and produce a number you can use at least as a starting point for the priorities.

Figure 8-6. Strategic Priority Map

Technology Radar

How can we have a simple way to help us communicate our Roadmap for technology tools and practices to broad and diverse technical teams, collect feedback, and measure progress against advances on our strategy?

The Technology Radar pattern was invented by ThoughtWorks. The company publishes on its website, every six months or so, the set of technology tools it is reviewing, and gives a summary of its view on that technology.

The radar is divided into four parts: Tools, Techniques, Languages & Frameworks, and Platforms. Then ThoughtWorks further divides the technologies within each of those areas into a category based on how the company advises you to consider them. These subcategories are Adopt, Trial, Assess, Hold.

I like to look at this radar on occasion to consider how ThoughtWorks is thinking about technology. But they company opened up its radar-making tool so that you can generate your own radar using your own categories and list of items. This is a terrific way for you to visualize and share with your teams how you’re thinking about the set of tools out there. Depending on your culture, this can be more of a dictum or more of a guide.

The radar is not merely a frozen perfect tech future represented in boxes and arrows, but shows the tools and techniques together and presents them in a clear, easy-to-understand framework, and presupposes that you will evolve and update it.

The radar is a set of concentric circles representing criticality and standardization levels, showing what teams should start using now, what to learn about and test, and what to contain and avoid.

The Technology Radar will evolve over time, in a methodical, inclusive, transparent manner. This is a more evocative, realistic, and planful way to show your thoughts on technology features than a traditional single, pristine architecture target state as if it could be frozen in time. Figure 8-7 shows a sample from ThoughtWorks of what this pattern looks like.

Figure 8-7. Technology radar

There’s value in helping your teams see how you’re thinking, topics they should be researching, or areas where they might suggest other items you weren’t aware of. Instead of providing a merely beautiful, oversimplified, isolated, frozen snapshot of a future state (as architects all too often do), you can represent architecture as an evolving radar, improving the signal-to-noise ratio, and support a practice of directing capabilities toward a strategy. This can help us offer options through a variety of lenses.

Remember, too, that the radar-making tool can include any categories and items, so you could use it as a way of presenting strategy priorities in conjunction with the Priority Map (see “Priority Map”).

Build/Buy/Partner

Sometimes we’re brought into conversations with the business development folks who do mergers and acquisitions. We can use the Build/Buy/Partner pattern as a way of framing our conversations with them. It’s important to align these decisions with your technology strategy. Let’s take an overview of each of the three options in turn.

Due Diligence

As part of the conversations we have during Build/Buy/Partner (see “Build/Buy/Partner”), if things advance to the Buy stage, we’ll need to perform a Due Diligence. This is an assessment of the technology and operational aspects of the target company. It’s very important, because it’s used to determine if the company should be bought at all. Depending on the outcome of your assessment, it may suggest that you leave the company be, or pay a different price than what the company is asking, or go a more nuanced route and pick up only part of its software, or enter into a licensing agreement. There are too many variables to make those suggestions into a template here, so this pattern is confined to helping you consider all the technological aspects so that you can make an informed decision. I encourage you to make your own template as suits your purposes. This pattern offers you a strong starting place for performing this kind of analysis.

First make a spreadsheet that will represent your template. Create a summary page, as we did with the Directional Costing template (see “Directional Costing”). It looks like this:

This is your master list of concerns in the assessment. You can add one for your own company’s particular concerns, and how well the target aligns with your strategy and Roadmap, distinct from these generally reusable and standard categories.

You will create a set of questions in each of these categories and give the target product’s answer a score. Make a legend like this:

0: Unsupported and not on the Roadmap

1: Unsupported but on the Roadmap

2: Implemented but weak

3: Implemented and suitable

4: Implemented and world-class

Add another column to reflect these scores, as summed on each section’s individual worksheet.

These scores of 0–4 will cover most of the circumstances I tend to see when doing this kind of work. If the company states that a particular feature you’re interested in is unsupported in the current system, and not on the Roadmap, that’s a different signal to you than if the company knows it’s important and has it prioritized but just hasn’t done it yet.

Then create separate worksheets for each of those categories that have the drill-down questions. These will form the core of your assessment.

Each subsection spreadsheet (you’ll have 12 of them) will look something like Figure 8-8.

Figure 8-8. Due Diligence subsection spreadsheet

Make a similar worksheet for each of the remaining primary characteristics. You then score each one of these individual items with a value from your legend, 0–4. This should sum up to a score for that characteristic and then appear in the summary page. Together, these all add up to a score for the product.

There’s a second use for this template: note that as a software vendor, you could also offer this to large enterprise customers as they assess whether they should license your software or not.

Architecture Definition

I’m going to have to contextualize this template a bit. Let’s start with recent attitudes toward how we express architectures.

In my experience, the predominant form architectures take is in the clever people expressing their views over email and in meetings. This is too informal, too untraceable for architecture work. To be clear: I reject this mode of business unless the team is small, they all share extra-sensory perception, and what you’re building doesn’t require any physical load bearing. If you’re building Yet Another Trivial Social App for neighbors to spy on and gossip about each other, that should work just fine.

But when this “method” finds its way into the enterprise, absent any formal means, teams in these environments will be confused or uncertain about how to do things. The role of the architect lacks clarity, and there is insufficient accountability for their decisions. The products will also suffer as a result, and thereby so will your customers. Moreover, the architect, and thus the organization, is unable to scale, since they’re required to be present and speak to how they want things built. This is far too slippery and sloppy a mode for any really helpful architect.

Yet in recent years we hear formal architecture definitions—and perhaps even the practice of architecture itself—sometimes derided in the posh voice of maverick trendsetters, those impresarios of the modern software stage who denounce waterfall, reject RUP, and poison the well for any way of representing requirements that doesn’t fit on a Post-it note. We mustn’t plan because the world “changes” so fast, we are told. We have no problem spinning up 150 people to type their hearts out for two years, presuming to use $25M of someone else’s money to build something without a plan or design. But we can’t afford to have three smart people think about how to build this thing for three weeks. I find this irresponsible. We need to have a clear picture of what we’re doing, why we’re doing it, and how we’re doing it, and we need to be able to refer to those things.

But the currently prevailing trendy attitude in some—not all—software circles can be very inefficient. It can create significant churn, waste, confusion, redundancy, alienation, and lack of alignment. Yet in the name of saving time, we sometimes dismiss formal architectures. “We don’t have time to write this stuff down,” I’ve had dev leaders tell me. There’s never enough time to do it right, but there’s somehow always enough time to do it over.

Other detractors would denude the art and science of software development methods or architecture documents down to a set of platitudes proclaiming “disruption” and “obsession with customer feedback” as if their “platforms” will spring to life without a clear picture of what they’re doing, why they’re doing it, and how they get there. “Move fast and break things” works if you don’t think your customers are people, and what you’re “breaking” is trivia within a predominantly closed system entirely of your own devising with no operational contractual responsibilities, and you hold people, relationships, and data as playthings. I wouldn’t hope to get on an airplane built by software teams proclaiming this hollow creed.

For many practitioners, “Agile” seems to have devolved into “we don’t have to write requirements,” and “iterative” often translates to “we don’t have to think about what we’re doing.” But since it’s iterative, we can just revisit the same code and the same problems over and over, like a scene from Groundhog Day, or enter a Sisyphean eternal return from which one day hopefully someone will rescue us.

Consider that Google was built on a tremendous architecture foundation. The many (publicly available) founding papers for web search and PageRank are 20 pages long each—including diagrams and math!—adding up to many pages of descriptive, specific, planful architecture that paid careful attention to business architecture (though they don’t call it that, instead referring to the vulnerability of the algorithm as what eventually become known as “Google bombs”), and thoughtful and specific design around the scalability and the core components. Though the folklore likes to suggest that Silicon Valley is full of freewheeling geniuses who ride around on colorful bikes and don’t need to think about how to build their systems because it will all “just work” as long as they’re thinking about disruption, this is a false narrative.

This pattern represents a template to record architectural decisions and goals with the aim of guiding development teams working in an Agile environment. So it is up-front. In my experience, architecture is best expressed with a formality somewhere between a long hallway conversation and a full-blown Turing-complete intricate specification written in thousands of pages with Leslie Lamport’s TLA+. If you think even this middle-road way of recording architecture is too formal, this is how real companies are built: see the Google Search Architecture, the Google BigTable architecture, and the original Cassandra paper describing its architecture from its creators at Facebook. Often these papers were written for the public after the fact to explain how the systems were built. When this level of forethought isn’t applied initially, the software tends to quickly be rewritten and eventually scrapped. Consider the entire AWS website Amazon has devoted to its whitepapers, or a talk by a hero of mine, Amazon CTO Werner Vogels, on scalable architecture and how architecture must work with the business. There are a lot of PhDs writing these architecture papers. And they didn’t do it after the companies made their first billions. However people may talk, this level of detail, thought, and comprehensive planning is how the grown-ups do architecture.

In my view, to best help guide teams and direct systems toward demonstrating strong nonfunctional attributes, and to best scale the organization, the architect needs a template. This template might be called the Architecture Definition Document. It’s the document analogous to the blueprints of a building architect.

The product management team owns the functional requirements: what the system does. These items are expressed in epics and user stories and stored in something like CA Agile Central. That’s great. But the architecture team owns the nonfunctional requirements: how the system will be realized—and what’s their form of expressing the architecture?

The purpose of the Architecture Definition pattern is to express in clear, executable, measurable, testable, directive text what the nonfunctional requirements (NFRs) of the system are.  These are the -ilities,” which we covered in “The Architect’s Role”.

I’ve used the same basic template for well over a decade to express architecture requirements. It’s based on TOGAF, but is much lighter and, I believe, more pragmatic. In this pattern, we’ll walk through the major sections of this template. Then anytime you have an architecture question that needs answering, you can use this template. It scales from just several pages if you’re making a change to a single component inside a system, to large documents that cover how to build entire new systems. I’ve used it to write architectures in just 6 or 10 pages, to 50 pages, to 150 pages. It scales in a different way too. The lead or enterprise architect might write one capturing the broad contours of a system, and then have local application architects on a team write “child” architectures that represent specific subsystems.

One question that comes up is: When should architects weigh in? I use the following informal little rule of thumb, and make sure the team knows it too:

• When something is going to cross a data center or other significant network boundary

• When something is going to cross system boundaries

• Anything architecturally significant

The question of what’s “architecturally significant” seems slippery, but it’s actually rather decidable. It breaks down to one or more of these, based on the Wikipedia list:

• There is high business value, it’s highly visible across teams, or it has high technical risk.

• There is high risk of budget overruns or high business risk based on past experience with similar projects.

• There are outstanding questions or concerns from a key stakeholder or business leader.

• This component is new or first-of-a-kind to the organization—none of the responsibilities of existing components in the current architecture addresses it, or it must dramatically change.

• The requirement has Quality of Service or SLA (service-level architecture) characteristics that deviate from all the ones that are already satisfied by the evolving architecture.

If there’s other stuff, architecture can be silent on it and let the team leads handle it. Now let’s look at the template itself.

Summary

In this chapter, we covered eight patterns to help you talk about your strategies and architecture decisions to a wide variety of audiences at different levels. The tech teams, management and decision-making executives, and customers will all benefit from the patterns presented here:

1. One-Slider (see “One-Slider”)

2. Use Case Map (see “Use Case Map”)

3. Priority Map (see “Priority Map”)

4. Directional Costing (see “Directional Costing”)

5. Technology Radar (see “Technology Radar”)

6. Build/Buy/Partner (see “Build/Buy/Partner”)

7. Due Dilligence (see “Due Diligence”)

8. Architecture Definition (see “Architecture Definition”)

The next chapter will show you different types of slide decks that you can use to tell others about your great ideas and how to structure them so those people understand them, like them, and fund them.