Enterprise Architecture Assessment
When every business initiative takes longer than planned, the bottleneck is almost always the architecture. We evaluate how processes, data, applications and technology fit together, where the architecture is holding the business back, and build the roadmap to release it.
The assessment surveys the four architecture layers —business, data, applications and technology—, identifies the points where the current design prevents or inflates the cost of what the business wants to do, and builds the target architecture with a prioritised transition roadmap. It is not a diagram: it is a diagnosis of your capacity to change.
Understand why everything takes so long
Where the current design multiplies the effort of every new initiative.
Define where to go
An explicit target architecture, not an implicit technical preference.
Order the transition
What to change first to unblock what the business already has on its agenda.
One surveys and maps the route. The other executes it.
These are two different services and it is worth knowing which one you need before contracting. The assessment does the first information-gathering exercise, builds the roadmap and aligns it with the business areas. The consulting practice executes that roadmap.
Enterprise Architecture Assessment — this page
Surveys, maps and aligns. It surveys the four architecture layers, identifies the friction points, defines the target architecture and builds the transition roadmap agreed with the business areas. It runs two to four weeks depending on the size of the organisation. It does not implement, does not configure and does not operate anything.
Enterprise Architecture — execution
Executes the roadmap. It takes the roadmap and executes it: detailed design, standards definition, architecture governance and support through the implementation of each transition. It works just as well if you already have a roadmap of your own.
Eight fronts, from business to technology.
Friction is rarely where you look for it. We review the four layers and the fronts that cut across them, rating each one for maturity.
Business architecture
What capabilities the organisation sustains, which processes execute them and where they are duplicated across areas.
Data architecture
Where each piece of data originates, who owns it, how many versions exist and which one counts as true.
Application architecture
Which systems exist, what capability each one covers and where they overlap or leave holes.
Technology architecture
The platform, network and cloud everything runs on, and whether they support what you want to build.
Integration
How systems talk to each other: interfaces, dependencies and what breaks when one end changes.
Architecture governance
Who decides on design, on what criteria and at which point in a project's cycle.
Standards and principles
What design rules exist, whether they are applied in practice and how exceptions are handled.
Architectural debt
Past decisions that constrain you today, with their carrying cost and their cost to correct.
Six phases, without interrupting your operation.
The assessment rests on interviews, documentation review and portfolio analysis. There is no intervention on your systems at any point.
Scope and preparation
We define which capabilities, processes and systems are in, and agree access to documentation.
Business interviews
With the process owners, to understand what the business wants to do and what is holding it back today.
Layer survey
Processes, data, applications and technology, with their dependencies and integrations.
Gap analysis
Comparison against TOGAF and ArchiMate, layer by layer, between the current and the desired architecture.
Target architecture
Definition of the desired state and of the transitions needed to reach it.
Business alignment
Presentation of the roadmap with leadership and the areas, so priorities are agreed.
What your maturity is measured against.
The evaluation does not rest on the judgement of whichever consultant shows up, nor on a vendor catalogue, but on public and auditable frameworks your team can consult and your auditor will recognise. TOGAF is an international framework, but the architecture it orders operates under local conditions —suppliers, connectivity and regulation in Colombia and Mexico— and that is how it is assessed.
TOGAF
Evaluation framework. The architecture development method: it defines the layers, the gap analysis and transition planning.
ArchiMate
Modelling language. Standard notation for representing architecture so business and technology read the same thing.
ISO/IEC 42010
Description guide. How an architecture is documented: views, stakeholders and each one's concerns.
COBIT 2019
Governance guide. Orders who decides on architecture and how compliance with standards is controlled.
IT4IT
Value-chain guide. Connects the architecture to the real flow running from strategy to operation.
BIZBOK
Capability guide. Reference for mapping business capabilities before descending into systems.
The frameworks are public and verifiable: anyone on your team can consult them and check the rating we deliver. That is the difference between an auditable evaluation and an opinion.
What it costs to build without a blueprint.
Architectural debt does not produce incidents: it produces slowness. That is why it rarely has an owner until it blocks an important initiative.
Initiatives that get more expensive
Every project pays the cost of integrating with what already exists, and that cost is never budgeted.
Data that contradicts itself
Several sources for the same figure and none designated as true; decisions get argued instead of taken.
Fragile integrations
Point-to-point connections nobody documented, which break whenever either end changes.
Duplicated capabilities
Two areas solve the same thing with different systems, and neither wants to give up its own.
Decisions without criteria
With no design principles, each project chooses differently and complexity accumulates.
Dependency on whoever built it
The architecture lives in one person's head rather than in a document someone else can read.
What it costs you in time, said upfront.
An assessment that does not state the commitment it requires ends up delayed. This is what we need from your side to deliver on time.
Two to four weeks
Two weeks in organisations of up to 50 employees; four between 51 and 300. The timeline is agreed before starting.
Scheduled interviews
Sessions with process owners, architects or technical leads, and the business areas affected.
Read-only access
Queries against the platforms and existing documentation. At no point is a configuration modified.
A single point of contact
One person coordinating schedules and access. It is the factor that most affects hitting the deadline.
Whatever documentation exists
Existing diagrams, application inventory, integration contracts and documentation from previous projects.
A closing session
The presentation of findings with leadership and the areas involved, where the roadmap priorities are agreed.
When it makes sense and when it does not.
It makes sense if…
Every new initiative takes longer than estimated; there are recurring arguments about which figure is correct; you are about to undertake a modernisation or a migration; or you want to understand why the cost of changing grows with every year that passes.
Probably not if…
You already have the target architecture defined and are looking to execute it: go straight to Enterprise Architecture. Or if your question is what to invest in rather than how it is designed, that is answered by the Technology Strategy Assessment.
What you gain from the assessment.
Friction pinpointed
The exact points where the current design inflates the cost of every initiative.
An explicit target architecture
A documented desired state that stops depending on the judgement of whoever is available.
An orderly transition
What to change first to unblock what the business already has on its agenda.
Data with an owner
Which source is true for each piece of data, and who answers for it.
Faster decisions
Explicit design principles that stop the same argument recurring in every project.
Quantified debt
The carrying cost of past decisions, expressed in effort rather than opinion.
Why this evaluation and not a diagram.
The difference is not in drawing what exists: it is in explaining what prevents what the business wants to do and what it costs to correct.
Evaluation, not diagram
A drawing of the current state does not say what is holding the business back. Friction is measured against what you are trying to achieve.
Recognised frameworks
The comparison is against TOGAF and ArchiMate, in standard notation your team can maintain afterwards.
Business language
Each gap with the initiative it blocks and the overrun it causes, not in technical terms.
Vendor independence
The target architecture is not shaped by whichever platform would suit us to sell.
No interruption to operations
Interviews and document review. No intervention on production systems.
Continuity into execution
If you decide to proceed, the roadmap connects with Enterprise Architecture without starting the survey again.
As-Is, To-Be and the plan to get from one to the other.
Every assessment closes with the same structure, whatever the practice: where you stand today, where you need to be, what separates the two states and in what order that distance gets closed.
Current state — As-Is
The starting point surveyed with evidence, not declared in an interview: what exists, how it operates and how far it sits from what the business needs.
Target state — To-Be
Where the organisation needs to get to, defined with the business areas rather than imposed by the consultant. It is the benchmark everything else is measured against.
Gap analysis
Every difference between the As-Is and the To-Be, with everything required to close it: technology, processes, people, governance and budget. No gap is stated without what it demands.
Risk matrix
Each gap rated by probability and business impact, so priority does not depend on who pushes hardest but on what it costs to leave it open.
Work plan
The concrete sequence to reach the To-Be: what comes first, what it depends on, how much effort it takes and who should answer for each front.
Business alignment
The plan is presented and agreed with the areas involved. A roadmap signed only by IT does not survive the first quarter.
How what you receive is structured.
The central deliverable is a report with a fixed structure, designed so leadership reads the first pages and the technical team works with the rest.
Executive summary
Two pages: architectural maturity level, the three friction points that weigh most and what decision each one calls for.
Maturity by front
Rating of the eight fronts with the gap made explicit against TOGAF.
Current architecture map
The four layers and their dependencies, in ArchiMate notation.
Target architecture
The desired state and what separates it from the current one, layer by layer.
Transition roadmap
Changes prioritised by business unblocking against effort, with sequence and dependencies.
Immediate actions
What can be corrected or documented without a project or additional budget.
What you receive at the end.
- Current state (As-Is): map of the standing architecture across the four layers, in standard notation, with a maturity rating per front.
- Inventory of integrations and dependencies between systems.
- Inventory of architectural debt with estimated carrying cost.
- Target state (To-Be): destination architecture with views per stakeholder, agreed with the business areas.
- Gap analysis between the As-Is and the To-Be, with each gap, its evidence and everything required to close it: systems, integrations, data, capabilities and governance.
- Risk matrix: each gap and each debt item rated by probability and business impact.
- Work plan to reach the To-Be: transition prioritised by business unblocking, with sequence and dependencies.
- Recommended design principles and standards.
- Executive presentation for committee and leadership.
- Alignment session with the business areas involved.
About the Enterprise Architecture Assessment.
What exactly do you evaluate?+
How does it differ from architecture consulting?+
Do we need to have diagrams already?+
Do you deliver the models in a format we can maintain?+
Does it interrupt our operation?+
Who should take part on our side?+
Is it the same as a technology strategy assessment?+
How often should we repeat it?+
Know what is holding every initiative back.
Book your Enterprise Architecture Assessment and get the four-layer map, the target architecture and a transition roadmap prioritised by business unblocking.
Book my assessment → See the Enterprise Architecture →