Platform Engineering for Internal IT Operations

Introduction

This platform brings a shared lifecycle, validation, integration and interaction model to IT operations across five business domains: DNS, firewall, folder permissions, procurement, and employee onboarding. It replaces what were five disconnected ad-hoc forms and email threads with one architecture that every domain plugs into: one lifecycle model, one validation approach, one integration layer to the ticketing system, one interaction pattern. What makes it different is the perspective behind it: a request is treated as structured, traceable business knowledge with a lifecycle and a history, not a page with a submit button, a view shaped by a background in data engineering before moving into DevOps and platform engineering. I own this platform's architecture and have built the majority of its implementation.

Business Challenge

Before this platform existed, IT operations ran as five unrelated processes, DNS, firewall, folder permissions, procurement, onboarding, each its own ad-hoc form or email thread: individually solvable, but symptomatic of a deeper architectural gap.

• No shared entity or lifecycle model, so "status" and "history" meant something different in every domain.
• No traceability into the ticketing system: a request's real-world outcome depended on someone remembering to check a separate tool.
• Validation and duplicate-detection logic reimplemented per domain instead of shared.
• Real dependencies between domains left to manual coordination: a server request implying DNS and firewall setup, an onboarding implying hardware and software, with no structural link between them.

The underlying problem wasn't that any one process was broken; it was the absence of a common platform for all of them to sit on.

My Role

Business & Domain Analysis. I translate operational IT processes, DNS management, network access, procurement, employee onboarding, into structured, testable domain models, starting from what the business needs to track before any code is written.

Platform & Architecture. I designed the pattern this platform reuses across every domain: persistent entities with explicit lifecycles, a shared audit trail, a shared ticketing integration, and a clear boundary between platform-owned and externally-synced data (see Architecture, below). This foundation, and how it evolves as new domains are added, is my responsibility.

Software Engineering. I build the Django application logic, forms, services and integrations across all domains, and maintain the shared components, validation, normalization, duplicate-detection, document generation, every domain depends on, backed by an extensive automated test suite, including the entity-centric interactions under User Experience. Frontend work is part of this, secondary to the domain and backend architecture.

DevOps & Operations. Beyond development, I operate this platform: containerized builds across development, test and production, environment and configuration management, CI/CD tooling, and feature-flagged rollout of capabilities such as directory-service authentication and live ticketing integration. I also contributed to the current authorization model and the direction for a fuller role-based access layer.

Architecture

The platform is built on one recurring idea: model the business concept, not the form. Every request domain, DNS, firewall, folder permissions, procurement, employee lifecycle, is a variation on the same underlying pattern rather than a bespoke screen.

• Persistent entities with explicit lifecycles. A request is a first-class object moving through defined states (draft, submitted, updated, resolved), not just a row rendered by a form, which is what makes it auditable, reportable and safe to automate around later.

• Pages as projections, forms as mutations. Views read from the entity; only a dedicated service layer writes to it, keeping business logic out of templates and routing every mutation through the same validation and audit mechanism.

• A versioned audit trail as a first-class concept. Every domain stores a full version history with a human-readable diff of each edit: if you can't reconstruct why a state changed, the lifecycle model is incomplete.

• A hard boundary between owned and externally-synced data, feeding one normalized view. Platform data and data synchronized from the OTOBO ticketing system live in separate schemas, a data-engineering habit as much as a Django one: source-of-truth and reconciled data should never share a table.

  Internal request entity → OTOBO ticket → status and lifecycle events → normalized timeline on the detail page
  

  This is what lets the detail page present external progress as one coherent picture rather than a raw feed; its user-facing form is the OTOBO timeline (see User Experience).

• Reusable services over duplicated logic. Duplicate-request detection, normalization and PDF generation are each implemented once and consumed by every domain: more upfront design per service, but improving one improves every domain at once.

• Explicit relationships instead of hidden coordination. Where one domain's request should produce another's, a server request generating DNS/firewall requests, onboarding generating procurement requests, that relationship is modelled directly rather than left to a human filing a second ticket. The long-term direction is a full joiner-mover-leaver model, so every resource tied to an employee traces back to their lifecycle record.

• Lifecycle transitions triggered by actors outside the platform. Some decisions belong to a stakeholder who isn't a platform user, an approval only a resource owner can make, and forcing a login for one decision is the wrong trade-off. The platform extends secure, single-use, time-limited access to that action alone, while the decision still flows through the same service layer, audit trail and ticketing integration as any other transition (see Delegated Approval). Who triggers a transition never changes how it's recorded.

Individually, several of these choices cost more than "just build the form." The bet is that platform thinking, one lifecycle model, one validation layer, one integration point, compounds: each new domain gets cheaper to add, and each shared-service improvement pays off everywhere at once.

User Experience

The platform is organized around dedicated workspaces per business entity, not a collection of forms: list pages track open requests, detail pages hold everything known about an entity, forms only create or modify it, and available actions depend on the entity's lifecycle state.

Detail Page. The detail page is the operational workspace for an entity, not a rendering of database fields. Depending on lifecycle state, a user can edit, delete or copy it, review its version history, download a PDF, and follow links to related entities it produced, for example a server request's DNS or firewall requests. These actions belong to the entity: what a user can do there reflects what it currently allows.

