Enterprise architecture: from cathedrals to pragmatism

Interview with Louis Collinet (Onepoint), conducted by Sylvain Melchior (Boldo).

From IT audit at PwC to Enterprise Technology Management at Onepoint, Louis Collinet has seen information systems from every angle. A consultant specialising in luxury and higher education, he argues for a pragmatic form of enterprise architecture: a discipline that starts with knowing your IT landscape, proves itself through value, and now takes concrete shape thanks to a new generation of tools.

From the machine to the strategy

Hi Louis, thank you very much for your time. To start with, tell us a bit about yourself, your background and what you do today.

I am an engineer by training, a graduate of Télécom SudParis, and I moved into consulting and audit very early on: first at EY, then four years auditing information systems at PwC. I then joined Onepoint on IT strategy and enterprise architecture topics, before moving into what we call Enterprise Technology Management: orchestrating the whole set of technologies, and the skills around them, in service of the information system, which itself serves the business.

What kinds of organisations do you work with? Mostly large groups, or mid-caps?

When I was an auditor, I covered the insurance sector, for groups such as AXA and Swiss Life. These were recurring regulatory audits on the security of the information system: access management, change management, segregation of duties and environments. At Onepoint, my path has been multi-sector: higher education, banking, insurance, energy, construction, and more recently luxury, which I have been working on actively for more than two and a half years.

Today I cultivate three things. First, sector knowledge: before talking about technology, an enterprise architect has to understand the market and the business of the company they are supporting. Second, my core expertise, IT estate management: knowing your information system well enough, its strengths and its weaknesses, to make the right modernisation decisions and steer it towards a target that is fit for purpose, resilient and performant. And third, business development and commercial oversight in higher education, a sector I care about a great deal.

Working alongside organisations of very different sizes and maturities has taught me one thing: what worked in a large group does not apply everywhere. Problems play out differently depending on maturity, history, and market segment. Orchestrating all those parameters is what makes you genuinely impactful in this job.

Knowledge, costs, risks: every CIO's triptych

Are there shared concerns between a large luxury group and a higher education institution?

Some problems concern any CIO, in any company in the world.

The first is knowing what you own. What are my applications, my flows? Which teams use what? Which projects will have what impact on the IT landscape, on the business, on the value chain? And the most critical question of all: what are the dependencies between all of that? It is this knowledge that lets you measure the impact of a decision, a transformation or an external event. When we talk about AI transformation or sovereignty, when a company wants to move away from certain vendors or certain regions, you first have to understand the consequences of being, say, fully Microsoft, and what worst-case scenarios could unfold tomorrow. To build those scenarios and a sound impact matrix, you have to know all these interdependent elements.

The second is IT cost management, what we call TCO (Total Cost of Ownership) management: all the costs an application portfolio generates, whether people, licences or contracts.

The third is risk, in the broad sense. Regulatory risk first: am I exposed on GDPR? Sovereignty, which everyone is talking about, belongs to that dimension too. Then IT risk: am I vulnerable to attacks? And even before being attacked, there is technical obsolescence and end of support. If a vendor stops maintaining an operating system or an application, the company finds itself exposed to a risk that is not directly within its control.

And what about sector differences?

Traditionally, in higher education as in some other sectors, what is expected of CIOs first and foremost is day-to-day operational excellence, which sometimes obscures their strategic potential. They run the run: the daily grind, incidents, small changes, data centres, servers. They are rarely in a position of proposing value to academic leadership. Why? Because historically, the CIO was a very technical profile, in the garage or in the basement, making sure the machinery kept working.

Today the challenge converges with the architect's: yes, that complexity exists and it has to be dealt with. But you also have to step back and look at the value delivered to the business, at what is shifting on the vendor side, at the technologies that are emerging, AI first among them. In short, become a business partner. That blend of market pressures and inherited IT culture is something I find everywhere, whatever the size of the organisation.

The CIO in the boardroom: two worlds finally meeting

Are you seeing the CIO's position evolve, particularly in large groups?

Executive committees are changing the way they call on technology leaders, for a simple reason. In the past, a company's business model often depended on a flash of genius: what it was going to sell and how. And that “how” owed very little to IT, which was just an accelerator. Companies relied above all on brilliant profiles: in luxury, the artistic directors, the marketing directors, the guardians of the brand image. That is still true. But today, to win market share, the information system has taken on its role.

