What I believe | @rusakl

After years of architecting global systems and digital supply chains in the biopharmaceutical space, I have learned that the hardest problems in enterprise IT are rarely technological. They are almost always structural, alignment-based, and human.

These are the core convictions that guide how I build systems, lead teams, and make decisions.

1. Technology is a Promise, Not just an Asset

To me, a commitment is a matter of conscience. In the pharmaceutical sector, this takes on a deeper meaning: every latency spike, data silo, or system outage is not just an IT incident—it represents a delay for a patient waiting for life-critical medicine. I believe that enterprise architects must take psychological ownership of their systems. If a design doesn’t guarantee compliance, stability, and GxP rigor, it is a failed design, regardless of how modern the stack is.

2. Architecture Should Demolish Silos, Not Build Them

A system that works perfectly in isolation but fails to integrate with the broader value stream is a liability. I believe in designing “inclusive” architectures. Just as a strong team thrives on diverse perspectives and close relationships, a modern digital supply chain relies on modular, federated data meshes that allow separate systems (ERP, LIMS, WMS) to talk to one another seamlessly. Good architecture acts as a translator, not a barrier.

3. Seek Truth in the Data, Not the Hype

It is easy to get swept up in vendor hype or abstract theoretical models. I believe in a detective’s approach to systems: analyze the raw master data, uncover the hidden gaps, and focus on objective evidence. A beautiful dashboard built on top of fragmented, low-quality master data is simply an expensive illusion. Clean, decoupled, and highly structured master data will always outperform complex, monolithic software suites.

4. Continuous Learning Must Serve Practical Simplicity

My natural state is curiosity; I am driven to explore how things work and to continuously acquire new skills. However, in enterprise IT, the urge to over-engineer is the ultimate trap. True technical maturity is the ability to take a highly complex business problem and design the simplest, most elegant workflow to solve it. We should learn aggressively but build conservatively. If a solution cannot be explained simply, we do not understand the problem well enough yet.

5. Quiet Support Beats Loud Leadership

I believe the best leaders and architects are “coordinating supporters” rather than authoritarian directors. The role of an architect is to be a quiet, stable sounding board—helping teams think outside the box, easing tense integration conflicts, and celebrating the successes of others from behind the scenes. When we build the team’s capability and let others shine, the systems we deploy are inherently more resilient and widely adopted.