🔒 Disclaimer / Notice
This article is purely based on learning, exploration, and research into MDM, EMM, and API publishing technologies during my internship and personal projects.
No production-level deployments, enterprise bypassing, or unauthorized development for business gains were performed.
All experiments were done in local/demo environments and with educational intent.
The purpose of this write-up is to share knowledge and document my journey, not to promote or replicate enterprise deployments without proper authorization.
🏁 Starting Point: My Internship at Mercurial Minds
During my internship at Mercurial Minds (M.M), I was placed in the Enterprise Mobility Management (EMM) / Mobile Device Management (MDM) department.
At first, I wasn’t fully clear on what these systems were about — tools like Samsung Knox and other enterprise EMM platforms felt overwhelming.
But gradually, I discovered that EMM/MDM isn’t just about managing devices — it’s a core product area that many leading software companies invest in.
This was my first real exposure to enterprise-level technology, beyond the world of small-scale software projects.
🔍 Diving Deeper: From Confusion to Curiosity
As I got hands-on experience with an EMM/MDM portal on a demo server, my curiosity grew. With some research, I found that the portal was powered by the Entgra IoT Server.
Instead of stopping there, I pushed myself to self-learn:
- Studied how the portal behaves behind the UI.
- Explored the REST APIs that power MDM workflows.
- Looked into open-source repositories on GitHub.
- Broke down how Java, JDKs, and Maven tie together in Carbon Kernel–based projects.
At first, things like API gateways, publishing flows, and claim-based authentication seemed abstract. But slowly, the architecture started making sense — I realized these weren’t just “APIs,” they were enterprise connectors between identity, security, and data.
🧩 Connecting the Dots: From Internship to My Own Projects
While experimenting, I even evaluated Entgra UEM 6 (using my Alpha Tech business email). That opened doors to WSO2 API publishing features, which taught me that:
✅ APIs aren’t just direct DB calls — they’re published assets, controlled, secured, and monitored.
✅ A single published API serves all users/tenants, while tokens and claims decide whose data flows through.
✅ Enterprise systems solve the question:
“How do I ensure each user only sees their devices, even though everyone is calling the same endpoint?”
🧠 Applying It: Building My Own System
This was a big shift. I wasn’t just thinking like an intern anymore — I was thinking like:
- A developer building scalable solutions.
- A founder shaping my own product direction.
I applied these lessons in my own project — Alpha Connect Hub (under Alpha Tech):
- Built a Node.js backend for device management.
- Used WSO2 API publishing to expose those APIs securely.
- Integrated OAuth2 / JWT-based access tokens to ensure each request is linked to a unique user identity.
- Experimented with building a Java backend to simulate MDM/EMM workflows on a Carbon Kernel stack.
⚙️ Lessons From the Struggle
This journey wasn’t smooth:
- Running large Carbon Kernel projects on macOS was painful.
- Debugging JDK versions, Maven builds, and UEM server issues tested my patience.
- Figuring out why
GET /devicesworked only via the API Gateway (and not as a direct DB call) forced me to learn about invoker endpoints, token claims, and mediation policies.
I learned that one API is published for everyone, but the token’s claims (like user_id) make it unique per user.
Every error — from a 401 auth failure to a class-not-found exception — taught me something new.
Through this struggle, I learned the real difference between project-level coding vs. enterprise-level development:
Projects require coding skill.
Enterprise systems require architecture, patience, and persistence.
🌐 What’s Next
I’m now preparing to set up a Linux server environment, since Carbon Kernel–based systems run more stably there compared to macOS.
My roadmap is clear:
- Build enterprise-ready backend systems.
- Combine MDM, EMM, and API publishing into scalable, secure products.
- Use this foundation to grow Alpha Tech into a company that builds solutions, not just apps.
💡 Final Reflection
Looking back, this wasn’t just an internship. It was the spark that helped me:
- Transition from learning projects → building products.
- Move from coding → thinking enterprise.
- See technology not just as tools, but as part of a bigger ecosystem of identity, security, and scale.
My journey into enterprise development has only just begun. 🚀
Top comments (0)