Tactical Vs Strategic IT Assets

Historically (for a sub-single-century definition of “history”), when thinking Tactical vs Strategic, all software has been treated the same. Organizations use the same decision-making process to select an enterprise-scale database management system as they do to select a webapp framework for a small application. Developers think about the same -ilities for everything they write.

We haven’t usually thought about our IT assets as either strategic or tactical. If we did, we might apply different decision-making rules to each category. Strategic assets pertain to our core business operations; the things that differentiate us in the market. Tactical assets pertain to functions that draw upon core assets, but that are not themselves core assets.

Tactical vs Strategic – Key differences:

• Strategic assets will be with us a long time; tactical assets can come and go with little or no impact on business operations
• To get maximum value from strategic assets, we need to establish a partner relationship with the provider rather than a producer-consumer relationship; we don’t need a “relationship” with providers of tactical assets
• Strategic assets typically house data and algorithms that create competitive advantage for us; tactical assets are typically “windows” into strategic systems or data
• Strategic assets need higher security than tactical assets because of the relative risk of damage should they be breached

One point of view holds that a company’s operations may be data-centric or transaction-centric. This makes a difference in determining which IT assets are tactical vs strategic.

In the majority of companies, data is central to the business model. There are exceptions, but in general, it seems to be the case. A company like Bloomberg, Carfax, or Facebook accumulates massive amounts of data pertaining to a given domain and applies sophisticated analytics to help customers make informed decisions. The customers may differ…investors, car-buyers, advertisers…but the model is conceptually similar.

From that perspective, tools such as the core database management system, the enterprise business rules engine, and the enterprise data warehouse products they select can be seen as strategic assets. Those assets manage the most central part of IT operations. Application systems are, in effect, windows into the data. They read the output from core systems and produce externally-facing information in various forms…HTML, XML, PDF, JSON, CSV, printed reports, etc. Those windows may be tinted (that is, the data are filtered through analytical tools whose internal algorithms are strategic assets), but ultimately they are just windows; they are tactical assets.

It’s faster, easier, and cheaper to replace a window than to replace the entire building in which the window is mounted. But because of the way we make decisions about enterprise software, we make it just as slow, difficult, and expensive to replace a tactical asset as it is to replace a strategic one.

Tactical vs Strategic: Enterprise architecture

The structure of the technical infrastructure can help us treat strategic and tactical assets differently. A convenient starting point for thinking about this is service oriented architecture (SOA).

Most organizations have at least a loose notion of a “boundary” between things that are a little more “internal” and things that are a little less “internal,” even if they don’t have any sort of “formal” SOA infrastructure in place. Many organizations have a far more explicit definition than that. The SOA boundary is a natural line between strategic and tactical assets. Strategic assets live behind that line. They are not accessible in the same way as the tactical assets that live in front of the line.

We need to apply a high degree of rigor to decisions affecting anything that lives inside the SOA boundary. By the same token, to make our tactical assets more like windows and less like buildings, we need to try and pull as much of the strategic functionality as we can out of those assets and move it inside.

A public-facing website shouldn’t be managing network security; strategic security software should handle it on behalf of webapps. Data that flows outward should already be “clean” for public consumption. Data and algorithms that are private to the organization should remain inside the SOA boundary. Only data that is intended for external consumption, and only the output of strategic algorithms, should ever venture outside the SOA boundary.

When focusing on tactical vs strategic details, hacks that penetrate into the outer DMZ should be able to do only limited damage, affecting only tactical assets. That implies tactical applications should be designed to be resilient rather than hardened. Hacking through to the core should be much harder, and strategic assets should be hardened.

Product selection

Because strategic assets will support our business for a long time, we need them to be functional, reliable, and performant. We need them to support our needs specifically. Portability is not a concern. Customizability is of greater interest.

For instance, if we need a strategic enterprise database management system, we will examine products’ special features above and beyond the plain vanilla functionality of a database management system. We will look for a provider that is willing and able to act as a partner rather than just as a sales channel for their product. We need the solution to do everything we need, and to be available and supported at all times.

On the other hand, if a development team is creating a tactical webapp and they need a database management system (that is, other than accessing the enterprise one), there is no reason they must go through the same rigorous product selection process as we used for the enterprise solution. They don’t even have to use the same DBMS as other webapps. If another application needs to access that data, then we can factor the data access into a separate microservice. Each tactical application can be self-contained. We can treat the entire tactical webapp as a “throwaway” item, in a sense. It will not house anything of a strategic nature. To access strategic data, it will make calls through the SOA service layer. It’s a window, not a building.

Replaceability in Tactical vs Strategic:

You’re familiar with the so-called -ilities of software design, a.k.a. system qualities or non-functionals. They’re things like maintainability and accessibility and so forth. Codesqueeze suggests seven of them are especially important. Wikipedia listed eighty-two distinct system quality attributes, as of the date this post was written.

And yet, they’re missing one: replaceability.

For tactical solutions (and please note, I’m referring strictly to tactical solutions here), we should design our applications to be replaceable. Conventional wisdom holds that we make all our applications maintainable. In a world of rapid change, it may be wiser to design for replaceability.

Contemporary software development tooling supports this approach. Tools like Ruby on Rails and Spring Boot, as well as cloud-hosted continuous integration services and automated deployment services, make it a trivial exercise to spin up a whole new tactical application. It’s often easier and faster than trying to “enhance” an existing application. Even some of the underlying infrastructure management tasks, like creating server instances and maintaining consistent logs, are handled under the covers when we use these tools and services. Conventional methods tend to eat up a lot of staff time dealing with such routine matters.

This approach, of tactical vs strategic, enables us to dedicate more of our internal effort to our strategic assets. Those assets will be highly customized and long-lived. They are the assets that provide our competitive advantage. Therefore, those are the assets on which we want our technical staff to concentrate their efforts. To free up their time, we need to make the tactical stuff as easy as possible.