Blog Post

User Blogs
3 MIN READ

Complexity Creeps. Let’s Audit It Before It Breaks You.

Allynz's avatar
Allynz
Puritan
20 days ago

Last time we talked about Conway’s Law—how your messy org chart creates messy architecture. You nodded. Maybe even laughed. Then the real question hit: How do we fix it?

Here’s the truth: complexity isn’t something you “rip out.” It’s something you unwind, one step at a time. Incremental change I always say. That’s what I’ve done across enterprise IT, consulting, and now in my role at Pure. And I am here to say it starts with visibility. And most of all, honesty.

Step 1: Know What You’re Actually Dealing With

I have talked with many IT admins and leaders over my time in consulting and working for the manufacturer. Most teams think they have a handle on their environment—until they map it. Not addressing this is what usually leads to the complexity.

Start with discovery, not decisions.

Look beyond the app list:

  • Why does this system exist? not just what the vendor says
  • How is it actually being used?
  • What’s integrated? officially and unofficially
  • Where are the redundancies?

Then build a complexity heatmap. Rate each system 1–5 on:

  • Strategic importance
  • Technical debt
  • Redundancy
  • Integration fragility

It doesn’t need to be scientific—just enough to move from assumptions to evidence. I've seen teams uncover backup sprawl, three identity systems doing the same job, or tools left running for years because no one wanted to ask who owned them.

A Pure example. Fusion’s Fleet Management —one control plane for visibility across your arrays. Consider it a live inventory that doesn’t depend on tribal knowledge.

Step 2: Prioritize What’s Worth Fixing

Once you map it out, you’ll want to fix everything. Don’t.

Start by asking:

  • Effort vs. impact? Go for quick wins that move the needle.
  • Does this fix cascade? Consolidating cloud platforms might reduce tool sprawl downstream.
  • Is this making security worse? The more parts, the more seams to manage.
  • Where’s the pain? Track things like:
    • Hours spent maintaining glue code
    • Outages from brittle integrations
    • Feature delays due to siloed systems
    • Cost of tools that require hard-to-find skill sets

You don’t need a big framework—use colored stickies. I am a huge fan of whiteboards to visualize these relationships. Make it work for you an your team. 

Step 3: Make It Happen (Don’t Let Execution Kill It)

Execution is where most simplification projects stall. Not because of bad ideas—but because they’re too vague or too big.

Instead, define tight, time-boxed goals:

  • “Consolidate from three monitoring platforms to one by Q3”
  • “Migrate backups to cloud-native by year-end”
  • “Eliminate on-prem CI/CD pipelines by Q4”
  • "Reduce the black-hole effect

    in an RFP systems"

Build your cleanup crew:

  • Executive sponsor with budget
  • Tech leads who understand the mess
  • Business stakeholders who know what matters
  • A PM who can say no to scope creep

Expect resistance. Plan for it.

  • Use audit data to keep the conversation objective.
  • Document what’s really required vs what teams prefer.
  • Build transition paths—not tool cliffs.

Throw a metaphorical or actual retirement party for a legacy system. Turns out saying goodbye feels a lot better when it’s acknowledged.

Step 4: Prove It’s Working

If you can’t measure the impact, you’ll lose momentum (and support).

Track real simplification metrics:

  • Complexity counts – # of vendors/tools, integration points, exceptions
  • Ops impact – Incident resolution times, deployment speed, effort spent maintaining glue code
  • Cost – Licensing, support contracts, niche skills
  • Leading indicators – Shadow IT, “temporary” workarounds, requests to bypass standards

Show a clear before-and-after. Another Pure example something like Fusion + Pure1 shines: central visibility, consistent policy, and insights that cut through the noise.

Step 5: Keep It Simple

The hardest part? Not simplifying once—it’s staying simple.

Here’s how:

  • Architectural guardrails – Tool approvals, regular reviews, budget for technical debt
  • Cultural support – Reward simplification, share success stories, tie it to performance
  • Clear messaging – Less complexity means faster delivery, fewer outages, and a happier business

This isn’t about making IT prettier. It’s about making IT deliver.

Final Thought: Start Small, Win Big

Pick one app. One silo. One integration that always breaks on Friday afternoons. Fix that first. Show the win. Build the case.

Conway’s Law isn’t going away. But you can meet it with structure, visibility, and simplicity on your side.

But it is time to choose simplicity.

💬 Your Turn

What’s your biggest simplification headache? Drop it in the comments—or reach out. 

Updated 20 days ago
Version 2.0

3 Comments

  • Nice post Zane, goes back to keep is simple, make it better after every touch, retire tech debt and processes, get buy-in and support from management, if not start from the "basement" up. :) 

  • Great post, simplifying the complexity is also the first step in any operational or cyber resilience strategy as well. What are your critical apps and their interdependencies to build a minimal viable business should you need it.

  • Ludes's avatar
    Ludes
    Community Manager

    Fun read Allynz - what's an example of this situation that you tackled at some point in your career to provide some color and background to this?  Left unchecked, organizations do seem to take on too many tools, often with overlapping capabilities and end up with a glut of technical debt and inefficient use of resources (hint: it's something the Community team took on that resulted in us getting to this platform).  

    thanks for taking the time to submit again - look forward to reading more in the future.