Enterprise architecture, AI and sovereignty: a conversation with Almudena Manjarin

Interview with Sylvain Melchior, Boldo

Almudena Manjarin is an independent consultant and enterprise architect. Today she supports SMEs and mid-market companies in their transformation: mapping their information system, deploying AI on concrete use cases, data sovereignty and governance. We talked with her about her background, her vision of the enterprise architect's role, and her convictions.

Almudena, can you introduce yourself and tell us how you came to enterprise architecture?

I started out in the field as a consultant at Octo Technology, where I stayed for six years. My entry point wasn't the technical side: I was a strategy consultant and agile-at-scale coach. It was through organization that I came to architecture, by way of Conway's law and Team Topologies diagrams, until I understood just how closely information systems are tied to the organizational system.

It began to interest me, and I joined a tribe of architects. There I learned the basics: the different levels with TOGAF, the functional, the technical, the infrastructure. I learned to map and to model, and it became a real passion. You learn an enormous amount about a company, you secure things, you understand the stakes on both the business side and the technology side.

What I love is that it's fieldwork, but it also gives tools to the people who have to make decisions, to judge the usefulness of an application or a tool. We really straddle technology and business.

Was enterprise architecture something you saw systematically deployed at your clients?

Honestly, not that much, and that's precisely what pushed me to take it on. I often paired up with technical experts on one side, and on the other with non-tech profiles working on company culture, change, product, UX. What interested me was the cross-cutting dimension and having a common language.

I could see that you could be disconnected from a certain reality when you didn't dive into understanding the architecture of the products and of the company. There's also an entry point through data: you see where the data flows, how it's structured, how it's exchanged. That's an aspect I tackled a bit later, notably with MDM.

The enterprise architect role hasn't always had a good reputation. What do you think?

It's true there was a lot of discussion around it: is an enterprise architect really an architect, compared to a technical architect?

It's a role that isn't always well understood. Is it really a profession, or more of a mindset? Should we talk about an urban planner, an enterprise architect, something else? Are the CIO or the head of transformation enterprise architects? In the community, these exchanges are frequent. Personally, I'm not dogmatic. When the Boldo team launched the product, they weren't enterprise architects themselves: the role is often taken on naturally. What matters is opening up the debate.

You mentioned MDM (Master Data Management). Can you tell us more about it?

I contributed to MDM engagements and I took a course at the end of my time at Octo that I really enjoyed. Concretely, it's about modeling the business process of a domain and creating a catalog of reference data, to establish a common foundation across several applications.

Take a commercial company: several different actors often use the same platform. For everything to make sense from one business function to another, you have to model the data well: what is a customer, a supplier, an invoice? It's a whole semantic layer. Today, MDM is a real need, and it's a genuine profession, different from that of the enterprise architect, even though the two converge. I actually have an ongoing engagement on the single source of truth: should you create a database within the CRM, or outside it to have a single source? These are typically architecture questions.

What are the major transformation topics today that make architecture indispensable?

Previously, as an employee of consulting firms, I tended to have large clients with challenges that were sometimes far removed from the field. Today I mainly support SMEs and mid-market companies, and I can perhaps see more easily the concrete impact and the stakes of investing in the right enterprise architecture tool. That's what I enjoy.

One transformation topic I observe, for example, is deploying AI, but on very specific use cases, starting small. I support the securing and management of data, and all the mindset to install around it: data mesh, responsibility for the data lifecycle. I also insist on transparency in the products adopted: sovereignty, hosting in Europe, real after-sales service, proximity, and a fair price.

I also co-authored a white paper on OKRs, and supported a team around an open source data services catalog. It's very varied, from the most strategic to the most operational.

Let's talk about OKRs. What do they bring, particularly on the CIO side?

First, OKRs make it possible to open a dialogue between leaders and teams. That's invaluable for listening to teams, who are often more up to date on new technologies, and for agreeing on six-month objectives with key results. Key results clarify what you want to track and achieve, with a precise schedule of checkpoints. It's a strategy that advances as it goes.

That often leads to system audits. Enterprise architecture makes it possible to map and then audit: once the audit is done, you see which project to support first, where the risk is greatest. OKRs and agile precisely recommend starting where there's the most risk, with quick added value, in order to de-risk.

There's also the question of integrating or abandoning solutions. You refer to the map and to the OKRs to decide: do we still need this tool? Do we stop, do we continue? Mapping, auditing and strategy in the form of OKRs: all of that keeps the system rational and optimal. In an ideal world, of course.

A key aspect of OKRs is the autonomy left to teams. Can you elaborate?

A key result isn't a deliverable, it's the outcome you want to achieve, for example better customer satisfaction. Reducing the number of incidents then becomes a means, not an end in itself.

What I find important, especially in large companies, is to leave autonomy and space to teams. If you impose "reduce bugs to X," you may get it. But if you say "here's the outcome we're aiming for, it's up to you to find the means," you generate far stronger motivation.

You mention sovereignty. Is it also a concern for small companies?

It's a concern, but it's not where they start. Moving away from major foreign solutions means enormous projects that require a lot of upstream structuring: MDM, mapping, list of applications. We're talking about colossal sources of information that structure the company. You can't break that without preparation.

These projects require substantial teams and budgets, with a phased roadmap. The idea is to start smaller, with POCs, around one business domain. Once the method has been proven on one domain with new tools, you can consider gradually phasing out products deemed non-compliant with a strategy.

Concretely, when you arrive at a new client, what does your roadmap for the first days look like?

First there are several meetings to grasp the context and understand things, and a lot of research on my part into the business. As an independent, you go from cosmetics to banking by way of industry: you have to start by understanding the client's language and business.

Then it often goes through workshops, for example to model and map business processes, real work in Boldo. From there, and depending on the demand, you can have a mapping phase, then consulting on integrating a solution with the whole process that entails, and training afterward, on the use of solutions or of AI.

For example, I have a client whose company has grown and who wants a map of her information system with a high-level view to rationalize it. In short: grasping the context, mapping, then auditing the situation, and then small projects to integrate solutions or support a team on the mindset (data as a product, for instance).

To finish, what convictions would you like to share?

We've talked about rationalization, cost, security. One strong conviction: as an enterprise architect, I love doing a great deal of watching and monitoring. This whole new generation of solutions, like Boldo or others in their fields, deserves close attention. It's a real plus for staying a step ahead in my consulting work.

I take a lot of time to meet the companies offering solutions, to request or accept demos, to understand who's behind them, how the solutions are structured, the pricing. It's essential given the current moment, when everything is moving so fast. Technology evolves quickly. This watching makes it possible to meet business needs, its processes.