Enterprise Architect, Don’t Be a Prisoner of Your Department

Why your position in the organization matters, and how to build influence beyond IT

Oct 22, 2026

An enterprise architect I spoke with recently told me something interesting. They had come to realize that they were probably working in the wrong part of the organization. At the same time, they had managed to build good relationships with people in other departments, giving them opportunities to get involved in matters well beyond their own organizational unit.

This conversation prompted me to write about an issue I have encountered quite often in my work.

Over the years, I have worked with enterprise architects in dozens of client organizations. I have also spent longer periods working as an architect myself in a few organizations, and discussed the topic with both new and long-time colleagues. One thing seems to be fairly consistent, at least in Finland: enterprise architecture (EA) usually sits somewhere within IT. Occasionally, it belongs to a broader business or organizational development function, but that seems to be the exception.

I have seen this arrangement cause problems more than once. Being part of IT can affect what an enterprise architect gets to work on, who they collaborate with, and how much influence they have outside their own department. As a consultant, the problem can be even more pronounced. You are already an outsider, and reaching people beyond the department that brought you in may take considerable effort.

Of course, the organization chart does not tell the whole story. As the architect I mentioned had discovered, it is quite possible to build connections and influence across organizational boundaries, even when your formal position is less than ideal.

So, does it really matter where EA sits in the organization? And what can you do if you suspect you are in the wrong place?

IT Is a Good Place to Be, but There Is More to the Organization

Placing EA within the IT department makes perfect sense in many ways. EA has strong roots in IT, and many enterprise architects have moved into their roles from more technical architecture positions. Besides, much of the planning and decision-making within IT can benefit from EA.

Managing the IT environment, developing the application portfolio, selecting technologies, and planning development initiatives are all natural use cases for EA. There is nothing wrong with that.

The problem arises when EA activities become limited to these areas. After all, EA is an approach to planning and developing the organization as a whole. It considers the structures and dependencies between business operations, information, applications, and technology. And many of the organization’s most important development needs originate somewhere other than IT.

Consider an organization planning to improve its customer service. Such an initiative may require changes to business processes, responsibilities, employee competencies, information management, and IT systems. EA could help considerably in planning this kind of transformation. However, if the enterprise architect only gets involved when the necessary IT solutions are being designed or acquired, many important decisions have already been made.

At that point, the architect’s role may be reduced to checking whether the proposed IT solution fits into the existing application landscape. That is useful work, of course, but it leaves much of EA’s potential untapped.

Ideally, enterprise architects should also participate in strategic planning, as well as in planning and developing the organization’s core operations, preferably from the early stages when needs and alternatives are still being discussed. This requires collaboration with senior management, business units, development functions, and other supporting functions. And this is where the organizational position starts to matter.

The Organization Chart Matters More Than You Might Think

An organizational structure defines responsibilities, reporting lines, and management relationships. At the same time, it influences how people collaborate and whose business they are expected to get involved in.

In some organizations, collaboration across departmental boundaries is completely natural. Specialists contact each other directly, participate in joint planning, and solve problems without much bureaucracy. In others, people are very particular about who can contact whom, who gets invited to which meetings, and whose responsibility a particular issue is. Sometimes departmental boundaries seem almost like national borders.

The latter situation is particularly challenging for EA. The whole point of EA is to develop an overall view of the organization and identify dependencies that extend beyond individual functions and departments. If the architect only has access to discussions within IT, the resulting architecture work will likely be rather IT-centric.

The manager’s position also makes a difference. A CIO may have close connections to senior management and an important role in strategic planning and organizational development. In that case, an enterprise architect reporting to the CIO may have excellent opportunities to influence matters beyond IT.

The situation can be quite different when the architect reports to, say, an IT service manager whose responsibilities and influence are limited to one department. The manager may be very supportive of EA but lack the authority or connections to help the architect participate in activities elsewhere in the organization.

The organizational position can also shape expectations about the architect’s work. If an enterprise architect belongs to IT, others may expect them to focus primarily on IT matters. Getting involved in business process development, for example, may be seen as stepping into someone else’s territory.

In the worst case, the enterprise architect is expected to look after the interests of the entire organization, while their objectives, resources, and management come from just one small part of it. That is not exactly an ideal starting point for an enterprise-wide function.

Your Manager Is Not Necessarily Your Enterprise Architecture Sponsor

An enterprise architect’s manager naturally has an important role in defining their responsibilities, allocating resources, and managing their work. However, managing the architect and steering EA activities are two different things.

