Most of the activities IT performs aren't strategic. Like clean sheets, they're important, but not differentiating. How do you determine what's strategic? Evaluate the domains of your business.
Suppose you're in the hotel business. One of the things you have to do is make sure customers have clean sheets. If you don't change the sheets or launder them properly, you're probably not going to stay in business long. The bad news is that clean sheets are expensive and they don't differentiate you very much—all your competitors have clean sheets. You're stuck.
Consider the following graph plotting the cost of any given business decision against the competitive advantage it brings:
To the right in this diagram are the things we'd call strategic, representing features or practices that differentiate the organization from its competitors. The bottom half of the diagram contains the things that are relatively less expensive. Clearly if you're making a decision on what features to implement, you want to be in the lower right quadrant: low cost and high differentiation. Do those first.
The red quadrant seems like the last place you'd look for features, or is it? Think about clean sheets. As I noted earlier, clean sheets cost a lot of money and everyone has them, so there's not much competitive advantage in having them. But there's a huge competitive disadvantage if you don't. No one can do without clean sheets. Businesses are filled with things like clean sheets. For IT, things like availability, security, networks, and deployment are all clean sheets. Doing these well can differentiate you from those who don't, but they're not strategic. You still need a strategy.
How can you discover the things that really matter? I'm a fan of domain driven design. Domain driven design is a tool for looking at the various domains your business is engaged in and then determining which are core (differentiating), supporting, or merely generic. The things you identify as core are strategic—places you can differentiate yourself. This helps because now you know where to build and where to buy. Generic domains aren't unimportant (think HR or finance, for example), they're simply not strategic. And therefore buying those features is likely going to give you high availability and feature fit for far less money than doing it yourself.
On the other hand, domains that are core are the places you differentiate yourself. When you look at your organization's values, mission, and objectives, the core domains ought to directly support them. If you outsource these, then anyone else can do what you're doing. Core, strategic activities are places where it makes sense to build rather than buy. Spend your time and resources there. But don't neglect the sheets.
Concise, readable, and actionable, Domain-Driven Design Distilled never buries you in detail–it focuses on what you need to know to get results. Vaughn Vernon, author of the best-selling Implementing Domain-Driven Design, draws on his twenty years of experience applying DDD principles to real-world situations. He is uniquely well-qualified to demystify its complexities, illuminate its subtleties, and help you solve the problems you might encounter.
Photo Credit: Sheets from pxfuel (Free for commercial use)