Strategies for Your Digital Infrastructure: Part 1

I should probably start off by saying there are likely more than these nine strategies out there for how to architect a company’s digital infrastructure. Hell, the whole point of strategy is participating in a set of activities that is unique.

That being said, these nine are really a distillation of today’s most common practices. I’ve even seen some companies outright adopt a few of them (sometimes without even realizing it). Others got very close and it would have made their technical operations all the better.

Also, remember that the first objective of any tech strategy should be to mirror or enable the business strategy.

The hard part of that is sometimes (maybe oftentimes), that business strategy is lacking or not very well defined. In those cases, still being able to architect your information technology from a position of predetermined clarity is only going to make things quicker, easier, or more efficient.

Even so, if the strategy is well defined and it’s a matter of enabling it, then I want to give you a place from which to start.

This list won’t go into a whole lot of detail right now. Merely the general idea and potential tradeoffs. But we will explore each one in turn over the course of the next few months.

Cost Effective

General Idea: go for the cheapest options.

This is likely the most obvious one and I won’t mince words here: I hate it. (It might have something to do with my time spent in sales, but I’ve also spent some time in consulting and saw the consequences of choosing cheap.)

To be clear, I haven’t come across many businesses that explicitly state they choose the most “cost effective” option whenever they can, but I’ve come across quite a few that go about this in practice.

It may be worth noting here that “option” could just as easily mean a custom build as a new piece of software, and sometimes building it from scratch or not using out-of-the-box (OOTB) functionality is actually the cheaper option.

I’ll expound on this strategy more in a later issue: its pitfalls, why it results in needing therapy, the times when it’s necessary, even some success stories. For now, let’s just touch on some basic tradeoffs..

Trade Offs:

• Smaller impact on the budget (i.e. better margins), but will typically mean not as much business value being delivered

• It might make you look good in the short term, but in most cases, technical debt is being built along with a patch work of “band-aid” fixes that will have to be dealt with eventually

• It can work at times, but requires either thought-out and tested processes or a longer timeline

Best-in-Class

General Idea: go for the options that are considered to be the best or most robust in their verticals.

This essentially takes a look at your business problems and functions and searches for the best possible solutions for each.

What makes this tricky? Well, what exactly determines the “best possible solution”? It may be you’re just looking for the leader in Gartner’s Magic Quadrant, but what works really well for the company whose name is on the building might be tough to handle by the company that leases the third floor.

What is important here is understanding your capabilities and resources almost as much as your requirements. If you have a large enough budget, you may be able to pull off simply grabbing the #1 option and making it work.

Trade Offs:

• You’ll get world-class software/platforms, but it will cost a pretty penny and may require a lot of adjustments to either the offering or the business process

• You’ll have a lot more relationships to manage (most software/platform vendors have a team of executives assigned to their accounts), but most world-class solutions come with heavy-duty support

• There will be more functionality available, but it will require whole teams (internal, 3rd party, or from the product) to set up, maintain, and integrate

The Lean Stack

General Idea: Use or consolidate your solutions architecture to as few products or platforms as possible.

I’ve been told recently that the term “tech stack” still has a specific meaning to a lot of people in the IT world, so I will likely be more careful with its use going forward, but I still like the name I’ve dubbed this particular strategy.

I sort of borrowed the idea from the supply chain world, where having “lean” processes means reducing waste. It’s not necessarily even about reducing cost, but it is about increasing efficiency.

What makes strategy particularly exciting to me is how possible it is with the array of platforms available in the marketplace. SAP, Salesforce, Microsoft, Oracle, even Hubspot all give you options for a good portion of the needed business functions.

Trade Offs:

• Might not get the best functionality available for every part of the business, but it reduces the “swivel-chair effect” (i.e. fewer tools your employees have to worry about)

• Fewer vendor relationships to manage, but major platforms can get pricey the more products you add on (packaging helps here)

• You still need teams to maintain or update, but the number of software applications to maintain is reduced

• You get time back, but will require focus early

DIY

General Idea: Having an internal team build solutions for almost every problem or function.

In this context, “do-it-yourself” doesn’t necessarily mean building everything from scratch. Platforms like Salesforce are designed to be modular so that, if push-comes-to-shove, you can “build” a solution with the tools the platform offers.

Really, DIY is another take on “cost-effective”. How many people do you know in your life that are intent on fixing their own car or rebuilding their lawn mower or tiling their kitchen? They may be able to effectively do all those things and it is probably cheaper, but what does it cost them? Time.

If you happen to have a team whose sole purpose is to build out new functions on Salesforce, then great! But what about inevitable bugs, maintenance, and needed updates?

Trade Offs:

• The software spend is theoretically less, but requires personnel with full stack capabilities, and then some

• You won’t have the benefit of pulling from expert resources, but those expert resources can be expensive

• More risk with custom builds, but with builders being internal, they will already be around to handle bugs or fixes

• These scenarios require time, so there is an opportunity cost (i.e. what could these IT teams be doing besides this to support the company?), but you have more control over the end solution