Who Solutions Architecture Serves: Internal and External Customers - Solutions Architecture Best Practices and Framework
Who Solutions Architecture Serves: Internal and External Customers
(Chapter 6 of Solutions Architecture Best Practices and Framework)
Executive Summary: Chapter Overview
IF4ITThe Bottom Line
Core Concepts
| Concept | Definition & Strategic Role |
|---|---|
| Internal Customer | The internal Business unit(s) that own the problem being solved, or IT itself when IT is the party with the problem — a legitimate Customer in its own right, not merely the department that always sits on the delivery side of an engagement. |
| External Customer | A separate enterprise engaging Solutions Architecture as a professional service, the same way large consulting practices do — the Solutions Architect works on that enterprise’s problem, not the servicing firm’s own. |
| What changes between them | Who owns the resulting SARB and whose governance applies both follow directly from who the Customer is. What differs most for external engagements is where reusable knowledge goes: not into the client’s own EA Platform, but into the servicing firm’s own cross-client knowledge base — the accumulated patterns and reference architectures large consulting practices build and reuse across many clients. |
| One practice, either way | The practice of Solutions Architecture does not change based on who it serves — the same Framework, Dimensions, and SARB apply either way. What changes is entirely on the receiving end: who gets the SARB, whose governance reviews it, and where the engagement’s own lessons end up living. |
Quick Q&A
Question: Is IT ever the Customer of a Solutions Architecture engagement, or only the Business?
Question: Does an external engagement feed the same EA Platform an internal engagement would?
Read More Below
Overview
Every Solutions Architecture engagement has a Customer — the party who owns the problem being solved, and who ultimately decides among the Solutions Options presented in Phase 4. Who that Customer actually is falls into one of two categories: an Internal Customer, or an External Customer.
An Internal Customer is the Business unit or units that own the problem, or IT itself when IT is the party with the problem being solved. IT is a legitimate Customer in its own right — an engagement modernizing an internal platform or resolving IT’s own technical debt is still Solutions Architecture serving a Customer, not merely internal delivery work.
An External Customer is a separate enterprise, engaged the same way large consulting practices such as KPMG or PwC serve their own clients: Solutions Architecture offered as a professional service to an organization outside the servicing firm’s own walls.
The practice itself does not change based on which kind of Customer it serves — the same Framework, the same Dimensions, the same discipline around vetting a current state and presenting objective options applies either way. What changes is entirely on the receiving end: who ultimately owns the completed SARB, whose ARB or TRB reviews significant options, and — most consequentially — where the engagement’s own reusable knowledge ends up.
For an Internal Customer, this is already established throughout this document: the SARB is delivered to the Customer, stored in the Architecture Repository, and its vetted data folds back into the same EA Platform the next internal engagement will draw on. For an External Customer, the client still receives and owns their own copy of the SARB — but the engagement’s broader, reusable knowledge does not fold into that client’s own EA Platform. It feeds the servicing firm’s own cross-client knowledge base instead: the accumulated patterns, reference architectures, and lessons that large consulting practices build up and reuse across many different clients, the same way KPMG, PwC, and similar firms do.

Best Practice: Identify Which Kind of Customer This Engagement Serves Before Vision Development Begins
Confirm, as part of Phase 1, whether this engagement’s Customer is Internal or External — not as a formality, but because it determines who ultimately owns the SARB, whose governance applies, and where this engagement’s own reusable knowledge should actually go once it concludes.
Benefit(s)
Knowing this early avoids a costly mistake: treating an External engagement as if its patterns and lessons would automatically reach future clients the way an Internal engagement’s findings automatically reach the next internal one. Reusable knowledge from an External engagement has to be deliberately abstracted and captured into the servicing firm’s own knowledge base — it does not happen by default the way it does internally.
How to cite this page
When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.
Example (informal web citation):
The International Foundation for Information Technology (IF4IT), LLC. Who Solutions Architecture Serves: Internal and External Customers | Solutions Architecture Best Practices and Framework. https://if4it.org/best-practices/solutions-architecture/who-solutions-architecture-serves-internal-and-external-customers/ (accessed 2026-10-26).
See About Us for content governance and site-wide citation guidance.
Copyright for The International Foundation for Information Technology (IF4IT), LLC: 2008 - Present
Legal Disclaimers