Software Architect, Engineer & Leader
A unified provisioning, onboarding, and asset management platform built for a semiconductor company mid-acquisition-spree — integrating dozens of companies across Ireland, Europe, and the United States onto a single automated IT backbone.
Jenoptik was moving fast. The semiconductor manufacturer was in the middle of an aggressive global expansion — acquiring companies across Ireland, Europe, and the United States in rapid succession. Each acquisition brought a new IT estate: different operating systems, different user directories, different hardware inventories, different phone systems, different email infrastructure. No two were alike.
The result was a sprawling, fragmented environment where nobody had a complete picture of what existed, where it was, or who owned it. New employees arrived to find their machines unready, their accounts not provisioned, their access incomplete. Departing employees left behind hardware that sat idle for months. Procurement was reactive and redundant. Compliance across international jurisdictions was managed, if at all, by hand.
Fred Lackey was brought in to answer that question. The mandate: unify the IT and HR operational fabric across every acquired entity, at global scale, using whatever the underlying platforms happened to be — because standardizing the platforms themselves was not an option.
Before a single machine could be provisioned automatically, a fundamental problem had to be solved: no one had defined what roles meant across the organization. A “Systems Administrator” at a newly acquired company in Germany was not necessarily the same role as one at a legacy site in Ireland — different responsibilities, different access requirements, different hardware needs.
The first system Fred built gave Jenoptik’s central HR team the ability to define and map equivalent roles across all acquired organizations. Each role was described in terms of its responsibilities and then linked to a canonical set of IT requirements: what hardware was needed, what software licenses were required, what system access was appropriate, what phone configuration should be applied.
This role-mapping layer became the master dictionary that everything else ran against. When HR onboarded a new employee, the system knew exactly what that person needed based solely on their role — regardless of which acquired company they were joining or which country they were in.
With role definitions in place, the provisioning system could execute end-to-end without manual intervention. What had previously required days of coordination between HR, IT, and procurement teams was compressed into an automated workflow triggered by a single event: a new hire being entered into the system.
Role lookup. The system matched the new employee’s role against the canonical role map to determine the full set of hardware, software, and access requirements applicable to their position and location.
Inventory check. Available hardware at the relevant site was queried. If suitable equipment existed, it was reserved. If inventory was insufficient, a procurement workflow was automatically initiated — generating purchase order requests and routing approval emails to the appropriate managers.
Machine imaging. The assigned machine was imaged using Norton Ghost, applying the standardized operating environment for that role. Bootable images on CD/DVD eliminated dependency on local IT expertise — a field technician with no specialized knowledge could deploy a machine correctly.
Distributed command execution. Provisioning instructions were dispatched to remote nodes across the global network via the asynchronous messaging system. Each node executed its assigned tasks — creating domain accounts, configuring SSH credentials, setting phone extensions and voicemail, granting email access — and returned status reports to the central orchestrator.
Travel-aware access. The system accounted for employees who worked across multiple sites. Access was provisioned for every location the employee needed, not just their home office — ensuring continuity for the globally mobile workforce that Jenoptik’s acquisition strategy required.
The same workflow ran in reverse for departures and role changes: hardware was recovered or re-provisioned, access was revoked, and assets were returned to inventory rather than left to accumulate in desk drawers.
Coordinating automated tasks across a heterogeneous global network in the late 1990s meant building the coordination infrastructure from scratch. No suitable middleware existed. Cloud orchestration did not exist. What Fred built instead was a modular, asynchronous file-based messaging system — a command bus implemented over FTP.
The architectural insight was treating the FTP file system as a message queue. Nodes polled their designated directories, consumed instruction files, executed locally, and deposited result files for collection. The central orchestrator never needed a direct connection to a remote machine — it only needed FTP access, which was available everywhere. New platform types were supported by writing a new processor module and deploying it; the orchestration layer required no modification.
This pattern — now described in terms of event-driven architecture and decoupled processing — was built from first principles to solve a practical problem in an era when those concepts had not yet been formalized.
The acquisitions had made no attempt at platform consistency — because acquisitions rarely do. Each company came with the infrastructure it had built independently over years. The provisioning system had to work against all of it, simultaneously, without requiring any of the acquired companies to change their underlying infrastructure first.
Windows NT, Novell NetWare, Sun Unix, SGI Indigo, BSD, Slackware Linux
Unix mail, MSMail (predecessor to Microsoft Exchange) — each requiring distinct provisioning paths
Nortel, Tadiran, Meridian — extension and voicemail configuration handled per-system
C, C++, Visual Basic — selected per-processor based on what each platform required
The cross-platform breadth was not incidental. Each processor module was written in whatever language best suited the target environment. The orchestration layer was platform-agnostic by design — it dispatched instruction files and consumed result files; what happened in between was entirely the processor’s concern. This separation meant the system could grow to cover any new platform acquired in future without architectural changes.
The measurable outcomes were significant. But the less quantifiable change — giving the central IT and HR teams visibility and control over an infrastructure they had never been able to see in full — was arguably more consequential for a company still in the middle of acquiring more entities.
Jenoptik Highest Internal Recognition
In recognition of the platform’s impact on Jenoptik’s global operations, Fred was presented with a gold statue — the company’s highest internal honor. The name reflected the scope of what had been asked, and what had been delivered. It is a fair description of the brief.
The system was built without the benefit of modern orchestration frameworks, message queue services, or cloud infrastructure. Everything that needed to exist was built. The FTP-based messaging pattern, the role-mapping schema, the processor module architecture, the inventory tracking layer — none of these had off-the-shelf equivalents suited to the problem at the time.
Core Languages
Messaging & Orchestration
Platforms Integrated