How and Why You Should Audit Your Organization's Tech Stack

At some point in your career as a Mac admin, you’ll have to audit your organization’s tech stack. Your org might perform such audits on a regular schedule or whenever major software contracts are up for review. You might be asked to lead the project or just to assist. In either case, here’s what you should know about how such audits can and should work.

Why Audit Your Tech Stack?

Auditing or evaluating your tech stack means asking many questions. The most essential: What software and services is your organization using? And which of those do you really need?

Those two questions raise, in turn, a host of other issues, including:

• Duplicates: Does your organization have two (or more) software tools that do the same thing when one might suffice? (Spoiler alert: This isn’t always an either/or decision.) 
• Effectiveness: Are the tools you’re using still getting the job done? Are you using those tools to their full potential? Could a new tool do more? Do any of your tools do more than you need?
• Budget: Could you save money—on direct software costs, but also on training and support—if you culled the stack? Could a new tool do what you need for less? Could you find an alternative that’s a better fit for your needs and your budget?

The specific questions you need to ask depend in large part on who asked for the audit in the first place. 

Is your CFO demanding that the company cut software spend, and it’s up to IT to propose those cuts? Is it coming from the CTO, who says it’s simply best practice to audit regularly? Or is it coming from the CEO, who wants to make sure the organization is running as lean as possible? Whoever asked for the audit will define its focus and its deliverables.

To be clear, this isn’t about security or compliance reviews. Those have their own unique sets of questions, goals, and processes. For now, we’re talking just about those two primary questions above.

What Are You Going to Review?

But before we go any further, let’s be clear about what exactly we mean by a “tech stack.”

What’s in Your Tech Stack?

Old schoolers will say the phrase “tech stack” has a specific meaning derived from the world of app development: Traditionally, it refers to the suite of technologies used to develop and run a web application, including programming language, database, web server, front-end and back-end tools, and APIs.

However, the term has been coopted by others to refer to any suite of tools that a business uses to get its work done. It’s often used in a departmental sense: there might be a marketing stack or a sales stack. Then there are the organization-wide tools that everyone in the business uses—things like email, calendaring, chat, productivity, identity, and security. In the loose-but-common sense of the term, “stack” can mean all of the software in use in the organization—which makes auditing it that much harder.

How the Tech Stack Has Changed

Further complicating the question of what to review is the fact that software now comes in many forms.

In the old days, IT departments were solely responsible for buying and deploying the software their organizations used. That made it relatively straightforward to inventory and evaluate it all. 

However, that monolithic model was never really accurate: Even in those old days, users unofficially installed and used other apps that then escaped scrutiny. 

SaaS has made such shadow IT more prevalent: Now, anyone with a browser and an email address can adopt tools that might replicate or augment whatever official solutions IT provides. Individual departments now typically decide which tools best meet their needs; SaaS products work particularly well at the team level. 

Don’t be fooled by the fact that some such tools are free. Unless you’re auditing solely for the purpose of reducing spend, they need to be included in an audit, because they still have consequences—licensing agreements or intellectual property controls—that an IT team needs to know about.

An audit can be an opportunity for the IT team to find out which tools are actually in use. It’s a chance for IT to discover, rather than define, what’s in use out there. 

How to Audit the Tech Stack

There are many sources of truth for that discovery process.

One is finance. What are your accountants paying for? 

SSO is another. Ideally, you’ve already folded those SaaS products into your single sign-on infrastructure. You can also see which services people are signing into using their corporate identities. There are third-party tools that can do this sleuthing for you.

Don’t neglect old-fashioned human intelligence. Ask department heads what tools their teams use. Ask end users, too, via polling or other means, what tools they use. Put a positive spin on it: Do you use any tools that you think would help the company if adopted more widely? Which ones do you find less useful? You’ll get good intelligence, and you can provide some transparency about the process; people get worried when they think IT is going to take their tools away. 

It’s important to start those conversations early, in the discovery phase, because they’re just the beginning of a dialog that will extend into evaluation and decision-making. You can’t revise the company's stack without their help. Better to bring everyone, from team leads on down, into the conversation from the jump. 

Practicing IT isn’t just about technology these days; it’s just as much (if not more) about communication. Keep that in mind throughout any audit process. Whatever the impulse behind the audit, wherever that ask is coming from, treat this as an opportunity to have conversations that you might not have otherwise.

When to Do the Audit

As we said up top, some organizations perform audits on a regular schedule. If your IT leader initiated the audit, chances are it’s because it’s on their calendar. 

