A data architect consultant decides how information should be structured across an organization: which system holds the master copy of each record, how data should move between systems, how it should be stored and modeled, and who should be accountable for each measure. The output is decisions and documentation rather than working software. That distinction confuses buyers regularly, because the title sits next to engineering roles that produce something visible at the end of a sprint.
What the Role Actually Produces
A useful engagement produces artifacts that outlast it. If the deliverable is a slide deck and a set of verbal recommendations, the decisions will not survive the next staff change.
A current-state map. What systems exist, what each one holds, how information moves between them, and where manual steps sit in between. This is usually the first time anyone has seen the whole picture in one place, and it frequently changes the conversation on its own.
A systems-of-record register. For each data domain, the single system that is authoritative, and the tie-break rule when a second system reports something different.
A target-state design. What the structure should look like to support the business the organization expects to be, rather than the one it was when the current systems were chosen.
Connection standards. Not individual connections, but the standard approach a team should apply whenever a new system arrives. This is what stops the count of point-to-point connections growing faster than the number of systems.
A sequencing plan. What order the work happens in, what depends on what, and what can be deferred without creating rework.
A governance model. The rule for who may change a definition, what approval that requires, and where accountability sits when a figure is disputed.
What the Role Is Not
Not a data engineer. Engineers build the pipelines, write the transformations, and operate what runs. An architect decides what should be built and why. Both are necessary. Engaging an architect and expecting pipelines, or engaging engineers and expecting a structure, is a common and expensive mismatch.
Not a BI developer. Report and dashboard building is downstream work. It can only present what the structure beneath it permits, and it cannot compensate for decisions that were never made.
Not a platform reseller. Some firms describing themselves as architecture consultancies are primarily implementation partners for one vendor. That is a legitimate business, and it is a different service. The distinguishing question is whether the engagement could conclude with a recommendation not to buy the platform.
What “Modern Data Architecture Consultant” Signals
The word modern is doing real work in that phrase, and it is worth knowing what it usually refers to.
It generally means cloud-native rather than on-premises, lakehouse patterns that hold structured and semi-structured data together rather than a warehouse alone, transformation applied after loading rather than before, and the ability to handle streaming alongside batch. In practice, it points to environments built on Microsoft Fabric, Databricks, Snowflake, or Azure services, with Power BI or an equivalent at the reporting layer.
What it should not mean is a preference expressed before the requirements are known. A consultant who arrives with the target architecture already selected is describing their practice rather than your business. The relevant question is which of those patterns your data volumes, latency needs, and reporting obligations actually justify, and the honest answer for many mid-market businesses is a smaller subset than the category name implies.
Decisions first, then the build. Stratiform Group works with executive teams on the structural decisions that determine whether implementation work pays off.
When to Bring One In
The role is triggered by decision points rather than by a steady workload. Five recur.
A platform decision is pending. The most valuable timing, and the most commonly missed. Once a platform is selected and configured, the structural assumptions are set, and revisiting them means rework.
An acquisition has closed or is approaching. Two organizations arrive with independently reasonable structures that now have to produce one consolidated view. This is architecture work before it is integration work.
An implementation underdelivered. The platform went live, the reports are produced, and leadership still does not trust them. That outcome usually traces to decisions never made rather than software that failed.
Reporting cannot be traced. When the origin of a headline figure requires a conversation rather than a lookup, the reporting problem sits below the reporting layer.
Leadership has changed. A new CFO or COO inherits a structure nobody documented and needs an accurate picture before committing to a direction.
When an Architect Is the Wrong Hire
If the current structure is working, if reporting closes on time and nobody disputes the figures, and if no change is planned that the structure would have to absorb, then the honest recommendation is to wait. Architecture work done in the absence of a forcing question tends to produce a thorough document that nobody uses.
Equally, if the problem is clearly a build problem (a pipeline that fails, a slow report, a connection that needs writing), then engineering capacity is what is needed. Bringing in an architect to solve a build problem adds a planning layer to work that was already well defined.
In-House or External
A permanent data architect makes sense for organizations with continuous structural change: many entities, frequent acquisitions, or a large system estate under constant revision. The role stays busy, and continuity is worth paying for.
Businesses at this scale typically face these decisions in concentrated bursts, around a platform selection, a transaction, or a restructure, with quieter periods between. A permanent hire in that pattern spends much of the year on work that is not architecture, and the specific experience of having seen many environments is what the role depends on most.
There is also a practical point about independence. An external architect has no stake in preserving decisions they made two years ago, which matters when the honest finding is that an earlier choice should be reversed.
How to Evaluate One
Four questions separate a structural engagement from an implementation pitch.
- What will I have at the end that I can hand to a new CFO or a new engineering team?
- Under what circumstances would you recommend we do nothing, or delay?
- Which platforms have you recommended against, and on what basis?
- How does this engagement account for what the business expects to look like in three years, not just today?
The second and third questions are the most informative. A consultant who cannot describe a situation in which they advised against a build is describing a sales process.
Bring the Structural Questions Forward
If you are choosing a platform, integrating an acquisition, or working out why an implementation did not deliver what was expected, the structural decisions are the ones that determine the outcome. They are also the cheapest ones to get right early and the most expensive to revisit late.
Stratiform works with CFOs, COOs, and senior data leaders at mid-market and private equity backed organizations on exactly these decisions, and produces documentation that stays useful after the engagement ends.
Ask the questions before the configuration settles them. A structured review establishes current state, target state, and the sequence between them.