Someone shared another one of those enterprise architect versus solution architect infographics in my feed a few weeks ago. Clean two-column layout. EA on the left, SA on the right, bullet points about scope and depth and horizons. The usual.
These charts always leave out the person who, in my experience, is the one actually making a large program work.
You will not find this role on most of them. In the SAP and Workday worlds, we sometimes call them functional architects. Sometimes functional leads. Sometimes a senior consultant with a lead title and no architect in it at all. The label changes. The job does not.
The EA vs SA Map That Everyone Draws
Before I argue about the gap, it is worth saying what the usual chart gets right.
The enterprise architect owns the long view. Capability models, standards, the portfolio of applications a company is going to run three years from now and the ones it is going to turn off. TOGAF, the usual reference frame here, puts them in a strategy seat, worrying about business, data, application, and technology domains across the whole enterprise. McKinsey has written repeatedly about enterprise architecture as a strategic translation layer between business ambition and technology execution.
The solution architect owns one program. Pick the components, design how they fit together, make sure the end to end design holds up under integration and non functional requirements. On a large ERP program they are usually accountable for the technical shape of the whole implementation.
Both are real roles. Both are necessary. I have been one or the other on plenty of programs. The chart is not wrong. It is just incomplete.
The Role That Keeps Falling Off the Chart
Picture a global HR transformation. Workday is going in across sixty countries. The solution architect has signed off on integrations, security, environments, deployment approach. The enterprise architect has made sure Workday fits the ten year application strategy and the data governance model.
Who decides whether an organization should have its global grade structure drive compensation ranges, or whether comp ranges should sit outside the grade structure for executive bands? Who maps the business process for a cross border transfer so it does the right thing in payroll, benefits, time, and talent, in that order? Who looks at the SAP integration and realizes that the person record on the Workday side has to tie back to the position ID on the SAP side in a way neither vendor documents the same way?
Not the solution architect. Not the enterprise architect. The functional architect.
This is the person who understands HCM as a system of systems. They know how the modules depend on each other inside Workday. They know where the configuration decisions in Core HR constrain what Compensation and Benefits can do downstream. They know which of those decisions, once made, you will spend five years regretting.
On the SAP side the pattern is the same. Someone has to make sure Finance, HCM, Payroll, and SuccessFactors tell the same story about the same employee. Someone has to decide how an organizational change in FI shows up in HCM, and vice versa. Someone has to run the fit-gap and own the configuration design document that the configurators then build to.
In my practice, that is the functional architect. In other practices likely a gap or the most senior person on the team with no architect title at all. The work is the work.
What a Functional Architect Actually Owns
If I had to put a job description on it, these are the things the role carries that nothing else on the diagram carries.
- Cross module coherence. The configuration choices in HR, Payroll, Benefits, and Time all fit together, and the business process designs do not quietly contradict each other.
- Cross function integration at the business process level. A hire in HCM has to flow correctly into Finance, Procurement for provisioning, delegation of authority, and the IT identity stack. That handoff is a design, not an accident.
- The configuration design itself. On many programs the functional architect is the lead configurator, or at minimum the person who signs off on the configuration workbook before it leaves the design phase.
- Master data decisions that live in the business layer. Position management yes or no. Supervisory organization structure. Cost center hierarchy. These are configuration choices that behave like architecture, because they are nearly impossible to undo at scale.
- Translation. The business says "we want managers to approve expenses." The functional architect knows what that means in the actual tool, which workflow it drives, which security role it implies, and which three sentences in a policy document just became system constraints.
Technical depth matters here. Not infrastructure depth, usually, and not code. But a functional architect who does not understand how the system actually behaves under its own rules is a business analyst with an inflated title. The good ones can read a configuration guide, read a vendor roadmap, and read the data model of the thing they are deploying. The best ones can also tell you which release will break or give you endless headaches.
Why This Role Keeps Getting Classified as the VERY Senior Consultant
The industry has a bias here, and it is worth naming.
Architecture, as a job family, has mostly been defined by people whose work is upstream of configuration. Capability models, reference architectures, selection decisions, infrastructure patterns. All important and closer to what senior IT leadership thinks of as architecture because it maps to the way IT portfolios are governed.
Configuration, by contrast, has been treated as implementation. Someone else's job once the architecture is "done." That framing was never quite right for packaged enterprise software, where the configuration IS the architecture of your business process inside the tool. But the framing has stuck, and the job title has not.
In practice this shows up on day rates, on org charts, and on where the role sits in a program's governance. The solution architect sits on the steering committee. The functional architect sits in the module team and gets pulled into the steering committee when something breaks.
There is no clean career path from consultant to functional architect the way there is from engineer to technical architect. Which is a problem, because the people who do this well are mostly self taught, learned on numerous programs, and are not replaceable in a hurry.
What Breaks When the Role Is Not on the Chart
I have seen this in person more than once. A program names an enterprise architect and a solution architect. The functional work gets delegated to the module leads, who are, at that point, mostly focused on their own module. Nobody owns the horizontal view at the business process level much less the interconnections between processes.
Six months later: HCM and Finance have both configured organizational hierarchies that cannot be reconciled. Payroll and Benefits have both decided they are the system of record for one specific data element. The integration layer is quietly stitching things back together with transformation logic that nobody is going to want to maintain in production.
By the time anyone surfaces the problem, three design decisions are already baked and the fix is either a change order or a workaround that will show up in a Gartner post mortem five years later as a textbook example of why ERP programs fail at integration.
The industry has written a lot about why those programs fail. Gartner, Deloitte, and Panorama Consulting all publish on it regularly. Underneath most of their findings is a quieter failure, which is that nobody on the chart was explicitly accountable for the horizontal coherence of the business process design.
Alas, the role is left out most of the time anyway because of cost and the assumption that the team will be able to figure it out as they go...hopefully. On the sales side, where this role is most prevalent, the role sets the stage then the actors never actually get the updated script.
Is There a Better Name for This Role?
I do not know. I have been using functional architect for years because it describes what the person does, but the title is uneven across the industry. In some shops it is a brand, in others it is a seniority marker, in others it does not exist at all.
Business process architect gets you partway there. Module lead sells it short. Senior functional consultant sounds like a billing level, which is often all it is. ERP architect is close in the SAP and Oracle world but excludes the Workday and ServiceNow equivalents.
Whatever we call them, these are the people who make the difference between an ERP program that works and one that quietly compromises on a few integration points until the end state is held together with middleware and user training.
If you are planning a large program, draw them on the chart. Give them a seat at the governance table. Pay them accordingly. The alternative is to discover, in production, that the architecture of your business process was being written by the people with the least authority to make it stick.
If you want a second set of eyes on how your program is staffed before design freeze, that is a conversation I am glad to have. Reach out through AJA Software Solutions.
Comments
Post a Comment