History. Every entity carries a complete version history as part of its detail page, not an administrative log tucked away separately: a user can always answer what changed, who changed it, when, and why, letting a user or auditor reconstruct a decision without asking someone to remember it.

OTOBO Timeline. The detail page also carries a second kind of history, the OTOBO timeline. Version history explains how the platform's own record changed; the timeline explains how the request progressed once it became a ticket in the external service-management system, one chronological narrative of submission, ticket status changes, and customer-visible communication cleaned of system boilerplate. Before this existed, understanding where a request stood meant reconstructing it from the form, emails, ticket comments and direct contact with support; the timeline collapses that onto one page. Showing it reliably is an integration problem, not a UI one: a stable request-ticket mapping, normalized status vocabulary across domains, data kept structurally separate from the external system, and graceful degradation when that system is unreachable.

OTOBO is named because it's an open-source product, not confidential information; no ticket queues, numbers, internal URLs, staff names, or ticket content are described here.

Delegated Approval. Not every decision belongs to someone who uses the platform day to day. A folder-permission request, for example, needs sign-off from whoever owns that resource, who may have no reason to log in otherwise; requiring an account for one yes/no decision is the wrong trade-off and leaves requests stalling in an inbox. Instead, the platform emails the stakeholder a secure, single-use, time-limited link: following it lets them approve or decline directly, no login required, triggering the same state transition, audit-trail entry and ticketing update as an in-platform action would, only who can trigger it, and how, differs. A reminder follows up if a decision stays outstanding. The pattern is general, not folder-permissions-specific, and could extend to any domain where sign-off belongs to a stakeholder rather than a platform user.

Copy. Users frequently need to submit a request that differs only slightly from one already submitted, the same firewall rule for a new environment, the same equipment set for a new hire. Rebuilding that from a blank form is repetitive and error-prone; starting from an existing, valid entity and adjusting only what's different reduces both.

PDF. Every domain can render its entity as a PDF, a portable document archivable, emailable, or reviewable outside the platform: one shared rendering service used by every domain, not a one-off feature.

Engineering Principles

This project reflects a small set of principles I apply broadly, not only here:

• Model business concepts, not forms. A form is an interface; the entity behind it is what's worth designing.
• Persistent entities over temporary requests. If something matters to the business, it should have an identity and a history, not just a submission timestamp.
• Workflows over page logic. Business rules belong in services that encode a lifecycle, not scattered across views and templates.
• Reusable services over duplicated code. The same validation, normalization or integration logic should exist exactly once, regardless of how many domains use it.
• Explicit relationships over hidden dependencies. If one business process depends on another, that dependency should be code, not institutional memory.
• Platform thinking over isolated features. The right question isn't "how do I build this form," it's "what does this form have in common with the last four, and how do I build that once."

Together, these principles are what let one architecture carry five business domains: a data-engineering perspective on application design, fragmented processes turned into one coherent model, and interaction design, the detail page, history, timeline, copy and PDF, following directly from that model rather than styled on top of it.

Selected Capabilities

• Unified entity workspace: each detail page combines current data, lifecycle status, related entities, actions, version history, OTOBO timeline and PDF export in one place.
• Structured lifecycle and audit-trail management across DNS, firewall, folder-permission, procurement and employee-lifecycle requests, with full change history, not just current state.
• Workflow-driven request processing spanning five business domains from a single architecture.
• Reusable domain components: shared validation, duplicate-detection, ticketing-integration and document-generation services used across all request types.
• Cross-domain entity relationships: server-provisioning requests generate DNS/firewall requests; onboarding records generate hardware/software procurement requests.
• Delegated, tokenized approval workflow: secure, time-limited email links let a stakeholder approve or decline a request without a platform account, with reminders and full lifecycle/audit/ticketing integration.
• Deployment-ready, containerized architecture, operated across development, test and production, with an automated test suite on the order of a thousand tests.

Lessons Learned

This project reinforced a few things I now treat as defaults rather than options:

• Domain modelling pays for itself. Time spent getting the lifecycle and entity relationships right up front was cheaper than retrofitting audit trails or cross-domain links onto a plain form.
• Lifecycle-aware design scales better than feature-aware design. Adding a sixth domain is a smaller task than adding a second feature would have been to a codebase built as isolated forms, since it reuses almost everything the first five already established.
• Good UX follows from the domain model; it isn't a separate design pass. Once entities, lifecycles and relationships were modelled correctly, the detail-page workspace, history view and timeline fell out of that model rather than needing a fresh design pass.
• A data background is an asset, not just an origin story. Thinking in structured data, traceability and consistency before writing application code has produced simpler systems than starting from the UI inward.
• Platform engineering is a mindset, not a job title. Whether the label on a given day is "Django developer" or "DevOps engineer," the question is the same: is this a one-off, or a pattern worth building once and reusing.

Start from the entity and its lifecycle, not the screen; build the shared layer before the fifth form needs it, not after.

Confidentiality

This platform was designed and built within a company environment, for internal operational use. This description covers the platform's actual business domains, workflows and architecture, since none of that reveals the company's identity, proprietary business rules or sensitive implementation detail. Deliberately left out: company name and internal URLs, real employee or teammate names, internal issue/ticket references, ticket queues, numbers or communication content, exact data-model or configuration specifics, and any detail specific to how the company runs its own infrastructure.