Enterprise architecture that serves the business

Stéphane, thanks for taking the time. To kick things off, could you tell us about your background and what you are doing now?

Hello, I am Stéphane Vanrechem. I have been in IT for 36 years, and I have had the word 'architect' in my job title, officially, for 13 of them. I was an IS architect, then an enterprise architect, then a senior enterprise architect at Société Générale. And from what several consultants in IT services firms have told me, Société Générale is probably the most advanced architecture practice in the bank industry. That is what got me poached by Forrester Research, an analyst and advisory firm, in September 2022.

Being an analyst gives you a view across the whole market. What are the big issues organisations are wrestling with right now?

The big issues I see around the world today are, unsurprisingly, the ones around rolling out AI. Our dear AI, which, let me remind you, has nothing to do with intelligence, but which can answer any question you throw at it, and that does feel like magic. A word of caution, though: a generic LLM, whichever one you pick, OpenAI, Anthropic, Mistral, you name it, hallucinates one time in five, and this is not about to improve. On top of that, these models have verbal tics that people spot, which rather makes you wonder how sincere the writing really is.

Companies today will tell you that AI is a must and that not using it is the road to ruin. I agree, nobody can afford to do without AI now. But first, the human has to stay the decision maker, even an augmented one; second, the AI must to be contextualised using semantic (Vector RAG) and ontology (Graph RAG) with the company's knowledge assets as far as it can be, on good-quality data; third, the company's know-how has to be protected and secured; and fourth, the AI has to be used with the proper level of power and influence. Get those four precautions right and the company can push on towards using AI with excellence.

And beyond AI, what about sovereignty? It is a subject that is very much exercising the organisations we meet.

Absolutely, and it is not only a European concern. The Americans have worked it out: if they want to carry on flooding the market, they have to offer 'sovereign' options. Take S3ns for example, which offers a trusted cloud with SecNumCloud 3.2 qualification. S3ns is a company incorporated under French law, set up by Thales and Google Cloud.

And one thing needs to be clear: even though S3ns runs on capabilities that sit in Google Cloud, that gives Google no way of seeing what goes on inside. S3ns sovereignty is watertight: no data can be used, diverted or pre-empted by Google, the company is under French law. Sign a contract with S3ns and you can be confident nothing will cross over to the United States: it stays and remains encrypted in France, or in Germany where that applies. Sovereignty is a huge undertaking, but it cannot be done overnight: there is a lot to get through, and it will have to be done step by step.

With all that complexity, what part does the enterprise architect play in answering these challenges?

To me, the purpose of Enterprise Architecture is singular and uncompromising: to serve the business. It's a position I've defended for more than a decade. Yet it's far from obvious in practice. Most architects come from IT, and engaging directly with business teams isn't instinctive. Historically, that role belonged to business analysts, and more recently, in agile environments, to product owners.

But the enterprise architect should be and increasingly must become the business's primary point of contact. It's the only way to stay aligned with strategy, understand real needs, and get close to the pain points, irritants, and operational processes that shape value creation.

Yes, architects manage portfolios, data flows, technical debt, governance, standards, and emerging technologies. But the real impact comes when they bring a fresh, cross-domain perspective to business processes. That's where they can propose the strongest solutions, sometimes genuinely innovative ones, because they see both the strategic intent and the operational reality. When architects take ownership of business processes, the value potential is at its highest.

I came up through product management, and I have always shared that view. For you, is architecture a role rather than a job title?

Exactly that. What I have tried to push throughout my career is that beyond the hard skills there are the soft skills, and for me that is where an architect's real value lies. I will come back to that.

Let us pick up on that, then. It is a fast-moving field and you have been very close to practitioners. How is AI changing the job?

Given where we are, the architect has to make sure AI comes into the company with the four precautions in mind as stated above. Bringing AI into architecture practice is essential, because getting that right is what scales up architects' capabilities, both in the artefacts they turn out and in making the practice itself easier to run. So EA has to adopt AI while putting guardrails around it. I am thinking in particular of AI agents, those tireless, semi-autonomous creatures that can genuinely help create value. But be careful not to hand them too much power, or at least keep that power in check or you might end up with serious problems. You have to stay in control, because these little creatures are there round the clock, and once you have set out the rules of the game they do not wait to be told what to do.

