From Paper VBScript to a Global .NET Journey: Lessons from Michael Hahn (Corporate Software Architect at Doka GmbH)

A DevJobs.at recap of “Michael Hahn, Corporate Software Architect bei Doka”

When we distill a devstory, we look for the moments where craft turns into career—and career into impact. In “Michael Hahn, Corporate Software Architect bei Doka,” Michael traces a line that is refreshingly practical: from early scripting in school and programming on paper to a sustained .NET focus, global rollouts, and architecture responsibility in an international setting. It’s not a story of buzzwords—it’s a field guide: pragmatic, learning-driven, and centered on people.

Our takeaway: Respect the craft, and you grow—from fundamentals without tools to software that’s rolled out globally. Treat architecture not as an ivory tower but as enablement: consulting, clear guidelines, a shared framework, and a focus that lets teams spend most of their energy on real requirements. And in a fast-moving industry, build routines: read, listen, compare, question.

First steps: scripting, Toolbook, and the joy of tinkering

Michael describes his entry modestly: around age 13 or 14, he starts “programming”—initially, scripting—during computer science classes. Toolbook, used at the time, becomes a playground; animating objects is enough to spark curiosity. What matters here is not the tool but the early experience: small experiments and the realization that software might be a good fit.

This realization shapes the next move: a technical secondary school (HTL) focused on IT (then called EDV-Unterorganisation). The goal is straightforward: build foundations.

Programming on paper: thinking clearly before you type

A formative detail from his HTL years: Visual Basic Script—on paper, with a pencil. It sounds unusual, but it captures the essence of learning to think like a programmer:

Success doesn’t come instantly: “I wasn’t very successful at the beginning.” But that changes over time. This phase highlights the value of mastering logic independent of tools. When you can structure an algorithm with nothing but a pencil, you’ve built a foundation that outlasts frameworks and IDEs.

A language journey: from Java to .NET and a steady Microsoft/Cloud focus

Over the years, Michael works his way “from Java to .NET,” across languages, then settles into a clear home: .NET. His core stack is the Microsoft ecosystem and cloud technologies—with .NET as his “hobbyhorse.” In a world of ever-expanding choices, his path shows the upside of specialization built on broad fundamentals.

Entering the profession and moving to Doka GmbH

After HTL, Michael joins the industry as a junior software developer. About “one and a half years” later—after stints in different companies—he moves to Doka GmbH. There he develops an internal calculation application and learns far more than code alone:

• He gains insight “into all the processes that lie behind sales and operations.”
• He accompanies worldwide rollouts—“from America to Singapore.”
• He visits every continent except Australia.
• He experiences how “every country is a little unique and different.”

This phase shapes both craft and mindset: deeper domain understanding (sales and operations) and hands-on experience in international collaboration. There’s also a personal match: “I like traveling”—so global rollouts meet personal motivation. When professional tasks align with personal interests, energy compounds.

Studying while working: Hagenberg, questioning, and looking beyond your lane

In 2015, Michael levels up with a part-time degree in Software Engineering in Hagenberg. His contrast between HTL and university is crisp:

This habit of questioning becomes a catalyst for the next step: thinking not only about how to build, but why, and which alternatives to prefer. From our editorial vantage point, this is a decisive lever in developer careers: theory gives you concepts and language; practice gives you friction and reality. The combination elevates your work. Michael puts it simply:

Growing into architecture: responsibility across systems and teams

With this foundation, Michael arrives at his current role: Corporate Software Architect. He’s been in the role for “around two and a half years,” and the emphasis is on maturation rather than title:

That’s a useful reminder: role maturity is a process. Titles are snapshots. Impact accumulates when every project, decision, and conversation sharpens your practice.

Four focus areas of a Corporate Software Architect

Michael distills his architecture work at Doka into four domains:

1) Technical consulting for software projects

Architecture starts with real projects. Business teams bring requirements and product ideas. Internal and external engineers collaborate. The architecture function’s contribution:

• align on implementation and architecture,
• select components and building blocks,
• “build it up” so the right parts fit together at the right time.

This frames architecture as a service to projects—not abstract diagrams but decisions that keep requirements feasible and maintainable.

2) Upskilling and enablement for project members

The second domain is capability-building. The core team setup: “two architects and two solution engineers,” a conceptual lane and an operational one. Especially for new technologies, they lead from the front:

• take the first steps,
• check “does this fit the project?”,
• “bring the team along on the journey.”

This is how you move fast without gambling: validate before broad adoption; then teach deliberately.

3) Guidelines and conceptual standards—with security guardrails

Third domain: company-wide standards. Questions like “How do we as a company use the cloud?” are decided with intent. This includes preferred components and rules—security included. Michael’s examples are straightforward:

• “Don’t store passwords somewhere.”
• Encrypt “at the database.”

He’s candid that missteps still happen:

That honesty is critical: security isn’t mainly about policies on paper; it’s about daily routines, reviews, and culture. Guidelines matter—and only work when they land in practice.

4) A shared framework—tools, packages, and component choices

The fourth domain is a force multiplier: a shared framework of tools and packages, plus decisions on components. The goal is to “simplify for all project members,” so they can focus “primarily on the content requirements.” From our vantage point, a shared framework reduces cognitive load:

• less time sunk into repeating the same technical choices,
• more consistency across projects,
• more energy for domain logic and user value.

This is not an ivory-tower artifact—it’s a productivity and quality lever.

