Internal vs consulting Enterprise Architecture

Internal vs consulting Enterprise Architecture

Today, I want to discuss the two big experiences you can have as an Enterprise Architect: working internally at a company and being a consultant. I’ve done both in the past, so I hope to bring some insights into this topic.

I have the feeling that depending on what you have more experience with (internal or consulting), you will have a very different perspective on Enterprise architecture as a whole.

Time Horizon

It’s crucial to understand that a consultant’s role is time-bound, typically spanning from six months to two years. Within this limited timeframe, they must swiftly acclimate to the company, comprehend the project’s scope, devise a roadmap, and often prepare a handover program for the company to continue the momentum.

The company often picks a scope here. There might be a specific need: a cost rationalization, a merger, building an application portfolio map… It’s often very technology-driven. The first task will be to do a very brief dive into all the information available and create a roadmap for the work that is coming. As you can imagine, you can’t move the world in this short term. The focus here is mostly on mapping out the AS-IS and (not always) giving options for a TO-BE.

Internal architecture, in contrast, is a role that focuses more on a long-term perspective, as the architect is expected to stay for an extended period. While roadmaps are still essential, they take the form of phases in a larger plan. The initial phases often revolve around technology, laying the groundwork for the business layer structures.

Internal architecture might sound way more relaxed, which might definitely be the case, but it’s often overlooked that these architects don’t get to spend 100% of their time on the big architectural work. They will almost always be part of other projects that are going on at the organization, be it as solution architects, functional analysts, application/process owners, or just generally as people who know a lot about a specific part of the organization.

Being part of the in-crowd

Internal architects have the advantage of understanding the company’s culture. This cultural understanding is not to be underestimated.

One of the most critical jobs in Enterprise Architecture is ingraining your practice in the organization. This is done by marketing your schemas and information internally to people who might have a use for them. If you are internal, this comes very natural. You are invited to other projects where you can showcase your schema’s and ideas. If you are an external however, this is something you actively have to go out and seek.

I know this sounds weird to outsiders, but you often have to convince people that the information you give them is valuable.

The important thing to know here is that if you provide value in the form of information to people, they are way easier to convince to take 5-10 minutes out of their day and also to give back data. It is an investment you make that pays back in dividends.

You don’t get all of the above as an external architect. In the past, I’ve always felt that being a consultant often puts you on a bit of a backfoot with people in the organization. I wonder if this is because people don’t want to invest time in getting to know you (as you’re going to be gone in a year anyway) or if it’s just that people don’t like consultants. Whatever the reason, it is more challenging to get people to spontaneously invite you to meetings or share information with you.

What you do get, is a top-down priority. The powers that be have invested a lot in the consulting contract, so they will use their weight to tell others to give you all you need. You will, however, not get it spontaneously or with a smile.

A lot of companies are also very resistant to change. You can’t expect an organization with a few thousand people to turn on a dime. However, change will always be more accepted from within than from outside parties. It’s the “we are going to change x” versus “they tell us to change x”.

What about the work itself

As previously discussed, the role of internal architects is deeply rooted in a long-term vision. This focus allows them to witness the evolution of an organization over time, whether it’s a positive or negative change. A successful internal architect is not just a witness to this change, but an active participant, contributing to the positive transformation of the organization.

Both internally and externally, architects will probably start with a focus on the application landscape. The difference is, however, that for external architects, this is perhaps the sole focus. That’s not a bad thing. I’ve been blown away by what some consultants can do regarding an application landscape in six months.

However, the differences are more pronounced when you move to things like Capabilities (You can read more about how I like to use Capabilities here ). You need to be very experienced (and have the full support of the company) to create a fully bespoke capability map for an organization in six months. It’s definitely not impossible, but it will be far from easy.

If you are an internal architect, you will have a better chance of really deeply understanding a company to create a capability map from scratch, as you have worked in that same organization for the last couple of years.

External consultants, on the other hand, bring a different kind of value. Their ability to swiftly address pressing matters and deliver immediate results is a testament to their effectiveness. It’s incredibly satisfying to see a year’s worth of planning for an application rationalization exercise being enthusiastically embraced by management. This quick and tangible impact is a unique aspect of the role of external consultants. This is often a result of the timepressure and project priority.

You learn more as an external consultant right?

You hear this all the time. It’s not wrong. As a consultant, you get thrown into different situations every six months. Every company has their unique challenges and setups. You can learn a ton from this. So it’s a great place to be if you’re new to architecture and you are paired with a more senior consultant to show you the ropes.

However, you almost never see things through. That presentation that you’ve worked a year on, you have no idea if it ever actually gets implemented. This is a shame, as it will teach you a lot.

There is sometimes a bit of cargo culting (https://en.wikipedia.org/wiki/Cargo_cult) going on in our field. We do things cause we read them in a book or saw a conference talk about it. But it’s not always clear if it’s the right fit for the company for which you are implementing these ideas. If you stick around in a company, you will find out. If that’s a positive thing, I’ll leave it up to you.

Related Posts

Architecture in an agile world

Architecture in an agile world

Agile in the real world Before we start talking about architecture, it’s a good idea to lay out the foundation of this discussion first.

Read More
The Goldilocks strategy: Finding 'Just Right' in Good, Fast, and Cheap

The Goldilocks strategy: Finding 'Just Right' in Good, Fast, and Cheap

Picture this: it’s a Tuesday afternoon. You are called into a meeting room by your teamlead. He’s conversing with a client about a big new project they want to develop.

Read More
Connect microservices with the help of GRPC

Connect microservices with the help of GRPC

Microservices are all the rage these days. Luckily underneath the hype there are some great use cases for them. If you’re splitting up a monolith codebase into smaller specialised chunks, extracting a long running queue to its own system, or even using particular pieces of code in a different programming language.

Read More