Enterprise architecture in the service

Enterprise architecture in the service of sovereignty and continuous transformation

Sylvain Melchior: Hello Yann-Éric, thank you very much for your time. To start, could you introduce yourself and tell us about what you do?

Yann-Éric Devars: I run Solve DSI, a consulting firm. I have two complementary activities: interim CIO on a part-time, shared basis, mostly for large SMEs and mid-market companies, and enterprise architect, most often supporting CIOs in large companies, public services or government bodies.

Sylvain Melchior: Do you have preferred sectors, or is it fairly generalist?

Yann-Éric Devars: Fairly generalist. I understand businesses and their common patterns quite quickly. I've been working in this field for many years, so I have experience in just about every sector.

Sylvain Melchior: Why do companies call on you? Are there fires to put out?

Yann-Éric Devars: What they see is often the fires, yes. But in reality, they've usually launched their transformation badly, not launched it at all, or not funded its launch. So the transformation doesn't happen, or only in small, immature pieces, and that starts fires all over the place. My role is to treat the causes, drawing on the local functional and technical teams who know the ground well. I come in with an outside eye, I fix the root of the problems and I put out the fires: that's the most common operational work.

Sylvain Melchior: What are the hot topics right now? We hear a lot about sovereignty, about AI…

Yann-Éric Devars: Sovereignty is usually defined at the level of nations. At the company level, it's the ability to make decisions in one's own interest. The SaaS era did a lot of damage in that respect. Companies bought solutions all over the place and now find themselves dependent on suppliers who are sometimes abusive, with contracts signed in good faith but poorly framed. There's often a dependency to unwind. SaaS remains useful, of course: you can't do everything yourself, it's a model that works, provided it's properly framed.

There's also the older "move to cloud," where everything was put in the cloud thinking the IT department could be entirely outsourced: that didn't work. And then there's AI, with enormous expectations. There, what matters is the structuring of data and the ability to build your own AI. With SaaS, you depend on the supplier's AI, and if you don't want your data exploited, you have to build your own. All of this has to be defined, accepted, framed and implemented. I'm not here to slow down progress, quite the opposite: the goal is to have solid foundations so as not to fall back into the same traps and not be held back by later corrections.

Sylvain Melchior: And that's where architecture comes in, in this framing, this governance? How would you define the architect's role?

Yann-Éric Devars: The architect is there to prepare for the future, to build a house that lasts, not one thrown together quickly, or if it is, you'll need to plan for its later consolidation: sometimes necessity makes the law. Information systems are becoming more and more complex and interconnected, they last a long time and cost a lot. So they have to be solid, by identifying the places that most need to be. The architect builds things that are durable and economical to operate. That economic dimension is precisely the great forgotten aspect of architecture, and it's what I added in Dynamap SI. Today, many information systems break down for lack of fuel: since 2019, CIOs have almost all joined the executive committee. Before, it was the CFO who carried their voice and their budget; now CIOs face the executive committee but sometimes don't know how to talk about money, or how to explain the concrete benefits of the information system, and they end up in difficulty.

Yet no known architecture framework talks about economics, apart from Dynamap SI and NAF: Dynamap SI maps where to invest, why, what it will bring in and save, all within a logic of continuous transformation. Before, we thought in waves, in an industrial way: you renewed the estate, then started again. Today, voting a budget fixed for a year is completely out of step with a context of continuous transformation. You need to be able to react immediately to a new competitor, a new market, a new product. Transformation is continuous, so economics must be too: that's why everyone should have an architect.

Sylvain Melchior: That reminds me of a talk by Gregor Hohpe on the "antifragile" organisation: not building an unbreakable fortress, but a system able to absorb shocks, whether technological or regulatory, to stay competitive. Do you use that concept in Dynamap SI?

Yann-Éric Devars: In my engagements, yes; in the framework itself, no. The framework stays focused on a methodology to let everyone do enterprise architecture: you build maturity step by step. It's also a point of view! Thinking that TOGAF is the only reference is crazy: it was designed by the US Department of Defense, a million employees. No French company reaches that size, and our largest ones tend to operate in business units, like SMEs. Opening TOGAF today without a sufficiently mature enterprise architecture culture is guaranteed failure. You have to build up maturity progressively: use TOGAF if you like, but a framework like Dynamap SI will generally be enough.

Sylvain Melchior: When you step in at a client, what baseline are they starting from? A blank page, or a TOGAF that didn't take hold? What appeals to them in your framework?

