Over the past decade, as Box scaled from a fast-growing startup into a global enterprise, the complexity of our IT environment grew significantly. What were once relatively independent systems evolved into a highly interconnected ecosystem of networks, identity platforms, endpoints, collaboration tools, cloud services, and security controls. Architectural decisions made by one team increasingly influenced other domains, often in ways that weren’t immediately visible.
Our IT organization supports every Box employee and serves as the foundation for how work gets done across the company. From network connectivity and endpoint management to collaboration platforms and enterprise applications, IT enables the day-to-day operations that keep Box running. When these systems work well, they fade into the background. When they don't, the impact can be immediate and far-reaching.
As our environment scaled, cross-team dependencies became more difficult to understand and manage. As institutional knowledge spread across teams, systems, and years of implementation history, questions such as "Who owns this dependency?" or "Why was this decision made?" became harder to answer. Security, Legal, and Compliance (SLC) reviews often surfaced architectural considerations late in the process, and operational incidents increasingly required coordination across multiple domains to identify root causes and restore service.
The challenge wasn't a lack of technical expertise; our teams were highly capable. The challenge was scale. As systems became more interconnected, we needed a better way to create visibility, align architectural decisions across domains, and help teams identify risks before they became operational problems.
That's where ITDAG began.
The hidden challenge: Complexity behind “working systems”
Like many organizations, our IT team is structured by domain — networking, infrastructure, identity, endpoints, and more. For a long time, this model worked well. Teams moved quickly and delivered solutions independently.
But as the company grew, the nature of the work changed:
- More solutions required cross-team collaboration
- Dependencies became harder to track and predict
- Because of this gap in visibility, design decisions in one domain unexpectedly started to impact others
- Questions like “Why was this built this way?” became harder to answer as institutional knowledge became fragmented across teams, systems, and individual contributors.
- Security, Legal, and Compliance (SLC) reviews increasingly became bottlenecks
These issues didn’t always show up during development; they surfaced during incidents. What looked like a localized issue would turn out to be a hidden cross-system dependency. Recovery took longer, not because teams lacked expertise, but because the system itself had become deeply interconnected.
We needed a way to scale decision-making, not just systems.
Introducing ITDAG: A lightweight architecture layer for IT
To address these issues, we established ITDAG (IT Domain Architecture Group), a forum designed to bring structure, visibility, and alignment to architectural decisions across IT.
ITDAG isn’t about adding process for the sake of process. It’s about enabling teams to make better engineering and operational decisions through a lightweight but structured collaboration and review model.
The goal is to help teams:
- Make better-informed design decisions
- Surface cross-team dependencies early and reduce siloed decision-making
- Integrate security, legal, and compliance considerations earlier in the lifecycle
- Create shared understanding across domains
- Improve architectural consistency and documentation
- Build systems that scale more predictably over time
The key principle is simple: design alignment should happen before implementation — not after incidents.
Before ITDAG, architectural discussions often happened within individual teams and domains. While this enabled teams to move quickly, it also made it difficult to identify cross-functional dependencies, align stakeholders, and surface risks early in the lifecycle.
The diagram below illustrates how ITDAG introduced a lightweight architecture layer that improves visibility, collaboration, and decision-making across IT.
By creating a shared forum for architectural review, ITDAG helps teams move from reactive problem-solving to proactive planning, providing the visibility and alignment that are needed to build scalable, well-understood solutions before implementation begins.
How ITDAG works in practice
At a high level, ITDAG introduces a simple but effective workflow:
- A business need, major technology change, or operational incident identifies the need for architectural review
- An initial design or proposal is drafted by the project driver (mainly the project leading team)
- Documentation is prepared using established frameworks such as:
- 4+1: a structured architecture model used to describe systems from multiple viewpoints
- ADR (Architecture Decision Record): a lightweight document used to capture key technical decisions and rationale
- The project driver presents the proposal during an ITDAG review session
- Key domain experts discuss the design, surface dependencies, identify risks, and provide architectural feedback
- The project team refines and updates the architecture based on ITDAG feedback and alignment discussions
- SLC (Security, Legal, Compliance) review follows with stronger technical context and more complete documentation
- Implementation proceeds with shared understanding across stakeholders
This flow helps ensure that decisions are not only technically sound, but also operationally scalable, secure, and organizationally aligned.
ITDAG in action: Enabling passwordless authentication
The benefits of architectural alignment are often easiest to see through real-world projects. One example was a recent initiative to expand passwordless authentication across the company.
At first glance, the project appeared relatively straightforward. Corporate Security identified passwordless authentication as an opportunity to improve both user experience and Box’s security posture. The initial implementation path seemed clear: the Identity team would configure and manage the authentication platform and users would begin adopting the new authentication methods.
But as discussions progressed, it became clear that the change impacted far more than a single system. While the Identity team managed the authentication platform, other services — including VPN access, endpoint authentication workflows, device trust validation, and user onboarding processes — relied on existing authentication mechanisms. Changes to authentication flows could introduce operational, security, and user experience implications across multiple domains. Through ITDAG, stakeholders from Identity, Corporate Networking, Security, and other IT functions were brought together early in the design phase.
Through ITDAG, stakeholders from Identity, Corporate Networking, Security, and other IT functions were brought together early in the design phase.
Rather than evaluating the solution from a single team's perspective, the group reviewed the end-to-end architecture, identified cross-system dependencies, discussed implementation risks, and aligned on operational requirements before deployment planning began. The review also helped determine where Security, Legal, and Compliance (SLC) engagement was appropriate. By involving the relevant stakeholders earlier in the process, teams were able to prepare documentation, address governance considerations, and reduce uncertainty before implementation work was underway.
The outcome wasn’t simply a better technical design — it was a clearer understanding of how the solution would affect the broader IT ecosystem. More importantly, potential challenges were identified during planning rather than during rollout.
This type of cross-functional visibility is exactly what ITDAG was created to enable: helping teams make informed decisions earlier, when changes are easier and less costly to address.
Challenges and lessons learned
Launching ITDAG wasn’t simply a matter of creating a new review process. Like many organizational initiatives, the technical framework was the easy part. The real challenge was driving adoption, building trust, and demonstrating value across teams with different priorities and responsibilities. Since launching ITDAG, several key lessons have emerged through continuous refinement and cross-functional collaboration.
Adoption takes time
One of our earliest lessons was that architectural alignment doesn’t happen overnight.
Many IT teams are accustomed to operating independently within their own domains. Introducing a cross-functional architecture forum naturally raises questions about ownership, decision-making, and additional processes. While the long-term benefits may seem obvious in hindsight, they aren’t always immediately visible to teams that are focused on delivering projects and solving day-to-day operational challenges.
Building trust required patience and consistent execution. Rather than expecting immediate adoption, we focused on helping teams solve real problems, surface hidden dependencies, and reduce rework. Over time, as teams experienced those benefits firsthand, participation grew organically.
Architecture reviews must add value
One of the most important decisions we made was not to position ITDAG as an approval gate. Instead we focused on enablement; every review needed to provide practical value, whether that meant identifying architectural risks, highlighting cross-team dependencies, improving documentation, or connecting project teams with the right stakeholders.
This approach helped shift the perception of ITDAG from an additional layer of process to a collaborative forum for solving complex problems. As adoption increased, teams began engaging with ITDAG proactively, often seeking architectural feedback before major design decisions were finalized.
Leadership sponsorship is critical
Strong leadership support played a significant role in ITDAG’s success. Establishing an architecture forum that spans multiple domains requires alignment across teams, managers, and organizational priorities. Early engagement with IT leadership helped establish a shared understanding of the program’s purpose and reinforced that the goal was to improve decision-making, not create bureaucracy.
Equally important was having credible technical leadership within the forum itself. Effective architecture discussions require broad technical knowledge, strong relationships across teams, and the ability to facilitate conversations that balance competing priorities while driving toward practical outcomes.
Leverage familiar frameworks
Adoption becomes significantly easier when teams aren’t asked to learn an entirely new way of working.
To reduce friction, ITDAG was built around frameworks that were already familiar to many engineers at Box, including the 4+1 architecture model and Architecture Decision Records (ADRs). By leveraging existing practices rather than introducing new methodologies, teams were able to focus on the quality of architectural discussions instead of the mechanics of documentation.
This consistency also improved collaboration by creating a common language for discussing design decisions across different technical domains.
Bring Security, Legal and Compliance into the conversation earlier
Security, Legal, and Compliance reviews are essential for enterprise systems, but they’re usually most effective when architectural discussions occur before implementation begins.
As systems become increasingly interconnected, even seemingly small technology decisions can introduce broader security, privacy, or compliance implications. By creating earlier visibility into proposed designs, ITDAG helped teams identify when SLC engagement would likely be required and prepare stronger documentation before formal review.
The result was a more proactive and collaborative approach that reduced uncertainty, improved decision quality, and minimized avoidable rework.
Culture matters more than process
Perhaps the most important lesson is that architecture is ultimately a people problem, not a documentation problem. Processes, templates, and review meetings are useful tools, but lasting success comes from creating a culture where engineers actively seek architectural feedback, share knowledge across domains, and view system design as a collective responsibility.
Over time, ITDAG evolved from a review forum into a community of practitioners. Engineers began contributing ideas, challenging assumptions, and helping shape architectural standards across the organization. That cultural shift has proven far more valuable than any individual process improvement.
Looking back, ITDAG greatest success hasn’t been the number of reviews completed or documents produced. It’s the creation of a sustainable framework that helps teams collaborate more effectively, make better-informed decisions, and scale with greater confidence.
What we've seen so far
While ITDAG continues to evolve, the impact has been encouraging. The most meaningful outcome of ITDAG isn't the number of reviews we've completed; it's the conversations that are happening earlier.
Since launching the initiative, we've seen stronger engagement across multiple IT teams and increased participation in architectural discussions that previously happened within individual domains. Teams now have greater visibility into how their decisions affect adjacent systems, helping reduce surprises and improve cross-functional alignment. We've also observed earlier identification of architectural risks and dependencies, allowing teams to address potential issues before they become operational challenges. Security, Legal, and Compliance discussions are increasingly taking place earlier in the project lifecycle, resulting in more informed decisions, stronger documentation, and better-prepared reviews.
Rather than treating architecture as a one-time review activity, teams are increasingly viewing it as an ongoing collaboration that supports scalability, operational resilience, and long-term maintainability.
Perhaps most importantly, ITDAG has helped establish a shared architectural mindset across the organization. Rather than treating architecture as a one-time review activity, teams are increasingly viewing it as an ongoing collaboration that supports scalability, operational resilience, and long-term maintainability.
Fast forwarding to today, we've created a scalable mechanism for sharing knowledge and making informed technical decisions across a growing IT organization. As systems become increasingly interconnected, that shared visibility becomes just as important as the technology itself.
While there’s still work to do, we've built a foundation that enables IT to grow and innovate without proportionally increasing complexity and risk.
Next steps
While ITDAG has already helped improve architectural alignment across IT, we view this as a first step rather than a destination. As our systems continue to evolve, we see opportunities to expand architectural collaboration across a broader set of teams and disciplines. Future areas of focus include strengthening partnerships with Security, Legal, and Compliance stakeholders, increasing engagement with business application and platform teams, and creating earlier opportunities for cross-functional design discussions before implementation begins.
The long-term goal of ITDAG is to provide a lightweight and scalable framework that helps teams collaborate more effectively, surface risks earlier, and make better-informed decisions in increasingly interconnected environments.
More importantly, we want to continue building a culture where architectural thinking is a shared responsibility rather than that of any single team or forum. As organizations scale, the biggest challenge is ensuring that knowledge, context, and decision-making can scale alongside the technology itself.
The long-term goal of ITDAG is to provide a lightweight and scalable framework that helps teams collaborate more effectively, surface risks earlier, and make better-informed decisions in increasingly interconnected environments.
As adoption continues to grow, we believe ITDAG can evolve beyond a review forum into a broader architectural community that helps Box balance innovation, operational excellence, security, and scalability as the company continues to grow.
Final thoughts
IT can no longer operate as a collection of loosely connected teams. As systems grow more interconnected, architecture becomes essential infrastructure.
ITDAG is about:
- Making better decisions
- Avoiding hidden risks
- Scaling with confidence
- Aligning across the company
As organizations scale, technology challenges are rarely isolated to a single team or system. Success increasingly depends on the ability to make informed decisions across interconnected domains. ITDAG is our attempt to create that capability at scale — helping teams collaborate earlier, understand dependencies more clearly, and build systems that can evolve with confidence. Because scaling technology is only part of the challenge. Scaling decision-making is what makes sustainable growth possible.
About the Author: Zhen Chen is a Principal Corporate Network Architect at Box, where he focuses on enterprise networking, cloud connectivity, and IT architecture. He is the founder of the IT Domain Architecture Group (ITDAG) and is passionate about building scalable systems and cross-functional engineering practices.
