What’s in a Name? Enterprise Architect, Solutions Architect, and the Blur of Corporate Titles

What’s in a Name? Enterprise Architect, Solutions Architect, and the Blur of Corporate Titles

When I originally penned this reflection five years ago, the technology landscape was wrestling with a quiet identity crisis. Today, as we navigate the dizzying velocity of the AI era, those waters have only grown muddier.

Let me take you back to a personal milestone. July 2020 marked my 41st work anniversary—a journey where business and technologies have been permanently intertwined. I feel profoundly fortunate to have witnessed a succession of remarkable revolutions: the electronic dawn of the 1970s, the birth of the worldwide web in the 1990s, and the explosion of digital ecosystems and the Internet of Things (IoT) in the 2000s.

I began my career in 1979. The very first computer I ever operated was an IBM 1401, utilizing a punched-card architecture.

Looking back, nearly five decades have passed in the blink of an eye. Today, the “IoT” devices that seemed like science fiction are daily, invisible necessities for both global enterprises and individual consumers.

The Compasses That Shaped My Mind

Throughout this journey, I have worn many titles. Yet, I have always anchored my focus on roles and responsibilities rather than positions or corporate hierarchy. In the 1980s, two monumental catalysts shaped my perspective: John Zachman’s The Zachman Framework for Information Systems Architecture and James Martin’s Information Engineering.

These frameworks became my operational compasses, providing the blueprint for what I like to call my “business journey” (because technology, at its core, is business). My internal challenge became an ongoing mission to learn, adapt, and contribute to every single cell of Zachman’s framework: the What, How, Where, Who, When, and Why.

Have I mastered every single one? Not completely. But I have spent decades practicing within the core verticals:

  • What (Data & Information)
  • How (Business Process)
  • Where (Technology)
  • Why (Business Value & Motivation)

Then came 1993—a true transformational milestone for me. I was fortunate enough to be coached directly by Dr. Stephen R. Covey, author of The 7 Habits of Highly Effective People.

“Architecture is about leadership competence. It is about challenging the status quo and designing business terms by doing the right things when no one is looking.” — Inspired by Dr. Stephen R. Covey

Dr. Covey made a profound impression on me with an elegantly simple truth: it takes 21 days to learn a new habit. The rest is simply practice, practice, and more practice.

The Title Paradox: Ten Answers from Five People

Over the years, the industry has birthed an overwhelming taxonomy of titles: Enterprise Architect, Solution Architect, Project Architect, System Architect, Cloud Architect, Cybersecurity Architect, Domain Architect, Application Architect, Data Architect, Business Architect, Infrastructure Architect… the list is seemingly endless.

Is there a standard, universally accepted definition for these roles? Not really. If you ask five different professionals across business and technology, you will easily get ten different answers. Even seasoned, professional architects hold competing definitions.

A few years ago, I received a phone call from a recruitment agency looking for an “Enterprise Architect.” I politely asked for clarity regarding the day-to-day roles and responsibilities. Based on the recruiter’s response, I summarized the job description back to them: project management, meeting coordination, basic business requirements analysis, and administrative support.

When I noted that the compensation structure was far too low for the strategic weight of an Enterprise Architect, the conversation took a bizarre, creative turn. Within the hour, the same recruiter called me back. They offered to bring me in under a different title—either a “Solution Architect” or a “Cybersecurity Architect”—simply because those specific titles commanded a much higher corporate pay bracket.

My mind immediately raced with questions: Has the strategic importance of the Enterprise Architect been fundamentally diminished? Is this a systemic global issue, or just a regional symptom?

In a fiercely competitive market, organizations try to be clever with talent acquisition at any cost. In the process, roles and responsibilities become blurry, diluted, and sometimes entirely meaningless. Consequently, the business wing of the enterprise is left deeply confused.

(Don’t misunderstand me—I have also collaborated with exceptional organizations that get this right. They cleanly formulate business visions, map out clear short-, mid-, and long-term architectural roadmaps alongside domain experts, and align their people, tools, and processes to drive real, measurable business results.)

The Architectural Path Forward

To bridge this divide and restore clarity to our organizations, we must return to first principles. Here are the core truths I believe we must champion:

For Enterprise Architecture & Technology Teams
  • Our Purpose: The business and the customer are the sole reasons we exist in technology.
  • Alignment: True architecture must be practiced in lockstep alignment with business leadership to guarantee its success.
  • Awareness: We must build mass architectural literacy across all operational layers of the organization.
  • Simplicity: We must educate and guide our business partners using clear, accessible “business terms”—leaving the dense jargon behind.
  • Trust: Trust is earned by demonstrating a seamless blend of technical competence and moral trustworthiness to improve key business metrics.
  • Shared Ownership: We must establish joint, unified goals where Enterprise Architecture and business leadership win together.
For Business Leadership
  • The Sovereign Customer: The customer remains king; they are the engine fueling your organization’s growth, transformation, and innovation.
  • Active Engagement: To navigate the relentless speed of modern digital transformation, business leaders must actively embed themselves with their EA and technology teams.
  • Role Clarity: Demand and establish distinct, uncompromised roles and responsibilities for your teams.
  • Measurable Value: Establish and demand clear, quantifiable, and verifiable business outcomes from your Enterprise Architecture investments.
References
  1. The Zachman Framework for Enterprise Architecture – John A. Zachman
  2. Information Engineering – James Martin
  3. The 7 Habits of Highly Effective People – Dr. Stephen R. Covey

What are your thoughts? Have you noticed the responsibilities of the Enterprise Architect shifting or blurring in your own organization? Let’s keep the dialogue going. Feel free to share your insights or reach out to me directly at tarun@meghastuti.com.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top