A very simple example. Before Covid, luxury sold very little online. eCommerce sites were not the main purchase channel, because a luxury experience was lived in store, carefully choreographed for clients ready to spend eye-watering sums. The effort went into hospitality, not technology. Covid accelerated a realisation: you have to be able to sell elsewhere, and technology makes a virtualised luxury experience possible. That triggered a huge amount of thinking about how technology helps you sell better, carry the brand image better, listen to the end client better. Innovation departments in luxury groups are seeing their technology budgets grow. With AI, you can now use the camera to project how a collection piece would look on you. That was unthinkable: you had to go to the store.

Executive committees are realising this. And because technology is a nebulous subject (it is not just AI or cloud, it is an orchestrated whole), they give these profiles far more weight. Except that a clash remains, one that is gradually resolving itself: long-standing technical directors do not always speak the boardroom's language. Those gaps are being filled little by little, so that the person who knows the IT landscape intimately can also articulate its value for the business model and the brand. These two worlds are starting to meet. And sovereignty, like AI, are not purely technological subjects, yet they remain eminently technological: you cannot talk about AI without talking about data centres, energy, capacity, performance. It is wonderful to imagine AI everywhere in the company, but you still have to be able to host it, on every floor, including the technical ones.

Enterprise architecture: a discipline, not a person

Is that where the architecture approach can reconcile the two worlds?

Exactly. The architect is not the only person with one foot in the business, even in strategy, and one foot in technology, but the role remains a pivot. That said, I prefer to talk about the discipline, or the culture of enterprise architecture, rather than the architect. Making everything rest on one person (knowledge of the business, of every technology, the capacity to keep watch) creates enormous pressure and is not realistic. Nobody builds an iPhone from A to Z: experts and intermediate orchestrators are what bring the product to completion with quality. The same goes for enterprise architecture. But the discipline itself needs to be orchestrated.

It also requires not putting all the weight on the technical side. Architects, whether solution, enterprise, technical or integration architects, have often been accused of being zealots of their subject, locked in their ivory tower: experts unable to step outside their own frame, unable to show how their cherished concepts and capital-T truths are ultimately meant to deliver value to the business. They then lose interest in the reality on the ground and get bogged down in endless debates. That mentality has to change.

For me, enterprise architecture is the ability to identify the right people, the ones who hold the key knowledge at each level of the IT landscape, in order to guarantee a chain: knowledge of my information system, assessment of it, then definition of a target and a trajectory. Where I want to go depends on the market's ability to supply certain technologies, on vendor maturity, on our internal maturity and our skills, but also on the value we can bring to the business. In the end, the architect says: here is where my IT landscape is today, here is where I would like it to be tomorrow, here is how I steer it, and here is how I make sure I am managing all of it properly.

That as-is / to-be mechanism, we have always had. The real turning point is making pragmatic decisions. I have to tell a story that starts from the company's strategy and goes all the way down to the most operational piece of data I manage, then distribute coherent responsibilities across key people. That story has to hold together end to end: I cannot settle for an integration strategy, an infrastructure strategy, a collaboration tools strategy and a core business strategy, each in its own corner. I have to understand how everything instantiates at the most operational level, while still enabling decision-making in the boardroom. As long as that thread is not written, we do things locally that may never deliver value, or deliver questionable value. That is especially true in large companies, where teams sometimes struggle to talk to one another.

On assignment: the duty to advise and the art of sequencing

From IT audit, very close to the machine, to the wider view at Onepoint: what convictions have those experiences shaped?

That thread I was describing, I try to apply it to myself. When you arrive at a client, through a tender or because they hand you their day-to-day problems, you have what we call a duty to advise, which applies internally too: making sure the problem as stated is the right one. We do not ask enough questions, and sometimes not the right ones. The ones that let you check whether the problem being posed is really the one the company needs to face, or whether there are underlying issues, prerequisites, that would be wiser to tackle first. My first principle: take nothing at face value, and be curious enough to uncover the invisible pain points.