You know, there is still a long way to go, and the ivory tower syndrome is still alive. My take is that architects are clever people who can occasionally lack common sense or do not communicate as often as they should. So the best way of keeping an architect anchored in reality is to connect EA tools, yours for instance, Boldo, to the various systems. This will show the architects whether what they proposed actually work. With the enterprise architecture tool at the centre, I count eleven such connections:

The operating model which describes the organisational structure, the reporting lines, the people, the skills and so on.
Business processes which are what generate the company's value.
Data governance covering definition, cataloguing, quality, type, governance, access, and use.
Knowledge management meaning all the contracts, policies, applications and customer feedback, but server logs too: the company's real body of knowledge.
Portfolio management whether on the IT strategy side (SPM) or the IT project side (PPM).
The physical IS inventory via the CMDB or ITAM (IT Asset Management), which helps you take stock of technical debt and manage it.
Delivery via DevSecOps platforms, where the EA tool can track initiatives and automatically pick up new modules, new flows, dependencies or changes of scope.
Application estate costs (ITFM) so you can easily see what any given application component costs, whatever it is, alongside FinOps (AI tokens included).
User tickets (ITSM) so you can quickly spot where to act to lift satisfaction.
Production tickets (AIOPS), because there will always be some, which expose the weak points in the IS and help you work out which architectures hold up best.
Security incidents and breaches (SECOPS) which show where data is not protected well enough, or accessible enough, in the face of cyber attacks.

Those eleven points are, to my mind, the direction EA tools need to take if architecture is to earn its stripes. A word of warning: do not go after all eleven at once. Prioritise them and move forward step by step, and you end up with digital twins. First the twin of the organisation, covering points 1 to 4; second the delivery twin, points 5 to 8; third the production twin, points 9 to 11; and fourth one spanning the lot, which lets you put a number on what the information system costs: people, value chains, IT components (infrastructure, applications), support, production and security.

Thanks for all that. You are a natural teacher, and I gather you have been lecturing on enterprise architecture. How do you get the principles across to students, and the appetite for architecture with it?

It is a question that had been nagging away at me for years, particularly where students are concerned. The discipline is twenty, maybe thirty years old, and things take quite a while to filter through to academia; no engineering schools (Grandes écoles) today offer a proper course in it. Even so, eighteen months ago Benjamin Gay at CGI, the well-known French IT services firm, got in touch. He asked whether I fancied teaching enterprise architecture to Master 2 students. I did not need asking twice and of course I said yes, since Forrester let me do it pro bono. So I taught three semesters back to back. It was a wonderful experience. Getting the enterprise architecture discipline across to Master 2 students was a real challenge, because I had to teach them without them having any real IT or business experience behind them. Teaching the course, I found students genuinely taken with the approach, which also earned me very good marks.

Did you have a trick for holding their attention?

Funny you ask this question in the age of mobile ;-) yes, I taught the whole thing in English. First, it gets them used to what working life is like in big companies where, even if people speak French, everything is written in English; unless you are an entrepreneur, of course. At Société Générale, for instance, it is English and nothing else. Second, it forces them to use English in class, which keeps them on their toes. It was quite fun: I would open by welcoming them in French, then we would switch to English, and after that not a word of French. Best of all, the questions then started coming in English too. So I had won on both counts: I had their attention, and they were asking me questions. A really interesting experience.

Enterprise Architecture Master’s Course Syllabus.

And with people already in the job, is it a different exercise?

With employees it is easier: you are preaching to the converted. They can see what architecture is, and once you are inside a company you can draw on professional courses that build architects' skills. I actually wrote a Forrester report on this, built around three pillars.

The first is technical training (hard skills): TOGAF, IT4IT, BPMN, API, agile, cloud, Lean Six Sigma and so on. The second is interpersonal training (soft skills): running a meeting, winning people over, storytelling, handling conflict, mentoring and so on. This second pillar, to my mind, was neglected for years, with architects pushed to be masters of the latest technology. Yet that interpersonal training is, for me, crucial: it is what lets you sell architecture and show that it ought to be a major asset for a company.

The third pillar, finally, is career development, giving people the room to develop under their own steam, because they know what is good for them. Verizon is a good example: someone can train themselves, and if they get certified, Verizon pays the bill. This is a great model. Or showing your expertise internally, in meetings, or externally at trade shows, as an individual: that is very rewarding.

Find out more

Stéphane Vanrechem is happy to go deeper on any of these topics at svanrechem@eabiz.fr.