TOGAF 10 Stakeholders: Identification, Concerns, and Architecture Requirements

Stakeholder Definition in TOGAF 10

In TOGAF 10, a Stakeholder is defined as an individual, team, organization, or class thereof having an interest in a system. Interest is not limited to economic benefit; it includes anyone who can influence the system, is affected by it, bears responsibility or risk for its outcome, or holds explicit rights, demands, or constraints relative to it. The key judgment is whether a substantive relationship exists with the system, not project membership or job title.

Case Study: HR Management System

A large group builds a unified HR management system covering organization, personnel, recruitment, performance, compensation, training, and employee services. Stakeholders include:

HR Department – owns HR policies, processes, and management requirements that run through the system.

Group Leadership – rarely logs in but needs talent structure, headcount, key-position gaps, and labor-cost visibility for decisions.

Business Department Heads – hire, transfer, evaluate staff; system design directly affects daily management.

Employees – use the system for leave, transfer, attendance, performance, compensation queries, training, and personal data.

Finance, IT, Audit, Legal, Compliance, Security – finance cares about payroll and labor cost; IT builds and runs the system; audit/compliance require policy enforcement, access control, and audit trails; security protects personal and sensitive data.

External parties (recruitment agencies, training providers, assessment firms) also qualify if the business outcome depends on them or architectural changes alter the business/data relationship. Organizational boundary ≠ stakeholder boundary.

Crucially, users ≠ stakeholders . Employees are daily users and stakeholders; leadership may never log in but remains a key stakeholder; audit may not use the system but dictates mandatory data retention and operation logging.

Step 1: Define the Analysis Object

Stakeholder identification starts by asking "Stakeholders of what ?" The scope changes with the analysis object:

Group HR management system – broad scope: executives, HR, business heads, employees, finance, IT, audit, external service providers.

HR management system construction – narrower: roles involved in building and running the system.

Leave-approval feature optimization – even smaller scope.

The same role may have different importance under different objects. Without a clear boundary, relevance cannot be determined.

Step 2: Six Questions to Identify Stakeholders

Instead of walking the org chart, ask six questions around the analysis object:

1. Who Decides?

Who sets goals, investment, scope, and major principles? In the HR case: group leadership, HR VP, HR director.

2. Who Is Directly Affected?

Whose work changes after go-live? HR specialists, business heads, employees. They may lack decision authority but bear the most direct impact.

3. Who Runs the Business Operations?

Who owns recruitment, organization, personnel, compensation, performance, training? These roles hold the real business rules. Interviewing only management yields principles that cannot be executed.

4. Who Builds and Operates Long-Term?

IT, data, security, operations. They care about integration, data exchange, security, and sustainability.

5. Who Supervises, Constrains, or Sets Rules?

Finance, audit, legal, compliance, security, and external regulators. Often overlooked, they dictate what must and must not be done.

6. Who Collaborates from Outside the Enterprise?

Recruitment agencies, training providers, assessment firms. If business results depend on them or architecture changes alter the relationship, they are stakeholders.

Mapping Concerns to Architecture Requirements

Knowing who is only half the analysis. TOGAF introduces Concern – what each stakeholder cares about. The same system elicits different concerns:

Group Leadership: talent structure, organizational efficiency, labor cost.

HR Department: policy implementation, process unification, data accuracy.

Business Heads: recruitment efficiency, staffing, performance management.

Employees: usability, compensation accuracy, performance fairness, personal data security.

Finance: payroll calculation, budget, labor cost.

Audit/Compliance: policy enforcement, access control, audit trails.

IT: integration, performance, security, maintainability.

TOGAF links these concepts: Stakeholder → Concern → Viewpoint → View . Stakeholder decides "who looks", Concern decides "what they want to see", View expresses the answer. Architecture should not start with "What diagrams for business architecture?" but with "Who is this diagram for? What question does it answer?"

From Concerns to Architecture Requirements

A concern like "system should be easy to use" is not yet an architecture requirement. Decompose it: multiple logins? lengthy approval flows? repeated data entry? no mobile access? This yields concrete requirements:

Leadership's labor-cost concern → organizational headcount management, labor-cost analysis, compensation budgeting capabilities and data needs.

Business head's recruitment-cycle concern → demand management, approval workflow, candidate management, onboarding optimization.

Employee's compensation-accuracy concern → attendance, personnel, compensation rules, data quality, integration with finance.

Audit's traceability concern → approval logs, permission records, critical-data change logs, audit logs.

The full chain: Stakeholder → Concern → Architecture Requirement → Architecture Design . This distinguishes enterprise architecture from simple feature gathering. Instead of asking "What features do you want?", architecture asks "Why do you care? What is your goal? What responsibility or risk do you bear? What problem must the architecture solve?"

From Scattered Activities to Integrated Architecture Logic

Domestic HR projects already conduct leadership interviews, HR workshops, business interviews, employee surveys, finance confirmation, IT design, security reviews, audit/legal sign-offs. Viewed through TOGAF, these are handling different stakeholders' concerns. The problem: they happen in silos. Leadership has demands; HR has requirements; employees have usability wishes; IT produces technical designs; security and audit engage late. Concerns are not analyzed together – some duplicate, some conflict, some key roles are missed.

Stakeholder analysis reintegrates these scattered inputs into one architecture logic: Who is related? Why? What do they truly care about? Do concerns conflict? Which concerns become architecture requirements? Only then do stakeholders move from a personnel list into the architecture.

Conclusion

There is no fixed stakeholder list. The criterion remains: around the analysis object, who can influence it, who is affected, who bears responsibility or risk, who holds explicit rights, demands, or constraints. Architecture must further ask: What does each care about? What must the architecture satisfy when concerns conflict?

TOGAF's concepts chain together:

Stakeholder answers "Who".

Concern answers "What they care about".

Architecture Requirement answers "What the architecture must satisfy".

Viewpoint / View answers "How to express the architecture to relevant people".

Understanding this chain reveals that stakeholder analysis is not a project-initiation checklist; it determines where architecture starts and why it is designed the way it is. Every architectural choice – efficiency vs. control, unification vs. flexibility, sharing vs. isolation – ultimately traces back to differing stakeholder concerns. Before discussing business capabilities, processes, data, applications, and technology, architecture must clarify: who is involved, what they truly care about, and by what criteria we choose when concerns conflict.