Here's a flash of the blindingly obvious: More and more products are going digital. You know this, but what I'm interested in is how they are going digital and to what degree. I see three major aspects: (1) the product itself becomes digital; (2) a physical product adds digital technology; and/or (3) processes and context around a physical product become digitally infused. Let me offer a sort of continuum of examples, and then I want to ask a question:

• Music (nearly 100% digital). The greater part of music bought these days is in the form of a 100% digital product. 
• Health band. With a health band (e.g., Fitbit, Nike FuelBand), I don't really care about the physical product, but I'll put up with it to get the digital benefit: lots of data (and more) about my workouts and health.
• Cameras. A digital camera is a physical product that uses a combination of physical and digital technology, and I actually care about some of its physical design (e.g., lenses). It produces a 100% digital artifact (photos), and the process around the photos is digitally infused.
• USB picture frame. Part physical, part digital. By replacing the center of a picture frame with a digital screen, I get a new twist on an old standby. But, working with the digital part still requires a high degree of physical manipulation (carry a USB drive to the frame, etc., etc.).
• WiFi picture frame. Part physical, even more digital. The WiFi bit bumps it way above a USB picture frame in terms of seamless integration into a digital world. I can email a picture to the thing, or maybe tag a photo on Facebook and suddenly it shows up.

Social networking is hot, and it’s smart to think about how your organization might use it to generate benefit equal to the market hype. As you develop your social technology strategy, it’s particularly important to steer clear of a fallacy of thought that often creeps into technology strategies for enterprise communication and collaboration.

Oftentimes, an enterprise social strategy, like enterprise collaboration strategies before them, will have among its goals a phrase suggesting that the technology should “change the way people communicate.” Superficially, this phrase may accurately describe part of the effect, but at a more fundamental level, it violates a very important change management principle. To make my point, I’ll back up and start with a little history.

I used to communicate via paper memos and phone calls, but it was cumbersome and time-consuming. Email has come to replace much of that. So, the “way I communicate” has changed, right? On the face of it, yes, but, looking more closely, not really, at least not at first. Compared to my “before email” days, I still communicate the same types of things with the same kinds of people — only email made these communications easier (for the most part). I started using email because (1) it could improve the existing way I communicated and (2) it fit my work and life context — it was just a new program to use on my handy desktop PC. Once email became part of my context, I realized that I could use it for communications that were too costly before. At this point, it did, to a degree, change the way I communicate.

Can you remember a year when your business both (1) grew in a healthy way and (2) changed more slowly than the year before? Besides a company’s early startup years, such would be the exception, not the rule. So, in 2011, your business is likely to continue accelerating its pace of change. A recent Forrester report, The Top 15 Technology Trends EA Should Watch: 2011 To 2013, named both business rules and SOA policy as items for your watch list — because both of them help accelerate business change.

Back in the mainframe days — and even into minicomputer, client/server, and Web applications — nearly all of the business logic for every application was tightly wrapped up in the application code. A few forward-thinking programmers might have built separate parameter files with a small bit of business-oriented application configuration, but that was about it. But, business changes too quickly to have all of the rules locked up in the code.

Some have tried the route that businesspeople ought to do their own programming — and many vendor tools through the years have tried creatively (though unsuccessfully) to make development simple enough for that. But, business is too complex for businesspeople to do all of their own programming.

Enter business rules, SOA policy, and other ways to pull certain bits of business logic out of being buried in the code. What makes these types of approaches valuable is that they are targeted, contained, and can have appropriate life cycles built around them to allow businesspeople to change what they are qualified to change, authorized to change, and have been approved to change.

As I discuss with clients the developing notions of Forrester's Business Capability Architecture (see blog post #1 and blog post #2), I have found it important to distinguish between different levels of scope for technology strategy. The primary distinctions have to do with (a) the degree to which a strategy (and the architecture it promulgates) aims to account for future change and (b) the breadth of business and technology scenarios addressed by the strategy.

Thus, I define a four-part technology strategy taxonomy along a two-dimensional continuum with (a) and (b) as axes (IOW, the four parts are archetypes that will occur in varying degrees of purity), to wit:

• Type 1: project strategy for successful solution delivery. With Type 1 strategy, the goal is simply to achieve successful project delivery. It is beyond the strategy’s scope to consider anything not necessary to deliver a solution that operates according to immediate business requirements. Future changes to the business and future changes in technology are not considered by the strategy (unless explicitly documented in the requirements). The classic case for a Type 1 strategy is when an organization definitively knows that the business scenario addressed by the solution is short-lived and will not encounter significant business or technology change during the solution’s lifetime (history argues that this is a risky assumption, yet sometimes it is valid).

In discussions on cloud computing, I often talk to architects who have been told to create a "cloud strategy." This sounds appropriate enough, but there’s a devil in the details: When the task is "create a Technology X strategy," people often center strategy on the technology. With cloud, they aim to get a good definition of pure cloud and then find places where it makes sense to use it. The result is a technology strategy silo where cloud is placed at the center and usage scenarios are arranged around it. The problem with this is three-fold:

1. Considering the full business dynamics of any given usage scenario, there is a wide continuum of often strongly competing alternatives to pure cloud (including cloud-like and traditional options).
2. The rapid pace of market development means that business value equations along this continuum of options will keep changing.
3. Your business needs integrated strategy for many technologies, not simply a siloed cloud strategy.