I should say I am not a zealot of any method. I am not the type to declare: “what you need is exactly an IT master plan, let's roll it out.” I like to get into genuine empathy with the problems of the person in front of me, and cross them with a company context, a history. A few principles guide my questioning, whatever the methodology: start from the strategy, look at how it cascades operationally, check that responsibilities exist at every level to keep the whole thing alive, make sure the conceptual gets operationalised and that we know how to step back when we sink into the operational. If the story ends up being called an IT master plan, fine; if it is an audit, that is fine too. That obviously does not stop me from drawing on market frameworks when they are useful: a TIME analysis, a 6R, a TOGAF methodology, or tools that carry their own method.

Do you have a concrete example of that duty to advise in action?

Recently, a client came to me because he was drowning in contradictory urgencies. He had to model his processes, plan his move to cloud, comply with the AI Act, reduce technical debt and put out the shadow IT fire, all at once. His leadership expected results on every front, immediately. Faced with that analysis paralysis, his first real problem was not technical, it was methodological: it was sequencing.

So I asked him a very simple question: “Do you know exactly which IT tools are running in your organisation today? Before describing your processes, before thinking about compliance or data, do you have a starting point? It is like asking you: do you know how many rooms are in your house?”

Before you hang a picture on the wall…

Exactly. Before you hang your picture, it would be good to know whether you have water and electricity: the foundations of your house, the ones that make it liveable. For me, the basics are these questions: do you know your company's IT tools? Do you know what they do? Which business capability do they serve? Can you say whether a given tool serves sales or after-sales, whether it serves designers, accounting, or HR?

Simply by asking these elementary questions, you sometimes discover that you cannot answer them. “That tool is used a bit by the accountants and a bit by HR.” That is when the real questions surface: is it normal to have catch-all tools? Has this one's purpose been diverted? These simple questions reveal whether the company's history has produced genuine confusion in how tools were rolled out, especially at the scale of a large group. And they spark the first useful conversations.

And once that foundation is in place, how do you prioritise?

Then, given the company's maturity and its ambitions, what is it urgent that I, as an enterprise architect, know how to answer to an executive committee? If I am told “Louis, compliance is non-negotiable, we are in insurance, tomorrow we have to be able to answer on DORA”, my questions will be: concretely, what do I need to be able to manage? What is the specification? What information does it require? Do I have it in my IT landscape? Who would hold it? Which tool could carry which knowledge? At what data quality? Who is accountable?

Then you have to know how to document over time. Right now I am reacting; tomorrow I no longer want to be. If I am asked the DORA question again, I need a base of centralised information, sourced from across my IT landscape, and I need to answer very quickly: we are at risk or we are not, here is the effort required, we have three months, and here is exactly what we are going to do to be beyond reproach. Ask any company today where it stands on DORA: the answer is very hard to give. And that is before even approaching an AI transformation without knowing your baseline applications.

There are starting points, then stable plateaus of maturity. Once you are solid on the number of applications and what they do, you can start asking about their dependencies: what information do they exchange? That is no small matter, but the day that information exists, you move to the next step, application security health for instance. Security teams hold that knowledge, but they often rely on outdated repositories: they gather information locally when an audit comes round, and six months later their knowledge is already obsolete.

The goal is knowledge that does not expire: an orchestrated method that gives the right people accountability, puts governance and the right rituals in place, and creates a collective dynamic for capturing the right information. And in the agentic era, the effort we used to make by word of mouth or group emails is something AI will be able to multiply: probing the SharePoints we have structured properly, querying the tools that centralise key information, and quickly checking whether the knowledge is sound, whether we assess correctly, whether we can answer sovereignty, regulatory and technical debt questions.

With every new priority, we apply the same in-house framework: accountability, information to manage, ability to assess, decision-making. And from there: how do I do better, how do I do differently. Less technical debt, more compliance, anticipating a carve-out in case of an acquisition, knowing your data and your application interdependencies, being ESG compliant. It is the most basic of basics. It is a hard thing to instil in a company, because you have to change mindsets and cultures. But the day you prove the value, by delivering a very fast answer across a very broad scope, the person opposite you thinks: “Wow, I never imagined you could answer me that easily.” And that makes the whole company want to adopt the method, so everyone finds something in it to ease their daily work, speed up their decisions, anticipate external events. In the end, you move from reaction to proaction: when I am no longer afraid of my past, of what might break, of where I am not compliant, I can finally ask the right questions, the ones about better and different. You move from risk control to innovation.

