Make Complex SystemsEasier to Changeand Safer to Scale
I help technology and engineering leaders understand architectural risk, plan platform changes,
and improve reliability—so the business can keep moving while its technology evolves.
Architecture that supports the way your business grows.
I'm Bence Roth, a technology architect. I help organizations understand systems that have become difficult to change, operate, scale, or secure.
My work includes enterprise platforms, security and identity, platform modernization, and technology integration after acquisitions. I help teams understand their options, weigh the trade-offs, and decide what needs attention first.
Good architecture makes day-to-day work more predictable. Teams understand how systems depend on one another, releases are easier to plan, and changes are less likely to cause problems elsewhere.
FocusEnterprise platforms, security and identity, platform engineering, and acquisition integration
DeliverArchitecture recommendations, migration plans, decision briefs, and clear ownership
ImproveReliability, maintainability, operational risk, and confidence in technical decisions
We start by understanding the problem, the constraints, and the outcome you need. From there, we agree on practical next steps based on your priorities, timeline, and tolerance for risk.
2–4 Week Architecture Assessment
A structured review of your current architecture, its main risks, and the options for addressing them. You'll get a clear basis for deciding what to change, what to keep, and what to do first.
If you're planning a platform change, preparing for an acquisition, or trying to understand the risks in a complex system, let's discuss what you need and how to approach it.
Architecture Review·Platform Modernization·Technical Due Diligence·Security Architecture
How an engagement starts: We typically begin with a 2–4 week architecture assessment. Depending on your needs, the work can then continue with technical advice, modernization planning, or part-time architecture leadership.
01Architecture risk map
02Options and next steps
03Decision brief
An initial conversation is a chance to discuss your goals and constraints. Discussions are confidential.
A global enterprise acquired an organization with 3,000 employees and needed to integrate their identities and access quickly. Security, compliance, and access to business systems all had to be addressed without disrupting ongoing work.
Challenge
The existing provisioning tools were built for a slower pace and could not easily handle a large wave of new users. The integration needed to happen in weeks rather than months, while protecting existing services and meeting compliance requirements.
Architecture Decisions
I designed a cloud-native onboarding platform rather than extending the legacy provisioning stack. The main decisions included:
Automated provisioning workflows with policy-based access assignment
Secure workflow orchestration with fewer dependencies on legacy systems
A self-service access portal to reduce routine work for IT teams
A modular design that could be reused in future acquisitions
Trade-offs
The delivery deadline required a focused first release. I prioritized getting people the access they needed safely, then left room to add capabilities without replacing the initial platform.
Outcomes
More than 60% reduction in onboarding time
No outages reported during the integration
Compliance validation automated from the start
Less manual onboarding work for IT teams
A framework that could be reused for later acquisitions
What I Learned
A modular design made it possible to meet the immediate deadline without creating a one-off solution. The resulting framework could support later acquisitions as well.
An enterprise wanted to bring important digital operations back in-house. After years of outsourced management, costs were increasing, turnaround times were slow, and internal teams had limited visibility into how key workflows operated.
Challenge
The organization needed to regain control without putting critical services at unnecessary risk. Vendor dependencies made the transition sensitive, and the existing tools provided limited visibility into service performance and incidents.
Architecture Decisions
I designed a cloud-first automation platform integrated with ServiceNow. The approach included:
Event-driven processing for timely request handling
Governance controls and audit trails to support compliance
Monitoring and alerting to replace opaque, vendor-managed operations
A phased migration with parallel running to reduce cutover risk
Trade-offs
Running the old and new arrangements in parallel increased short-term costs. It also gave the team time to validate the new service before switching over, which was important for critical operations.
Outcomes
More than 2,000 requests processed per day
Faster incident detection and response
Lower infrastructure costs through more efficient resource use
Operational responsibility returned to internal teams
An architecture designed to support evolving regulatory needs
What I Learned
Bringing critical services in-house is an organizational change as well as a technical one. The design needed to support knowledge transfer and internal ownership, not just deliver a new platform.
Security Design for 10,000+ Applications
Zero Trust · Application Security · Enterprise-Wide Enablement
Situation
A multinational organization was working toward a zero-trust security model across a portfolio of more than 10,000 applications.
Challenge
The challenge was not only the number of applications, but also the number of teams responsible for them. Application owners needed to make consistent security decisions without turning the process into a bottleneck for development and delivery.
Architecture Decisions
I designed a security enablement platform to help application teams understand and act on their security responsibilities. It included:
An interactive portal with graph-based security assessments
Automated notifications and chatbot guidance
Support across the application lifecycle, from classification to remediation and verification
A self-service model to reduce dependence on a central review team
Trade-offs
A self-service approach meant adoption would take time. The benefit was that teams could get guidance while doing their work, rather than waiting for every decision to pass through a central team.
Outcomes
Reduced security onboarding time for development teams
Increased deployment frequency among participating teams
Better visibility into application risk across the organization
A shift toward considering security earlier in design and delivery
Improved developer experience and delivery flow
What I Learned
Security programs are more likely to gain lasting adoption when they help delivery teams make good decisions with less friction. The platform was designed to make that support part of normal engineering work.