Information Technology
Enterprise Architecture
Consulting Firm

Published at

By Sylvain Melchior

Enterprise information system, business trajectory and collective intelligence: how to activate a living architecture?

The understanding of the information system and the business can no longer be the exclusive domain of the IT department. To create greater value, this knowledge must circulate, evolve and grow through engagement with the business. How can access to this knowledge be democratised, and how can everyone be enabled to contribute?


In this article, we bring together two committed experts: Arthur, enterprise architect at Projexion, and Sylvain Melchior, CEO of Boldo, publisher of an enterprise architecture co-pilot. Together, they share their vision of a living, contributive and actionable knowledge, accessible to everyone in the organisation.


What does “information system knowledge” really mean today, beyond traditional maps?

Sylvain: Knowledge of the information system is far more than a technical inventory. It spans several dimensions. There is the detailed understanding of each asset: applications, systems, infrastructure components. But that alone is not enough. What really matters is understanding how these assets interact, in other words, orchestration. That is the difference between a list of technical elements and a truly useful representation of the information system.

Mapping clearly has its role, but we need to be precise about what we mean. A static PowerPoint diagram is not sufficient. Mapping should serve as the single source of truth for assets and their relationships. It becomes valuable when combined with visual projections such as diagrams, charts or tables, which support data-driven decision-making.


Arthur: Agreed. We also need to move beyond a deliverable-based mindset. Real system knowledge is not what we print in a document, it is what we share and use to guide transformation. It connects assets to business goals, and the other way round. The information system is here to support the company’s strategy and respond to operational needs.

Many people still hear "IT system" when we talk about the information system. But it is much broader. It includes business processes that may be only partially, or not at all, digital. These processes still structure activity and form part of the knowledge landscape.


"Information system knowledge is not limited to what’s inside the IT system."


Sylvain: Exactly. We must reverse the lens. Start with the business, its capabilities, and the people involved, then work down to applications, processes, data and infrastructure. Mapping is not about adding layers of complexity, it is about making them legible and usable.


"The aim of mapping is to simplify how the system works and provide users with a clear view."


Why must knowledge of the information system and the transformation trajectory be shared?

Arthur: As a consultancy supporting transformation projects, we see every day that transformation is not just the concern of management or IT. Everyone contributes. The people who implement change, guide teams and adapt tools are the employees. To be effective, they need access to knowledge that gives meaning to what they do and helps them understand its purpose.

In architecture missions, I often meet people who know exactly what to do, but not why or how it fits into a wider context. Today, purpose is a key success factor in transformation. When an application manager understands how their work connects with an infra architect, a business unit or an integrator, they gain perspective, suggest improvements and become more engaged.


Sylvain: Absolutely. There is a basic human need to feel useful, aligned and effective. Understanding the purpose of an action increases engagement and improves execution.

Operationally, every transformation creates ripple effects. A change in one area can impact others. This is why sharing a broader vision helps anticipate issues, reduce friction and avoid unintended consequences.

At Boldo, we see this clearly in digital transformation projects. These projects are developed for business teams, and with business teams. They need clear access to knowledge so they can check that designs meet their needs. Sharing knowledge smooths alignment and iteration cycles and helps avoid misunderstandings. It also demystifies the workload related to change.


"Sharing knowledge is a key lever for change management and team engagement in transformation projects."


Arthur: Let me emphasise one point. Sharing does not mean simply distributing. It also means enabling everyone to contribute to the construction of knowledge. Each person in the organisation holds a piece of operational truth. This distributed and collaborative approach helps build a more complete picture, with real and contextual input. This applies across all departments, whether sales, marketing, production or IT.

"Information system knowledge should not only be shared, it must be co-built by those who live it every day."


Sylvain: And we should not forget that this knowledge is not limited to internal use. In many companies, the system interacts with partners, suppliers and customers. Where relevant, part of the knowledge can be opened to the outside. This depends on company culture and the specific industry.

There are three levels to consider: internal teams, the external ecosystem and the regulatory framework. This last one can heavily influence how knowledge is shared. In the banking sector, for example, the DORA regulation requires increased transparency and traceability. In this context, structuring and sharing system knowledge becomes a strategic necessity.


What are the key factors in sharing knowledge and managing transformation?

Arthur: The first factor is company culture. There is no universal model. Some organisations promote radical openness, where everyone can access everything. Others prefer a compartmentalised approach. Neither is inherently right or wrong. What matters is whether the sharing is useful. Does it add value? Could it overload users? Does it align with company culture?