And yet today, companies often try to innovate before controlling their risks, particularly on large-scale AI transformations. The timing is wrong. Yes, you have to go for it, but by asking the right questions about how. It is being done in a somewhat anarchic way, and the enterprise architecture discipline is precisely what brings rationality to these large transformations we sometimes launch blind.

There is definitely a FOMO effect around innovation: you see a neighbouring company publicising its AI (which it may well be running just as haphazardly) and you rush into the use case before you have, let's say, tidied your room.

“Tidied your room”, I love the metaphor. That is exactly it.

Equipping the discipline: the end of cathedrals, the era of pragmatism

Do you think this conviction can be equipped with tools, to simplify collecting and governing that knowledge?

Yes, and it is one of my strong convictions. Today's architect must have their own tools, the way a blacksmith has theirs to forge with. Architecture must not be purely methodological or cultural “bullshit”; I say bullshit because some people could perceive it that way. All of it has to be made concrete.

For more than twenty years, the enterprise architecture tools market threw itself into solutions that aimed to represent everything in the IT landscape. It was an era where the thinking was: the day the IT landscape is perfectly modelled, with organisations, processes, the value chain, technical costs, we will understand the dependency chains and we will make excellent decisions. The idea was already there. The problem was the method. When you try to collect everything, by the time you have counted all your sheep, one has been born at the far end of the field and others have escaped. Your conclusion is already wrong the moment you reach it.

Two things have shifted in this market, and any architect should be questioning their tooling. First, the main tool today is APM, Application Portfolio Management. The application is the nerve centre of the IT landscape: applications are everyone's tools, the whole company's. Behind them there are of course people, processes, projects, organisations, technologies. But it is the applications that are vital to how the company runs. APM means “I count my applications”, but not in just any way. I could collect every piece of information in the world around each application: the contract, the underlying code, the technical ecosystem, the network, security. Except that by the time you have counted it all, the information is out of date, especially if it is a one-shot exercise rather than something sustained over time.

And that is where the new tools come in?

Tools like Boldo arrive packaged with a method, a philosophy. I can hear it in the way you talk about it: you do not recommend modelling down to the company's power sockets, but on the contrary a highly pragmatic approach, to demonstrate the value of the architecture discipline.

The biggest challenge for an enterprise architect today is making visible the culture they are trying to instil, that knowledge of the IT landscape. And to make it visible, there is nothing better than a tool, paired with the right method: I go and find a vital piece of information and I put it in that tool. These tools are also very modern, enriched with AI; they have inherited the baggage of the past and focus on the essentials. The enterprise architect has to stop trying to be an expert in everything from the ivory tower: they have to focus on what matters. A tool like Boldo is the perfect embodiment of that pragmatism.

The advantage of this new approach is how quickly it makes things concrete and visual for executive leadership: “Look at what we collected in three months. Here are maps, dependencies that speak for themselves, aimed at a boardroom and not only at technical profiles.” And the executive committee can conclude: “The three-month budget we granted you has genuinely paid off, because today, in this forum, we are able to make an excellent decision: we know the risks, the business criticality across the group, the costs.” Once you have shown that the tools and methods of the past were not the right ones, you can invest more in the discipline, because its value is now understood.

Boldo arrives with terrific momentum: it is a great tool, modern, built for today's world. And above all, it has understood the key issue, the one that will allow enterprise architecture to become a recognised discipline in the boardroom tomorrow, but also at project level, among operational teams, security teams and legal teams. It will become that pivot point that establishes a shared language across the IT landscape and the company, where people finally talk about the same thing in service of the same goal, and which reconciles a sometimes painful history, born of the wrong method or of insufficient technological or cultural maturity. Boldo will bring, in my view, a great deal of value to every architect who gives it a chance, and who gives themselves a chance to change posture: to prove that behind the method and the concept there is a reality on the ground, and a visual reality, that can be offered to everyone.

Thank you so much, Louis, this was a fascinating conversation.

My pleasure!

Louis Collinet is a consultant at Onepoint, specialising in Enterprise Technology Management and IT estate management. Sylvain Melchior is the founder of Boldo, a modern Application Portfolio Management and enterprise architecture platform.