We've Been Building Technology Infrastructure Since Before the Internet Changed Everything.
GDP Support traces its roots to 1988, when the business began as Computer Time during the early PC clone revolution.
Our early work included point-of-sale systems and individual PCs. But the technology didn't stand still—and neither did we.
From individual systems
to enterprise infrastructure.
-
Computer Time
PC Systems · Point of Sale · Early Clone Era
-
1990s
Networking
ARCNET → Novell → TCP/IP
As computing moved from standalone PCs to connected workgroups, we moved with it. ARCNET gave way to Novell networks. Proprietary networking gave way to TCP/IP. Workgroups became enterprise networks. Servers, communications and infrastructure became increasingly interconnected.
-
Microsoft Enterprise
MCSE · Microsoft Certified Trainer
By 2000, that evolution had moved us deeply into Microsoft enterprise technologies. Our principal engineer earned the Microsoft Certified Systems Engineer (MCSE) credential and became a Microsoft Certified Trainer (MCT) in 2000, followed by Cisco CCNA certification in 2001.
-
Cisco Networking
CCNA
That led to teaching and technical engagements across the United States—and eventually to increasingly complex enterprise infrastructure projects.
-
2004+
Telecommunications
Telecom Infrastructure · Project Management
By 2004, our work had expanded into telecommunications infrastructure and project management.
-
Enterprise
ScaleIntegration
Large Infrastructure Projects · Multi-Site Environments · M&A Integration
The scale changed dramatically.
Experience grew from individual systems and networks into major infrastructure initiatives, including telecommunications projects with values exceeding $100 million.
At the same time, merger-and-acquisition work introduced another class of engineering challenge: integrating networks, telecommunications, systems and locations while the underlying businesses continued operating.
GDP Support's experience includes technology integration associated with major mergers and acquisitions and environments involving hundreds of locations across the United States, including work associated with the ProBuild environment.
Projects at that scale teach lessons that don't come from certification courses.
Technology is only one part of infrastructure.
Successful integration requires understanding operations, logistics, communications, risk, people, schedules, vendors, budgets—and what happens when the plan encounters the real world.
-
Today
Convergence
Data Centers · Networking · Satellite · Virtualization · Resilience · AI
There is a difference between knowing how a system is supposed to work and having been responsible for getting it working when it doesn't.
GDP Support brings that operational perspective to engineering.
Systems fail. Networks go down. Hardware breaks. Software vendors change direction. Backups eventually have to become restores. Remote locations lose connectivity. Infrastructure that looked perfectly adequate on a diagram can behave very differently in production.
That experience influences how we design.
- Reliability.
- Recoverability.
- Maintainability.
- Security.
- Simplicity.
These aren't features added at the end of a project. They are engineering requirements from the beginning.
The Technology Keeps Changing. The Engineering Principles Don't.
- PCs became networks.
- Networks became enterprise infrastructure.
- Physical servers became virtual infrastructure.
- Data centers became hybrid environments.
- Communications expanded from terrestrial networks to increasingly capable satellite systems.
- Computing is now entering another transformation through artificial intelligence.
GDP Support continues to evolve with it.
Today our work encompasses:
Data Centers · Enterprise Networking · Telecommunications · Satellite Communications · Virtualization · Cybersecurity & Resilience · Artificial Intelligence
The technologies are dramatically different from what we installed in 1988.
The fundamental questions aren't:
- What does the organization need to accomplish?
- How should we engineer it?
- What happens when something fails?
- How do we keep it operating?
- What comes next?
We Don't Begin With a Product Catalog.
We begin with the requirement.
What does the system need to accomplish? What happens when something fails? How will it be operated? How will it be recovered? What does it need to become five years from now?
Only then do we determine which technologies belong in the architecture.
That vendor-independent approach allows GDP Support to evaluate established platforms alongside emerging alternatives and engineer infrastructure around the organization's requirements—not a manufacturer's sales strategy.
Experience Matters.
Nearly four decades in technology provides perspective.
We've seen technologies arrive with enormous promises and disappear a few years later. We've watched dominant vendors become obsolete, new architectures replace established ones, and business decisions completely change the economics of technologies organizations had depended upon for years.
That history is one reason GDP Support remains vendor independent.
We don't engineer around the product.
We engineer around the requirement.