The ask may be tied to the annual budgeting calendar: perhaps you’ll be asked to cut—or increase!—the software budget by X percent in the coming fiscal year. 

Audits may also be timed by software lifecycles. If your organization leans heavily on a small set of software tools, their contract end dates could be triggers for a reassessment of everything in the stack. 

Whatever the triggering event, you need to let everyone know that such audits take time. They aren’t something you want to rush through. You need time for both the discovery phase described above and the assessment phase that follows.

Assessing Your Tech Stack

Once you’ve discovered which software tools are in use, it’s time to assess. While the exact analysis will vary from organization to organization, it helps to ask two basic questions.

Do You Have Duplicates?

One of the most typical—but important—findings of a tech audit is that your organization has multiple tools doing the same thing. Take project management, for example. Your engineers might be using Jira, while marketing prefers Asana or Wrike. One team might have adopted Miro as a collaborative whiteboard, while others use FigJam.

Your immediate impulse might be to standardize on just one tool. That’d certainly be easier for IT: It’d be one less tool to help manage and configure, one less tool to monitor for security and compliance, one less tool to integrate into SSO. (Chances are that if those departments adopted such tools independently, they’re paying for them out of their own budgets.)

But before you do anything, you need to initiate a conversation that includes all of those team leaders, “Hey, I've noticed that three of our teams are using three different tools to do essentially the same thing. Maybe we could consolidate on just one?” 

Then it’s on them to have that conversation among themselves; you’re just the prod. They know how they're each using that tool better than you do. They know what their teams’ requirements are. They know what they could compromise on. But if you didn't ask the question, they might never have had that conversation.

As we said above, if you do find duplication, it’s not necessarily an either/or decision. Sure, settling on just one tool could make things marginally simpler for you. But the fact is that marketing teams aren’t likely to adopt Jira to track their campaigns (though it could work). Ditto for engineers and Asana. Such tools have entirely different interfaces, workflows, and ways of presenting data that work better for some teams than others.

In these conversations, it helps to differentiate between the efficiency of a tool—doing something in one tool might take two clicks, while it takes six in another—and the fact that people have learned to be effective with one or the other. You have to take into account the learning curve a new tool requires—both for users and for the IT team. One tool might be easier than another on paper. But if a team has evolved all of its workflows around the more complex one; switching would still be painful.

Yes, you need to take costs into account—not just the yearly fee for the software itself, but the cost of supporting and training people on it. But unless the audit is being driven by accounting, that isn’t necessarily your top priority.

Is There Something Better?

The other big question to address in an audit is, in many ways, simpler: Are the tools you have in place now doing what you need? Could something new do it better?

The answer can change over time because (a) your needs have changed or (b) the software hasn’t. Perhaps your organization is branching out, getting into new products or workflows, either of which can demand new tools. More likely, the old tools you’ve been using for years may have fallen behind the functionality of newer ones that can do more. 

This is another opportunity to have a conversation with team leaders about the tools they’re using. The main questions: How much of the functionality of a given tool does your team use? Did you know about this alternative, which can do all that and more? How hard would it be for you to switch? How embedded are you?

Updating Your Tech Stack

Once you’ve had all those conversations, it’s time to do some calculations.

That can start with filling in a spreadsheet: 

• Column A: All the tools you found in your discovery phase.
• Column B: What the organization and its individual departments are using those tools for.
• Column C: The percentage of each tool’s overall functionality that’s being used. 
• Column D: How important that tool is to each team. 

This exercise should help you identify which apps and services are carrying their weight and which ones you might be able to drop or replace. 

If you have a compelling reason to switch—if, say, you’ve been given a mandate to cut costs—then it’ll be time to go back to the individual team leaders to say, “Look, this alternative can do 90 percent of what you need, and I’ll help you find a solution for the remaining 10 percent.” 

This entire discussion assumes that you can even make such a switch. You might be locked into a multiyear contract (though competitors will often offer buy-out options). Or the alternatives might not meet your security requirements, or they’re missing crucial functionality. Identifying those disqualifiers is critical.

Ultimately, for each tool, you need to ask yourself: Should we keep things as they are? Should we push the entire organization to settle on a single set of tools? Is it worth it to replace the tools we have with something better?

One other outcome of these exercises: Tools that have been casually adopted at the team or department level can be formally incorporated into the organization’s stack: vetted for security and compliance, and incorporated into the single sign-on infrastructure.

The point is less that IT should dictate which tools those teams and departments should use and more that IT should give leadership visibility into what those tools are and make sure they’re being used wisely. An audit of the tech stack is a first and necessary step in that direction.

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints, with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.