Strategic and Tactical IT Assets

综合技术 2017-09-06 阅读原文

Historically (for a sub-single-century definition of “history”), 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.

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 strategic and which are tactical.

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.

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.

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

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 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.

LeadingAgile

责编内容by:LeadingAgile阅读原文】。感谢您的支持!

您可能感兴趣的

2017年软件漏洞数量将破纪录 越来越多的软件程序和不断增加的报告,让漏洞报告比2016年增加了1/3强。两家追踪漏洞披露的组织表示,2017年见证了软件漏洞报告的激增,即将成为破纪录的一年。...
Webinar Wed 7/19: MongoDB Sharding Please join Percona’s Senior Support Engineer, Adamo Tonete as he presentsMong...
如何绕过windows 2008 R2身份验证? 本文我将为大家介绍一种,绕过Windows Server 2008 R2服务器的身份验证以及重置系统管理员密码的技术。此技术几乎适用于所有的Windows系统,...
mpvue小程序《校友足迹》成长记(一) 小程序体验 灵感 小程序开发进行的热火朝天,自己申请小程序账号也有一段时间了,但是一直没有有所作为,苦于没有一个好点子,不知道该做些什么,基本...
密码管理器1 Password纳入新功能:无需透露密码即可检测密码是否泄漏... 广受用户欢迎的密码管理器 1 Password 近期加入了新功能,可以不输入完整登陆凭证(不传输到服务器),就可以检查出用户的密码是否已经泄露。 ...