APV – Assets, Perspectives, Views
🧩 Why vocabulary matters more than technology
Automotive solved this systematically — 8D (Ford Motor Company, 1980s), Lean, Six Sigma, QRM. In manufacturing companies, the cost of poor quality is standard agenda. In IT companies, what I have mostly encountered is declarations, not action.
Quick Response Manufacturing (Rajan Suri, 1990s) explicitly extended its principles to office and knowledge work processes — precisely the domain where SDLC lives. The message is the same: without shared vocabulary, you cannot measure. Without measurement, you cannot improve.
Where APV comes from
APV did not emerge from academic research. It emerged from production lines.
My degree was in Technical Cybernetics — measurement technology and automation. The core principles: fast feedback, deviation detection, proportional corrective action. These apply not only to industrial control systems. They apply equally to managing organisations.
After graduating, I spent several years in manufacturing — consumer electronics (Philips, Sagem) and automotive components (Wabash Technology). I worked on product quality using SPC (Statistical Process Control), GR&R (Gage Reproducibility and Repeatability), Six Sigma, 5S, and 8D.
These were not just tools. They were a shared vocabulary. Everyone on the production line — from technician to manager — understood what "out of control" meant, what "root cause" meant, what "corrective action" meant.
When I moved into IT, I encountered something unexpected: the vocabulary was missing. The same word meant different things to different roles. "Architecture" for an infrastructure engineer and "architecture" for a business analyst were two different things. Projects failed not because of missing technology, but because of missing shared understanding.
APV is the framework I developed to address this.
The APV framework
- Assets — what exists and needs to be managed
- Perspectives — who looks at it and from which angle
- Views — what they actually see, filtered for their role and context
The goal: keep your solution's assets in order, across all roles, across all SDLC phases.
Physical Map of Enterprise vs Digital Map – the two realities that APV bridges
Reference Model vs Instance Model – how APV separates the blueprint from the reality
APV Framework layers – Business, Systems, Technologiers in structural context
APV pillars – Assets from Perspectives of specific Stakeholder visualised on Views
APV relationship between Reference and Instance model – how the blueprint connects to deployed reality
APV practical example – applying Assets, Perspectives, Views in a real project context
APV process in daily live. From conceptual element to vocabulary
Before building any model or document in your SDLC:
- What asset are we describing?
- From whose perspective are we looking at it?
- What view does this stakeholder actually need to see?
APV implementation steps
- Identify your key Assets — what solution elements need to be modelled and managed
- Map your Stakeholders and their perspectives — who cares about what
- Define Views — what each stakeholder actually needs to see (not everything, just their relevant slice)
- Implement in your tooling (Enterprise Architect, GitHub, or any structured repository)
- Iterate — vocabulary evolves with the solution
SFIA – Skills Framework for the Information Age
If APV addresses the vocabulary of solution assets, SFIA addresses the vocabulary of the people who deliver them.
Where APV keeps your solution assets in order, SFIA keeps your team's capabilities in order. Both frameworks solve the same root problem from different angles: without shared vocabulary, you cannot measure, and without measurement, you cannot manage.
→ See the dedicated page: K000107 – SFIA
You do not need to build a full taxonomy to benefit from one. The goal is to have one authoritative source that all roles can rely on. Start with the vocabulary that crosses the most boundaries in your organisation.
← Back to K000107 overview · TBM – Technology Business Management →