Sharing system knowledge is not about pressing “publish”. It is a process. You need to align openness with cultural norms, anticipate risks such as cybersecurity, confidentiality or cognitive overload, and above all, support the change. In organisations where this is new, expect legitimate concerns: what is my role in this? what is expected of me? why now?


Sylvain: Yes, the human aspect is real. We are not just publishing an Excel file. We are creating a knowledge system that affects people with very different roles, viewpoints and responsibilities. This is where governance plays a key role. It should define clear rules without creating rigidity or unnecessary friction.

Tools also matter. This is one of the reasons we created Boldo: to bridge the macro view, which gives people strategic context, with the micro view, which enables action. The system is complex. That must be accepted. But it should be made readable and relevant from every perspective.


"The role of tools is to simplify the system and provide each person with the right view, according to the value it brings them."


How can we structure a knowledge approach that is accessible, understandable and actionable?

Sylvain: The process has two stages: the initial launch and ongoing operations. Too often, organisations focus only on implementation and forget sustainability.

It usually starts with a triggering event: an upcoming audit, a company acquisition, a major ERP or CRM deployment, rising risk or a critical incident. That is when the need for structured knowledge becomes urgent. And that is when the project gains traction. Just saying “we’re consolidating knowledge” is not persuasive. You have to prove its usefulness.


"The real question is always this: what is the concrete ROI, for which scope, and for whom?"


Once this initial trigger is defined, you can start onboarding the existing knowledge—Excel files, interviews, CMDBs. Nothing should be discarded. The aim is to build a usable version, not a perfect one. The 80/20 rule is helpful here: create a structured draft, then iterate and validate with subject-matter experts. Better to start with a rough structure than with a blank page.

That first version often reveals insights the organisation never had before. Once people perceive the value, it is easier to secure ongoing commitment and gradually scale the effort.


Arthur: Yes, but from the outset, you need strong sponsorship. And you must define a clear intent: why are we doing this, who will benefit, in what format, and at what level of detail? These answers help connect the work to governance frameworks, decision-making processes and change management routines.


"To be sustainable, the knowledge must be kept up to date and integrated into everyday processes."


You also need to consider the human element. Some individuals might feel they are losing ownership if the knowledge they once held privately is now shared. They should be involved early, the project’s purpose explained clearly, and their input included in relevant decision forums.


Sylvain: That is where we move from half-success to full activation. We are no longer talking about building knowledge from scratch. We are maintaining it over time. That means defining update rhythms, connecting to existing processes, and organising review moments. And the benefits become very real. When a business user says, “Now I know who to ask for this data” or “I feel more autonomous,” that is the sign that knowledge has become truly actionable.


What advice would you give to organisations looking to promote cross-functional knowledge?

Arthur: My first recommendation is this: avoid exhaustive modelling. The TOGAF framework says it clearly, only model what is actually used. If an item is well documented but never used, then it is a waste of time.

You have to pick your battles. A partial map that is actively used and maintained brings more value than a complete map that becomes obsolete within three months.


"Better to map 20 percent of your knowledge and keep it alive than 100 percent and never update it."


There is no single right method. Organisations must adapt to their own context and working culture. In some cases, simply providing updates proactively is enough. In others, it becomes routine because it is embedded in governance. It is about finding balance, not enforcing doctrine.


Sylvain: At Boldo, we started with a simple belief: the foundation is how easily people can consume knowledge, in other words, storytelling. Our priority was to make system knowledge clear, engaging and simple to use. We come from digital transformation projects, we have been product owners, project managers and service providers. We know that if something is complicated, it will not be used.

Only after that did we add rights management, ownership and confidentiality rules. Our starting point was always this: every role should be able to access knowledge in a way that suits them.


"Knowledge is only useful if it is readable and presented in a way that makes sense to each user."


A CFO is not looking for a UML diagram. They want to understand costs. A tech lead needs a technical diagram. A CEO wants a nested map with key insights. At Boldo, we use a common data layer and offer multiple formats: plain tables, dashboard-style dataviz, animated diagrams for process flows. Everyone has their own entry point.

For mid-sized businesses, enterprise architecture may be less mature than in large corporates. But the need is just as pressing: acquisitions, restructurings, rapid growth. That is why starting with simple, measurable use cases can show quick ROI and bring teams on board. Information accessibility becomes a key enabler for these organisations.


Arthur: In summary, knowledge of the information system can no longer remain in the hands of a few isolated experts. To support transformation, it must be shared, actionable and understood by everyone who contributes to the evolution of the organisation, whether in business or IT.

Tools are accelerators, but the real success comes from collective capacity to structure, maintain and bring this knowledge to life over time.

The question is no longer “should we structure this knowledge?”, but “where do we start, with whom, and for what purpose?”