Yann-Éric Devars: Several cases. The blank page, first: they don't even know an architecture framework exists. Then those who have already done TOGAF or Zachman, and who find that Zachman, although older, is actually less outdated because it's easier to adapt to modern methods. And then public services, which have to rely on French-language references, notably because of the Toubon law: for them, being sovereign all the way through also means using a French method. In general, TOGAF's complexity works strongly against it. There's also the "magic tool" approach: believing you're doing architecture by buying software that does the work for you. That doesn't work, because what's missing is the governance and the understanding of what architecture is, and the available training still talks about concepts from the 1980s. Dynamap SI modernises all that and delivers the benefits of architecture progressively. We often come in through a specific angle: the information system costs too much, the information system is too complex to repair, or projects don't reach completion.

Sylvain Melchior: ERPs, for example…

Yann-Éric Devars: Exactly. There are plenty of different entry points.

Sylvain Melchior: We see many ways in: cost, the technical side, transformations that stall. And compliance?

Yann-Éric Devars: More rarely, and that suits me fine, because the subject moves very fast. On the other hand, I make it a great deal easier. It's often my clients' own service providers who reach out to me: they want a method to understand the client's information system, explain it to the business and project it into the future, and that's exactly the goal of Dynamap SI.

Sylvain Melchior: You mentioned how the CIO communicates with the executive committee. Can architecture, or Dynamap SI, help them communicate better?

Yann-Éric Devars: Look at TOGAF's logic: "Go and see the business, gather their needs, adapt the framework and deploy." First the business processes, then IT, then infrastructure, then the project. That approach works poorly in SMEs, mid-market companies and public services, because you don't know what you have. In the public sector especially: heavy legacy, retirements, complexity that nobody fully masters anymore. And when you ask the business what it wants, it often doesn't even know all its own processes, nor fully the software it uses. What Dynamap SI specifies is the opposite: know your information system* before going to see the business, otherwise you'll get torn apart, because the business will know better than you the old software missing from your CMDB or the Excel file you're unaware of. You risk proposing solutions worse than what already exists, or discovering your information system at the same time as they do.

(* By information system, I don't mean only software and infrastructure, but also business objects, processes, and so on.)

Once you master your information system, the dialogue changes. The business expresses a need, and you can answer: "That's already done here." And then you enter a real exchange, not an interview. Because TOGAF is an interview, as if you already mastered your information system, and that's not the reality on the ground.

Sylvain Melchior: You also mentioned Solve DSI Studio. Can you tell us more?

Yann-Éric Devars: I eventually created the Studio to deploy the whole of Dynamap SI in a single piece of software, because many clients were asking me for it. It stops people ending up in Excel sheets or getting lost in external tools to produce the deliverables. The Studio is geared towards enterprise architecture: it's a repository, not a simple mapping tool. Knowledge is easy to find there, simplified, organised around the value chain and the company's vital assets, with impact-analysis capabilities in the event of an incident.

Sylvain Melchior: We like to end our interviews with operational advice, "the ten labours of Yann-Éric." When you start an engagement, do you have convictions about the right way to discover a new information system?

Yann-Éric Devars: You have to discover the information system in the broad sense from the top, not from the tools at the bottom. People often say: "We have a CMDB, we know our information system." Not at all: a CMDB gives you your computer system, not your information system. Knowing the information system means knowing where information is vital, where it's strategic, where it's support. Take a large sporting-goods chain that went down at the back-to-school period or just after New Year: it would have enormous trouble recovering. At other times, the same outage would be absorbable. Knowing that is already essential, and inventory management is vital there, for instance, but every company is different. At a restaurant, saying "we're out of that dish" doesn't drive customers away. In a sports shop down at back-to-school time, people leave their trolley and rush to the competitor across the street: you benefit your competitors, and on top of that you disorganise yourself by having to put everything back on the shelves. So you have to profile the company, understand its value chains and what's vital, at both business and technical level. That's the CIO's job: to keep information flowing.

And the classic trap is that every department thinks it's vital, every one of them. It's a real problem, and the slightly funny side of it. The person in charge of printers will tell you: "If there are no printers, we don't sign contracts anymore, we have no customers." In most cases, the company carries on; yet sometimes he's right, and he's the only one who knows it.

Sylvain Melchior: Yes, like the salesperson convinced they bring in a hundred percent of revenue through the sheer force of their meetings.

Yann-Éric Devars: It's the notion of continuity. Some departments can disappoint without bringing the company to its knees; others, if they fail, bring it down. Each is often vital, but not at the same moment: an interruption of one or two hours doesn't carry the same weight depending on the time of year. Yet with an old vision of the SLA, you handle incidents in the order of contractual SLAs. The result: an incident on something vital comes after a non-vital SLA that's reaching the end of its window. Applying ITSM as is means losing interest in the value chain and handing power over the company's continuity to technicians. That's where CIOs find themselves in difficulty, caught between the old world and a new world that demands responsiveness.

Sylvain Melchior: It's fascinating. In any case, thank you so much for your time, Yann-Éric.

Yann-Éric Devars: A big thank you to you for this interview.