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).
- Type 2: project strategy for ongoing solution success. With Type 2 strategy, the organization knows or assumes that business and technology will change during the lifetime of the solution and specifically builds the solution’s architecture and strategy to account for this dynamic. However, the business scenario is treated as a silo separate from other business scenarios, and thus the project strategy is treated as a separate silo as well. To better accommodate future change, the strategy may incorporate various tech trends — SOA, BPM, events, embedded analytics, etc. — but the strategy considers the architecture and infrastructure of the solution’s user interface, processes, business rules, data requirements, connections to other solutions, collaboration needs, and other design elements only within the bounds of the immediate business scenario. There is no coordination of design or strategy between the project's solution and the solutions for any other business scenarios. The classic case for a Type 2 strategy is when a business scenario is truly siloed and separate from other business scenarios. As with Type 1, history argues that this is a risky yet sometimes valid assumption.
- Type 3: enterprise strategy for specific implementation. To guide multiple projects toward a common end point, an organization may build a Type 3 tech strategy around a specific technology or business goal (e.g., "Where should we apply cloud computing technology?" or "How can we improve customer service ratings by 10%?"). A Type 3 strategy aims to achieve a specific future state beyond which change is out of scope (understanding that the strategy may exist to implement a technology that aids in dealing with certain types of change). The strategy may integrate its target technology or business scenario with existing technologies and solutions, but it does not seek to anticipate future technologies or business changes. Within the bounds allowed by a Type 3 strategy, the sequence of projects required to achieve its end state may be conducted using Type 1 or Type 2 strategy.
- Type 4: enterprise strategy for ongoing business success. Beginning with the assumption that both business and technology will change in unknown and unanticipated ways, a Type 4 tech strategy aims to facilitate ongoing business improvement ranging from small optimizations to large transformations. Thus, rather than focusing on specific business changes, a Type 4 strategy focuses more generally on business change itself and how to facilitate it. To this end, it guides the evolving design and implementation of business and technology structures to (a) define and measure business outcomes, (b) analyze outcomes to develop and prioritize ideas for business improvement, and (c) efficiently and effectively carry ideas forward into the business and technology changes necessary to deliver measured business improvement. The preponderance of projects resulting from a Type 4 strategy would use a Type 2 strategy. Elements of Type 4 strategy are embodied in the flexibility of industry directions such as SOA, BPM, and the like, although each can be pursued with a lesser type of strategy.
While an organization may or may not use Type 3 or Type 4 strategies, every solution delivery project falls somewhere on the Type 1–Type 2 continuum, whether its strategy is implicitly or explicitly defined. If it exists, a Type 3 or Type 4 strategy will bound and shape a project's Type 1/2 strategy by, for example, establishing project requirements that connect and integrate the project with other technologies and business scenarios. Without a Type 3/4 strategy, the project is, by and large, left to its own siloed boundaries.
Furthermore, Type 4 strategy will bound and shape a Type 3 strategy, giving the Type 3 strategy the context required for it to contribute coherently to a broader base of the organization's business and technology evolution. For example, in relation to my recent blog post "Get A Strong Focus For Your Approach To Cloud," a dedicated cloud strategy is a Type 3 strategy, whereas the Type 4 strategy is my recommended approach of building cloud options into your existing infrastructure, application platform, and solution portfolio strategies. Around a Type 3 strategy’s focus on specific business plans, a Type 4 strategy sets a context to account for continuous change to the business plans themselves.
Forrester’s Business Capability Architecture and Digital Business Architecture guide the development of an organization’s Type 4 technology strategy. Each of the four strategy types is important, but without Type 4's bounding guidance, Types 1 to 3 lead to siloed architectures that, Forrester believes, create avoidable barriers to business change.
How, or how well, does your tech strategy account for continuous business and technology change?
Acronyms: SOA = service-oriented architecture // BPM = business process management // IOW = in other words 🙂