How to Become a Cloud Architect: Turning Help Desk Experience Into Cloud Architecture Skills
How to Become a Cloud Architect: Turning Help Desk Experience Into Cloud Architecture Skills
In Part 1, I explained why my Help Desk position became one of the most important foundations of my career. But fundamentals alone aren't enough. You can spend years learning valuable skills and still remain in the same place if you never decide where you're trying to go. At some point, I realized something that changed my career:
I couldn't wait for someone else to develop me.
I needed to take ownership. That meant looking beyond my current responsibilities, identifying the skills I was missing and deliberately building the experience required for my next opportunity. That mindset eventually helped take me from Help Desk to Oracle DBA, consulting, Enterprise Architecture and Cloud Architecture. The transition wasn't a leap. It was a climb.
Stop Waiting for Someone to Design Your Career
A company hires you because it has work that needs to be done. That's reasonable. But the skills your employer needs from you today and the skills you'll need for your future career aren't necessarily the same. That's why you have to participate actively in your own development. During my Help Desk years, I noticed that my work kept exposing me to networking and operating systems. I could have simply continued completing those tasks. Instead, I asked for training. That decision mattered because it represented a change in mindset. I was no longer simply asking: "How do I perform my current job?" I was beginning to ask: "What capabilities am I building?" Part 2 of my Help Desk Foundation transcript captures this shift: I stopped waiting for someone else to shape my future, asked for training and started taking ownership of my growth. That's one of the most important pieces of career advice I can give anyone trying to become a Cloud Architect. Don't wait for permission to become curious.
Learn Why, Not Just How
Early in an IT career, you're often given procedures. Click here. Restart this. Install that. Run this command. Follow this document. Procedures are useful, but if your goal is architecture, eventually you have to move beyond memorizing how and start understanding why. Why did restarting the service solve the problem? Why couldn't these systems communicate? Why does this application depend on that server? Why does authentication fail for one user but not another? Why does changing one component affect something seemingly unrelated? That curiosity is where architectural thinking begins. My Help Desk Foundation material makes this connection directly: documenting processes, understanding dependencies and examining network flows were early forms of architecture and design thinking—even before I would have described them that way. Architecture isn't simply drawing boxes and arrows. It's understanding relationships.
Dependencies Are Everywhere
When I first started dealing with application dependencies, I wasn't thinking about cloud migration. But years later, dependency analysis would become critical to the work. Imagine an enterprise preparing to migrate hundreds of applications. You can't responsibly look at each application as an isolated object. What databases does it use? What systems communicate with it? Where is authentication handled? What are its network requirements? What happens upstream? What happens downstream? What business process depends on it? What happens if you move one component and leave a tightly coupled dependency behind? These are architecture questions. My later cloud work involved assessing enterprise environments containing hundreds of applications, developing cloud strategies, designing landing zones and determining migration approaches. That sounds far removed from Help Desk. But the mental habit is related. Understand the environment before you change the environment.
Documentation Is Architecture Training
Documentation is another skill people underestimate. When you're early in your career, documentation can feel like administrative work. It isn't. Good documentation forces you to understand what you're documenting. You need to identify:
What exists? How is it configured? What depends on it? Who owns it? What is the normal process? What happens when it fails? What should happen next? As responsibilities grow, that thinking evolves into architecture diagrams, migration plans, operating models, standards, runbooks and technical designs. My later roles required architectural diagrams, AS-IS and TO-BE designs, application and data-center assessments, cost analysis and migration planning. The sophistication increased dramatically.
But documentation remained part of the work. So if you're on the Help Desk today and someone asks you to document a process, don't automatically think: "This isn't architecture." Think:
"I'm learning to explain how a system works." That's valuable.
Use Your Current Job to Build Your Next Skill Set
One of the strategies that worked throughout my career was looking for overlap between what my employer needed and what I wanted to learn. At the Help Desk, networking and operating-system responsibilities created an opportunity to request formal training.
Later, while working in a computer lab installing and packaging applications, I noticed I was installing ODBC drivers associated with Oracle databases. I had already looked at the technology market and decided I wanted to pursue Oracle DBA work.
So I connected those two facts. I approached management and explained that Oracle training could help me better troubleshoot the Oracle-related work I was already performing. They agreed. That training gave me my first formal exposure to Oracle. At the same time, I built relationships with the Oracle DBAs inside the company, so they knew I was interested in their work. When an opportunity eventually opened, I was positioned to pursue it. That's career strategy. I didn't fabricate a connection between my job and the skill I wanted. I found a real business reason for learning something that would also advance my career. From Troubleshooting Systems to Protecting Production Becoming an Oracle DBA increased the stakes. Now I wasn't simply dealing with an individual workstation. I was dealing with databases and production systems. Unix became deeper. Scripting became more important. Data protection mattered. Backup and recovery mattered. Availability mattered. Performance mattered. And production failures mattered. My Career Journey includes a defining moment when a production database failed while I was still relatively new. Through research and troubleshooting, I found the problem and restored the database. Think about what was underneath that moment.
Troubleshooting. Curiosity. Research. Remaining focused under pressure. Understanding systems. Those habits didn't suddenly appear when I became a DBA. They had been developing for years.
From DBA to Enterprise Thinking
Oracle DBA work eventually expanded into Oracle Apps DBA work, ERP environments and large consulting projects. I gained exposure to SQL Server and DB2 as well as enterprise applications such as Oracle E-Business Suite, SAP, PeopleSoft and JD Edwards.
The technical landscape became larger. So did the business landscape. Instead of thinking only about a database, I had to understand the enterprise processes depending on the technology. Later, I began leading teams, working with clients and presenting to executives. That progression eventually moved me into Enterprise Architecture, where I was working with private data centers, large migrations, architectural blueprints and proofs of concept. Again, notice the progression. Support a component.
Understand the system. Understand the dependencies. Understand the application. Understand the business process. Understand the enterprise. Then design for the enterprise. That's why I describe the journey to Cloud Architect as a climb rather than a leap.
What a Cloud Architect Actually Needs to Understand
Cloud Architecture is bigger than memorizing AWS, Azure, GCP or OCI services. Those platforms matter. But knowing service names isn't the same thing as knowing architecture. Cloud Architects need to think about systems holistically. Applications, Compute,
Networking, Identity, Security, Data, Availability, Disaster recovery, Cost, Governance, Migration, Modernization, and Business requirements. My later resume reflects that breadth: Cloud Architecture work across AWS, Azure and OCI, along with databases, operating systems, backup and recovery, virtualization, networking, architecture and enterprise applications. My cloud work eventually included assessing enterprise environments, determining migration candidates, developing cloud strategies and working across AWS, Azure, GCP and OCI. That's why the fundamentals matter. Cloud didn't erase infrastructure. It abstracted and transformed parts of it. You still need to understand what the technology is doing.
The Mindset Shift: From Fixing to Designing
Here's the transition I want aspiring Cloud Architects to understand: At the Help Desk, you're often reacting to problems. As your career develops, you begin asking how to prevent them. Then you begin asking how the system should have been designed in the first place. That's the shift. Support asks: What broke? Engineering asks: How can we make this reliable? Architecture asks: What should we design to meet the technical and business requirements? The curiosity developed during support can become the foundation for all three. Part 2 of the Help Desk Foundation series describes the goal as moving from supporting systems toward designing them—and connecting technical decisions to reliability, scalability and trust.
That is the bridge.
Build Your Cloud Architect Career One Layer at a Time
If you're currently at the Help Desk and want to become a Cloud Architect, don't try to learn everything simultaneously. Build layers. Master troubleshooting. Learn networking. Learn operating systems. Understand identity and security. Learn scripting and automation. Understand applications and databases. Learn how systems depend on one another. Document what you learn. Look for opportunities to work on larger environments. Learn how technology supports business outcomes. Then start applying those foundations to AWS, Azure, GCP or OCI. And above all, take ownership of the process. My career didn't move forward because someone handed me a 25-year roadmap on my first day at the Help Desk. I made decisions. Some worked. Some didn't. I changed direction. I watched the market. I asked for training. I built relationships. I pursued opportunities. And I kept learning. My Career Journey ultimately describes that progression as a series of strategic moves rather than luck. That's the lesson I want you to carry forward. Your current job does not have to define your future. But what you choose to learn from your current job can help build it. The fundamentals give you a foundation. Ownership gives you momentum. Strategy gives you direction. And continuous learning allows you to keep evolving.
Modernize Without Compromise.
SHARE