If EA is expected to support strategy execution and organization-wide development, its steering should also come from a sufficiently senior level. Otherwise, there may be a mismatch between the objectives assigned to EA and the opportunities available to achieve them.

This is where EA sponsorship comes in. Ideally, EA should have a sponsor in management who considers the function important, helps define its objectives, and enables collaboration across organizational boundaries. This could be the CIO, a development director, or another member of the management team.

The sponsor and the architect’s line manager can be the same person, but they do not have to be. A CIO who participates actively in strategic planning and business development may be an excellent sponsor. On the other hand, an IT manager whose responsibilities are limited to one department may have fewer opportunities to support organization-wide EA activities, however positive their attitude toward EA might be.

Of course, simply naming someone as the EA sponsor achieves very little. Sponsorship should be visible in practice, for example, in the assignments given to architects, their participation in development planning, and the use of architecture in decision-making.

The enterprise architect needs access to the people and discussions where architectural input could make a difference. That matters more than the reporting line itself.

So, Are You in the Wrong Place?

Would it then be better to place EA directly under the CEO or somewhere else near the top of the organization?

Perhaps, but there is no single correct answer. Organizations differ in their structures, management cultures, and ways of working. In a small organization, EA may work perfectly well as part of IT. In a large corporation, it may make sense to have a central EA function working together with architects in different business units or subsidiaries.

A position high in the organization also comes with higher expectations. If EA reports directly to senior management, it should be able to actually contribute something to strategic planning and organization-wide development. Maintaining a collection of current state architecture diagrams will hardly be enough.

Before proposing an organizational restructuring, I would therefore look at how EA could work better within the existing arrangements. Could the architect participate in business development planning? Could the EA function establish closer relationships with process owners and information management specialists? Would a shared architecture forum help bring together people from different departments?

Sometimes relatively small changes in collaboration and governance can make a considerable difference. The architect’s formal position remains the same, but their actual opportunities for influence improve.

However, organizational structures can also become genuine obstacles. If the architect is effectively prevented from participating in activities outside IT, and management is unwilling to support broader collaboration, there may be little room for improvement.

In that case, it may be necessary to reconsider where the EA function belongs. Alternatively, its objectives should be adjusted to match its actual mandate and opportunities for influence. There is little point in promising organization-wide strategic benefits if the architect is only allowed to participate in internal IT meetings.

How to Work Beyond Your Department

Most enterprise architects have little say in where they sit in the organization. However, their actual opportunities for influence can be considerably broader than the organization chart suggests. Much depends on how they approach their work and build relationships with others.

Here are a few things worth trying:

Clarify Your Mandate and Find a Sponsor. Discuss with your manager what EA is expected to achieve. If the objectives extend beyond IT, try to get support from someone in senior management who can help you get involved in organization-wide planning and development. Your line manager and EA sponsor can be different persons.
Get to Know the Business. Find out what people outside IT are working on and where EA could help. Start with concrete development needs rather than architecture methods and frameworks. A useful contribution to one business initiative may open doors to several others.
Build Relationships and Join Existing Activities. Get involved in development planning, portfolio management, and other activities where architectural input could be useful. Build connections with business developers, process owners, information management specialists, and project managers. Try to make EA part of existing ways of working rather than introducing yet another layer of meetings and governance.
Make Organizational Obstacles Visible. If your position prevents you from contributing to important development activities, discuss this with your manager and sponsor. Use concrete examples of missed opportunities and explain how broader EA involvement could help. You have a better chance of changing things by demonstrating value than by arguing about your position in the organization chart.

Look Beyond Your Department

Ultimately, the value of EA depends on how well it is used in organizational planning and decision-making. The organizational position matters, sometimes quite a lot, but it does not determine everything. The architect’s own initiative, credibility, and ability to build relationships also make a difference.

The architect I mentioned at the beginning had recognized that their position in the organization was probably less than ideal. Yet, they had managed to build connections across departmental boundaries and expand their opportunities to contribute.

I think that is a good example to follow. You may have limited influence over where your position sits in the organization chart, but you can often do quite a lot to extend your reach beyond it.

You can certainly belong to the IT department. Just remember that your job concerns the entire organization.

🎓 Yes, Enterprise Architects Can Go Back to School

Enterprise architecture is a field where much of the learning happens through projects, clients, and experience. But there are other options too.

I spent ten years completing a PhD on enterprise architecture benefit realization alongside a consulting career. It taught me a lot about research, the field itself, and the practical limits of doing serious study on evenings and weekends.

In my Expert Work by Design Substack, I wrote about the full journey, what I got out of it, and whether I would recommend doing a PhD alongside an expert career.