top of page
  • LinkedIn
  • Whatsapp

What if your digital transformation didn’t start with a tool?

Returning to functions, needs, and value creation before talking about solutions.


In digital transformation projects, the same reflex appears almost systematically: conversations quickly shift to solutions, tools, and platforms. ERP, CRM, EPM, HRIS, data tools, or business-specific applications… The categories are familiar, reassuring, and give the impression that progress is being made. Yet by jumping straight to solutions, we often miss what truly matters: the question of purpose.


What need are we really trying to address? Which pain points are we trying to resolve? Which functions need to evolve in order to create more value? This is precisely where functional architecture plays — in my view — a key role that is still too often underestimated.


Functional architecture makes it possible to return to the very essence of the organization: what it does, before deciding which tools it uses to do it. It forces teams to reframe the problem not in terms of solutions, but in terms of functions and business needs. This is why I systematically start my digital transformation projects with this step.


Personnage avec rouages

A framework… and above all, a dialogue tool

Functional architecture is first and foremost a way to think about the organization through its real needs. It helps ask the right questions: what are the key functions? Where is value created? What works today, what doesn’t, and why? Unlike approaches that focus directly on solutions or tools, it brings purpose back to the center of the discussion.


This is also what makes it such a powerful support for dialogue. Everyone can talk about functions. Even without being an architect, people can project themselves into what the organization does, how teams interact, and where friction or dependencies exist. Functional architecture creates a shared language between business teams, IT, and leadership. It serves as a foundation for concrete workshops, where the goal is less about producing a perfect diagram and more about building a shared understanding of the organization and its priorities.


There are, of course, well-established frameworks and methodologies for structuring enterprise architecture. Standards such as TOGAF (The Open Group Architecture Framework), Zachman, or broader Enterprise Architecture approaches promoted by organizations like The Open Group or BCG / Gartner provide proven models to think about the enterprise holistically—across strategy, processes, data, applications, and technologies.


These frameworks offer a systemic view, strong structuring principles, and valuable reference models to align IT and strategy. They are particularly relevant in complex, multi-entity, or highly regulated environments and represent a solid foundation for enterprise architects.


In practice, however—especially when working closely with business teams—these frameworks can sometimes feel too abstract, overly standardized, or disconnected from day-to-day operational realities.


A model designed for service organizations

Over the years, my experience has led me to develop a specific functional architecture approach for service, consulting, and technology organizations. These environments are unique: there is no tangible product, and knowledge, skills, and people are the primary drivers of value creation.


In this model, all functions are essential to the organization’s operation, but they do not all carry the same weight from a business perspective, nor do they contribute equally to value creation. I distinguish three major groups.


The first is the core business. In service organizations, this typically includes sales, talent, the matching of client needs with expertise, and delivery. This is where value is directly created.

The second group includes support functions: finance, legal, procurement, marketing and communication, IT, data, and analytics. These functions ensure the company runs smoothly and act as true business partners to the core business.


Finally, I deliberately introduce a third group very early on: business reference frameworks and core concepts. What are the key concepts handled by the organization? What are the foundational data entities? Who owns them? This work lays the groundwork for what comes next: data governance, golden sources, and eventually application architecture.


Archiecture fonctionnelle

A strategic lever—not an IT exercise

Working on functional architecture also makes it possible to address sensitive but unavoidable questions: which functions should be managed at group or international level, which should remain local or regional, where strong synergies are needed, and where local flexibility must be preserved.


These choices are not technical. They are deeply strategic. They reflect the company’s ambitions, its growth trajectory, and its approach to local versus global operations. This is precisely why functional architecture should not be confined to an IT architect’s exercise, but instead become a true decision-support tool.


From functional architecture to application architecture

Once these foundations are in place, the transition to application architecture becomes much more natural. Tools are no longer chosen “by category,” but rather aligned with clearly defined sets of functions, taking into account the company’s strategy, organization, and operational realities.


This approach helps avoid uniform and dogmatic models—one tool for everyone—in favor of more nuanced, realistic, and often more effective trajectories. Tooling then becomes a means to serve business ambition, not an end in itself.


Architecture

Digital transformation starts before tools

Digital transformation is not an IT strategy. It is neither an autonomous objective nor an abstract exercise carried out far from the field. It is a response to core business strategy challenges: value creation, performance, attractiveness, and the ability to evolve.


When used effectively, functional architecture makes it possible to bridge strategic vision and future operational choices. And perhaps most importantly, it helps organizations ask the right questions before searching for the right solutions.

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page