- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
17m ago - edited 17m ago
Enterprise Architecture Workspace already gives you a rich model of how your enterprise runs: business capabilities, value streams and stages, business processes and activities, business services, business units, and goals, all connected to the applications, technology products, and integrations that deliver them.
This release extends that model into the motivation and people layers. You can now capture what is driving change in your organization, who holds a stake in the outcome, and who performs the work, as first-class entities related to the business architecture you have already built.
It is a direct response to what this community has been asking for. Architecture teams standardizing on ArchiMate and TOGAF wanted these elements available natively, so that motivation and accountability live in the same model as capability and process.
Why this matters
Business architecture answers a specific set of questions, and this release puts each one in the model:
- “Who needs to approve this?” Attach stakeholders to the value streams, processes, and services they care about, with influence and interest levels captured on the record.
- “Why are we changing this?” Record a regulation, a market shift, or a cost pressure as a driver, and link it to the goals it motivates.
- “Who does this work?” Relate actors and roles to the process activities they perform.
- “How does this goal reach execution?” Trace a goal to the capabilities and processes that realize it, and on to the applications already mapped to them.
What’s new
Four new business architecture entities
Entity |
What it represents |
Notable attributes |
|
Business actor |
Who acts on a business process—a person, business unit, role, or department |
Department, Group, Location |
|
Business role |
An actor’s responsibility for specific behaviour, with its rights and duties |
Parent Role (for role hierarchies), Department, Group, Required Skills |
|
Stakeholder |
An individual or team with an interest in the outcome of an architecture |
Stakeholder Type, Influence Level, Interest Level, Department, Group |
|
Driver |
An internal or external condition motivating the organization to set goals and change |
Source (internal or external), Driver Type (dependent on Source), Urgency |
All four are first-class entities in the Business Architecture section of the Portfolios module—list views, forms, side-panel editing, and related lists.
New relationships
Connect the new entities into the model you already have:
- Business actor to business role (assigned to :: fulfilled by)
- Business actor to business process activity (performs :: performed by)
- Driver to stakeholder (influences :: influenced by)
- Driver to goal (influences :: influenced by)
- Stakeholder to goal (has goal :: goal of)
- Stakeholder to value stream, business process, and business service (interested in :: of interest to)
Business process activity is now a first-class list
Previously reachable by drilling into a business process, activities now have their own entry under Business Architecture—a list view with name, description, activity type, and ownership columns, create and edit in place, and a related list showing the actors who perform them.
Relationships carry meaning, with a suggested default
Relationships are not generic associations. Each one is typed from a catalogue of enterprise architecture relationship semantics—influences, assigned to, interested in, realizes, and others—with the inverse phrasing held alongside it. When you associate two entities, the modal preselects the preferred relationship type for that specific pair, with the full list available behind a separator if you need something else. You get consistency by default and flexibility when the situation calls for it.
How the entities fit together
The four new entities extend the existing business architecture model into the motivation and people layers.
Putting it to work
From a regulation to application impact, in one traversal. Record a new regulation as a driver, link it to the goal it motivates, and follow that goal to the business capabilities and processes that realize it. Those capabilities are already mapped to your business applications, so a compliance question becomes a portfolio query rather than a three-week discovery exercise.
Stakeholder maps that live in the model. Capture influence and interest levels on the stakeholder record and attach stakeholders to the value streams, processes, and services they care about. Architecture Review Board preparation stops being a memory exercise, and the map stays current because it is a record, not a slide.
Operating model clarity. Business unit to business capability and business unit to business process answer the question that decides who owns a rationalization decision: which part of the organization runs this?
Process accountability without a separate spreadsheet. Business actor to business role to business process activity gives you responsibility modelled where the process is modelled, so ownership survives the next reorganization.
Next step
Demo data ships with the release so you can see the relationships are working before you model your own.
Is this the model you’ve been waiting for, or is something still missing? Leave a comment—we read them.