Working between tech and people: what stood out to us

What stands out in this devstory is the balance between technology and enablement. There’s no name-dropping in Michael’s account, and that clarity makes the essentials visible:

• Craft first: think before you type. On paper if needed.
• Depth over constant switching: a home stack (for him .NET, Microsoft, cloud) without tunnel vision.
• Architecture as a service: advise, structure, decide—and strengthen teams.
• Rules without dogma: guidelines and security serve reality, not the other way around.
• Frameworks as multipliers: reuse, consistency, and focus on content.

Combined with international rollout experience, this paints the role of a Corporate Software Architect as less about grand slides and more about a steady accumulation of sound, shared practices.

Continuous learning: education, blogs, podcasts

Asked how to progress, Michael highlights two levers—education and ongoing learning around the day job:

1) Combine education smartly. His path—IT-focused technical school plus a subsequent degree, ideally part-time—pairs practice with theory. He summarizes it plainly:

2) The industry moves fast, so you need routines beyond the day job. Michael’s approach:

• Follow blogs “daily,” scanning for what’s interesting and applicable.
• Use podcasts because they work “everywhere”—“while running, biking, on the train, in the car.” The medium matters less than the habit. Consistent input makes patterns, technologies, and opportunities visible sooner.

He also stresses looking beyond your own industry: “What is the rest of the market doing, what are other industries doing?” That curiosity is the extension of formal education into everyday practice—question, adapt, improve.

Practical takeaways for developers

Michael’s path maps to concrete, repeatable steps for your own trajectory:

• Sharpen fundamentals deliberately: Practice reasoning without tooling crutches. Sketch algorithms, data flows, and constraints in plain language before you code. Clear logic translates into reliable software—in any language.
• Know one stack deeply: Choose a technical home (as Michael did with .NET and the Microsoft ecosystem) and invest in depth. This doesn’t exclude other tech; it prioritizes your learning time and makes your profile coherent.
• Learn the domain: Whether it’s an internal calculation system or a customer-facing product, business processes (sales, operations, etc.) are not side quests—they are the value. The better you know the domain, the better your architecture decisions.
• Treat architecture as enablement: If you hold responsibility for systems, create clarity before adding complexity. Architectures exist for teams—not the other way around.
• Make guidelines livable: Write rules that survive project pressure. Provide examples, checklists, and defaults that make mistakes less likely—especially in security.
• Maintain shared building blocks: A lightweight, shared set of tools and packages cuts waste, reduces variability, and lifts quality. Iterate and explain the “why.”
• Lock in learning routines: Set when and how you track blogs and listen to podcasts. Consistency beats intensity. Make a point of spotting ideas from other industries that you can transfer.

Global rollouts: learning at scale

Michael’s note on worldwide rollouts is more than travel. Large organizations with many sites surface software strengths and weaknesses under real-world conditions. Two points become tangible:

• Take differences seriously: “Every country is … a little unique and different.” What works in one market behaves differently in another. Architectural subtleties like configurability, localization, or integration paths gain their full weight in the field.
• Experience scales: Being on the ground across locations accelerates learning on where standards help—and where you need variations. That experience feeds back into guidelines, frameworks, and consulting.

The role matures with you: from developer to Corporate Software Architect

Michael’s move into architecture isn’t an overnight jump; it’s a continuum. The building blocks are clear:

• early programming exposure—even if it starts rough,
• breadth across languages before settling into a steady focus,
• hands-on exposure to business processes and global rollouts,
• a part-time degree to deepen thinking,
• gradually filling the architecture role “better and better.”

That composition—practice plus theory plus responsibility—is reproducible, not as a rigid blueprint, but as a resilient pattern.

Quotes that stick

These are pins on the map of a developer’s journey: fundamentals, focus, fieldwork, systems thinking—and a culture that keeps tech human.

Closing thought: tech as craft, architecture as responsibility

“Michael Hahn, Corporate Software Architect bei Doka” shows how consistent steps create a career: from early scripts and paper-based programming to specialization, global rollouts, and a role that shapes how teams build. The lesson is clear: keep learning, think cleanly, enable teams—and progress becomes more likely. To borrow Michael’s own words:

For anyone looking to grow into architecture, that’s a simple, durable compass.

• 

  

  Ronni Bjelosevic, DevOps Team Lead bei Doka

  DevOps Team Lead bei Doka Ronni Bjelosevic gibt im Interview einen Überblick über den Aufbau der Teams im Unternehmen, was dort neue Mitarbeiter erwartet und mit welchen Technologien gearbeitet wird.

  Watch now
• 

  

  Benjamin Schauer, Group Leader Digital Operation Tools bei Doka

  Group Leader bei Doka Benjamin Schauer umreißt im Interview die Organisation des Teams für Digital Operation Tools, was dort technologisch spannend ist und wie das Recruiting und Onboarding gestaltet ist.

  Watch now

• 

  

  Katja Hammer, Software Developer bei Doka

  Katja Hammer von Doka erzählt im Interview über ihren Werdegang als Software Developer bis hin zu ihrer aktuellen Arbeit und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  Matthias Schmutzer, Mobile Developer bei Doka

  Matthias Schmutzer von Doka spricht im Interview über seinen Einstieg ins Software Development, mit welchen Aufgabenbereichen er in seiner aktuellen Arbeit zu tun hat und gibt Ratschläge für Leute, die selbst gerne mit Development starten möchten.

  Watch now