Case study
Dell — conferencing and collaboration
Five years owning voice, conferencing, policies, and app access at Fortune 500 scale. A company that large ran those lanes on a pile of scripts you could not trust, and I turned that pile into one library driven by the database.
Software Engineer II · 2019 – 2024 · Dell Technologies
Before
Voice and conferencing was a Microsoft form to call or host in Teams or Zoom. Same steps copied across scripts. No app review.
After
Voice and conferencing became a ServiceNow request. One library granted the license, number, and policy from the database. Where they sat decided the product. App review behind a gate I ran. An initial 400.
Context
I owned enterprise voice, conferencing, policies, app access, and the app review. I held that remit for a company that used those systems at a very large scale. A footprint that large meant that if those lanes broke, the break came to me. What I built under that ownership was the automation that kept those services running. The same scope also put me in the security-champion seat for a 40-person team: secrets, and whatever cyber sent back.
Constraints
- Company-wide blast radius: voice, conferencing, and access.
- Process changed. Same steps in every script. Miss a copy, the next run is wrong.
- One path: Teams, Zoom, different countries, city codes.
- Business rules as a row the run can read, not another copied script.
- No app review when I took it on. Cyber needed a process they would accept.
What I built
- 1.Lanes — Voice, conferencing, policies, and app access formed the scope I owned.
- 2.Library — The copied scripts became one library, and the process lived there instead of in each copy.
- 3.Rules — I put the conditions in tables so an update is a row, and the code reads the database.
- 4.Inventory — The tables needed a list they could join to: one roster of numbers across providers, pulled from Microsoft, with a schema so they can sit together, and lines that free up are recycled automatically.
- 5.Apply — One command applies the row to the directory, Teams, or Zoom, whatever the record said.
I used the company directory to build the layer that read that identity. That layer joined it to the rules, then ran the process the same way every time.
Hard problems
You could not trust the scripts you inherited
Several scripts had the same steps copied into each of them, so the process was not in one place. Scattered steps cannot take a single update: when the business moved, every script had to change. A missed script kept the old steps, and you spent the next week undoing what that copy had done. That cleanup is why I put the work in one library so the code lived in one place.
The rules had to be data
The business already had the rules, and the written ones moved. A moving target has to live as data the library can read. Some of that data already sat in the database: someone had dumped numbers they bought from a vendor, for a narrow case. I built one inventory across providers, pulled from Microsoft, with a schema so the numbers could sit together, and freed lines return to the pool automatically. The other tables join to that roster: this number, this vendor, this country, a person rather than a service account, then this policy, these directory attributes. The code reads those joins and applies the number, the license stamp, the Teams policy. A churn is a row, not a hunt through every script. That same machine ran conferencing, voice, Teams, as well as Zoom, and only the conditions on the row changed.
There was no app review
When I took it on, there was none, and a request for an app did not pass through a review cyber would accept. I put a governance process with security checks in that gap. I sat at the gate and processed an initial 400 apps through.
Outcome
- Scale
- Voice, conferencing, and access used company-wide
- Before
- A Microsoft form, with the same steps copied across scripts
- After
- ServiceNow, centralized code, database integration, and a polished process
- App review
- A gate I ran. An initial 400.
Close
- What this proves
- I can own a domain at Fortune 500 scale and leave the function more automatic than I found it.
- What I would keep
- The process lives in one library, and the conditions that used to be copied into every script live in the database. One run reads those conditions and does the job that used to be a ritual.