MACManager
MACManager is not another inventory tool. It is a coordination layer over existing enterprise network systems: identity, Cisco ISE and Meraki, unified into one operational workflow for onboarding and managing a site's device fleet.
Built by a four-person team in just over three months, on a fixed deadline, inside a closed enterprise network.
Problem
Network onboarding and MAC-address administration were fragmented across tools and operational teams. A site could contain a large fleet of devices that needed to be registered, classified and made visible quickly. Manual onboarding was slow and error-prone.
Operators needed a single workflow that connected:
- identity
- network access control
- device inventory
- telemetry
- audit history
Constraints
- A team of four.
- A fixed deadline of roughly three months.
- A closed enterprise network: no public SaaS dependencies, no casually added external APIs.
- Existing systems (ISE, Meraki, the identity platform) were the sources of truth and could not be replaced.
Architecture
A coordination layer over existing enterprise systems.
flowchart TD
user["Operator"]
frontend["React application<br/>device search · bulk onboarding · scoping · status tracking"]
backend["Python backend<br/>security boundary · orchestration · normalisation · audit point"]
identity["Identity and role resolution<br/>SSO, directory groups, country scoping"]
ise["Cisco ISE<br/>network identity, MAC operations"]
meraki["Meraki<br/>device enrichment, network context"]
logging["Process logging<br/>operational feedback + enterprise log platform"]
user --> frontend --> backend
backend --> identity
backend --> ise
backend --> meraki
backend --> logging
Frontend. A React application for device search, bulk onboarding, country and organisational scoping, status tracking and operational feedback. The frontend never talks directly to Cisco or Meraki.
Backend. A Python service that acts as security boundary, orchestration layer, normalisation layer and audit point. It hides vendor-specific differences from the frontend.
Identity. Enterprise SSO establishes the user. Directory groups map to application roles, and access is scoped by country or responsibility. Role and scope are applied server-side, never trusted from the client.
Cisco ISE. The primary source for network identity and MAC-related operations: retrieving devices, creating and modifying records, operational network-access workflows.
Meraki. Enriches device information with current network context and telemetry. The system combines ISE and Meraki data into a more useful operational view than either provides alone.
Logging. Every mutation is recorded. The operator gets immediate feedback; logs are also forwarded to the enterprise logging platform for longer-term audit and support.
Bulk onboarding. Accept a large set of devices, validate and normalise the input, apply authorisation and scope checks, process mutations in a controlled sequence, and report success or failure per device. One failed item must not force the operator to repeat the entire batch.
What the closed network forced
- Dependencies had to be approved, mirrored or already present internally.
- Authentication and certificates had to work with internal infrastructure.
- External observability platforms could not simply be added.
- Debugging was harder: production-like integrations existed only inside the network, so local development ran on mocks, fixtures, simulated vendor responses and careful contract testing.
- Deployment and CI/CD had to fit internal infrastructure rather than public cloud conventions.
- Documentation mattered more, because developers could not always reproduce every integration locally.
- Vendor integrations had to tolerate inconsistent responses, internal connectivity failures, certificate issues and permission differences across environments.
The broader lesson: in a closed enterprise network, architecture is shaped as much by organisational and operational constraints as by software design.
Trade-offs
What we prioritised: the core onboarding workflow, essential role and country scoping, direct integration with the existing systems, operational transparency and reliable mutation handling.
What we deliberately deferred: generic integration abstractions, sophisticated event-driven enrichment, elaborate approval workflows, deep historical analytics, perfect real-time consistency, and any platform generalisation the deadline did not require.
Concrete decisions from that pressure:
- Direct mutations, rather than introducing a reviewer or approval layer.
- Short-lived caching (Redis) for selected recent state and reference data.
- Graylog as a logging destination, without trying to become a Graylog query interface.
- Enrichment queues and richer asynchronous workflows deferred until the core operational path worked.
We optimised for a reliable end-to-end operational flow rather than for the most elegant theoretical architecture.
The ugliest compromise
The system presents a unified experience over integrations that do not share a unified data model.
Device identity can differ across systems. Some data is authoritative in ISE, some in Meraki. Freshness differs. The backend has to merge imperfect records and expose uncertainty without confusing the operator.
And under a fixed deadline, some vendor-specific logic inevitably leaked into the orchestration layer. A cleaner abstraction could be built later; over-generalising early would have endangered delivery.
What changed my mind
The main challenge was not writing code. It was maintaining a shared model of the system across developers, operations, identity teams, network specialists and stakeholders. With four people and three months, ambiguity was more dangerous than technical complexity.
I initially thought a small team required everyone to stay flexible across all responsibilities. In practice, flexibility without clear ownership created uncertainty. The team moved faster once responsibilities, interfaces and decisions were explicit. Leadership became less about controlling implementation and more about reducing ambiguity.
The takeaway: a small team does not need less architecture. It needs architecture that is easier to communicate and act on.
Future evolution
- More asynchronous bulk processing.
- Better reconciliation between ISE and Meraki, with explicit source-of-truth indicators.
- Richer operational audit views.
- Configurable workflows per country or business unit.
- Better resilience around partial vendor outages.
- More contract testing against integration boundaries.
- Event-driven updates instead of refresh-based enrichment.
- A domain model further separated from vendor models.
Engineering principles
- ✓ Coordinate existing systems, don't replace them
- ✓ Scope aggressively under a fixed deadline
- ✓ Explicit ownership over universal flexibility
- ✓ Reliable end-to-end flow over theoretical elegance
- ✓ Server-side authority, never trust the client
- ✓ Every mutation audited
Related
Status: Living document Last updated: 2026-07-28
This article reflects my current understanding. As I build more systems I expect parts of it to evolve.