Indicates key events performed when executing a process.

The philosophy designed to deliver the user requirements in a way that allows for flexibility, through incremental iterations to enable more testing and feedback opportunities.

The Agile Manifesto, is in effect a contract between the delivery team and the Stakeholder. All work streams, facilitated by the Scrum Master, endeavour to deliver to ensure sprints are guided by the Agile Manifesto.

An interactive and incremented Agile software development framework for managing software projects and products or application development.

Represents the costs (and activities) involved to support an application post implementation, includes maintenance, training and support.

An architectural work product that describes an aspect of the architecture, generally classified as catalogues (lists), matrices (showing relationships between things) and diagrams (pictures of things)1.

List of requirements (i.e. User Stories, themes, epics), usually prioritised by business value. A Programme can have one or more backlogs. Business Architecture Programme, Work Stream, Spring, Test backlog with each subsequent backlog a subset of other Backlog i.e. Work stream backlog is a subset of the Programme backlog; Sprint backlog is a subset of the works tram backlog; Test Backlog is a subset of the Spring Backlog etc.

Intermediate: a benefit that occurs early, that contributes to an End Benefit; End: achievement of a final benefit, that is dependent on the achievement of one or more Immediate Benefits.

An outcome of an action or decision that contributes towards meeting one or more business (strategic) objectives. Benefits are the result of capabilities delivered and transitioned into and used by the Business Organisation, that produce positive outcomes for the business, that through their ongoing use, lead to the realization of benefits.

A network of benefits, usually linked to one or more primary investment objectives.

A person responsible for the realisation benefits. Can be an individual or group of stakeholders. According to the Managing Successful Programmes (MSP), this responsibility usually lies with the Senior Responsible Officer (SRO).

A comprehensive description of a single benefit, including all its attributes and dependencies.

The framework and process of Organisation and managing Benefits, so that planned benefits, arising from investment in change, are actually achieved.

The artefact which shows how and when all benefits, for a particular change initiatives, are expected to be realised.

A phase of a project where the solution is in use and in the process of being improved, through testing within the Programme or in the public domain. Also refers to the status of a Business Architecture Blueprint or artefact.

A Blueprint is a User Story level Business Architecture requirement and deliverable that describe a specific view or perspective of the Organisation. Blueprints make up HOBA® Business Architecture Building Blocks.

Building Blocks are Epic level Business Architecture Requirements and deliverables. They are made up of Blueprints, that collectively describe a specific view or perspective of the Organisation. Building Blocks make up HOBA® Business Architecture Reference Models.

In laments terms, How the Organisation is structured (architected) to execute its business strategy and achieve its Vision. In technical terms, a description of the structure and interactions between the Business Strategy, organisation, functions, business processes and information needs (source: TOGAF). Business Architecture makes up one half of an organisations Enterprise Architecture (the only half, and main domain is Technology Architecture. Also see Technology Architecture.

The high-level plan of the series of steps that are both required and followed in a specific and logical order to build up the Business Architecture.

see Benefits (Business)

In Business/Business Architecture context – a business capability is ‘what a business does’, made up of (essentially) people, process and technology. Each of these can be broken down further into people skills, culture, process steps, action, hardware, software, data etc.

Changes that are needed or made to the business environment (people, skills, processes), to support the realisation of benefits (but excludes technology).
Note – business change implicitly includes culture, strategies/policies, practices, procedures as they are necessary to deliver the above mentioned ‘people’ and ‘process’.

A concept or abstraction of a business system, where the actual ‘Business System’ is not known or known about the physical landscape. Also see Service.

Something that physically exists i.e. Application software or Technical System.

A regular rhythm of working.

In Benefits Realisation Management (BRM) context – a capability is ‘the set of outputs required to create an outcome’.
Note – ‘capability’ is often used interchangeability with the term ‘business capability’, which is not entirely true or correct. Business Capabilities consists of ‘people, process and technology’. Often ‘Technology’ stakeholders refer to the collective ‘technology’ they build, develop and/or maintain as ‘capabilities’. To be explicitly clear and to avoid confusion, and therefore the 70% failure rate in transformations, ‘a capability’ in that context strictly refers to or relates to ‘technology only’. Also see Business Capability.

Situation where quick and dirty design choice is made to meet a deadline or milestone, which end up costing unnecessary time and effort to undo or correct when time and/or money comes available.

In terms of enterprise architecture and design, a concern is a worry or area of worry a stakeholder has that results in a tension on the project, program or transformation. There is a cause-and-effect relationship before concern -> tension, which is addressed by (design) principles. Concerns are often related to scope (whats in, and whats out), which cause a tension, which is addressed by design principle(s).

A Customers needs (or requirement) expected from a given product or service that addresses their stated (or unstated) concern(s).

The quantitative measure of a Customer (internal or external) need. See Critical to Customer (CTC) above.

In terms of assumptions – an indicator of the level of how disruptive the change will be to the Programme.

Acronym for Create, Read, Update and Delete. Used to describe (shorthand) the basic function or User requirements.

Logical grouping and representation of a common data store.

A principle or set of principles that act as a guide to help contain scope and consistent design decisions and decision making. A well structured design principle is make up of three (3) parts – statement (what is the principle); rationale (why have it), and implications (now you have adopted it, how will that affect our decision making, or said another way ‘how does that affect our design decisions?’).

The 6-step process using HOBA® to develop the design of the Target Operating Model (TOM) and manage the alignment of the implementation of the physical TOM with the design.

An outcome perceived as negative by one or more stakeholders.

Phase of the project where the user needs are researched and identified.

Phases of software development (or phases of project management). Also, referred to as Discovery, Design, Build, Deliver.

An enterprise architectural domain, or architectural subsets of an overall enterprise architecture.

Total time to complete the activities based on resources available, and does not include holidays or non-working days, often referred to as work days or weeks.

The number of work units to complete the activity, often referred to as man hours, days or weeks.

The total calendar time needed to complete the activities, which can include weekends and public holidays.

Something that can be developed or purchased to enable the realisation of a/the benefit. Business Architecture capability classifications include – technology and information. Also see Business Changes.

An ultimate benefit of a Programme or project. Achievement of a final benefit is dependent on the achievement of one or more Immediate Benefits.

The description of how the Business Organisation is setup and structured in order to deliver on its Business Strategy. Consists of both Business Architecture, and Technology Architecture. Also see Business Architecture, and Technology Architecture.

A Product Backlog Item (PBI) which is not sufficiently defined. These are large story(s) that need to be broken down into User Stories.

High-level abstractions of User Stories and can include Non-Functional Requirements (NFRs) of discrete ‘business visible’ functionality that deliver Business Benefits.

An indicator of the cost to the Programme of a full-time worker (on an annual basis).

Final outcome the business or Organisation sets to achieve.

Agile business transformation framework. Consists of six (6) reference models -Business Motivation.. Each reference model covers a specific aspect of the Organisations business transformation, addresses each of the six (6) 5W1H strategic questions (Why, Who, What, Where, How and When). HOBA is implemented by the six (6) step Target State Architecture Design Process (‘Design Process’).

Benefits which occur between the implementation of early changes and the realisation of the End Benefits.

Technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s “just-in-time” (JIT) production system. The technique relies on work being ‘pulled’ through the system from the downstream process, when the upstream process has capacity to process it. The technique aims to reduce work-in-progress at each step of the process, prevent overproduction and remove bottlenecks.

A measure, usually tracked at a corporate level, to monitor overall performance.

An approach designed to increase efficiency, reduce waste and focus on what is important (i.e. maximising the value to the customer).

A phase of a project where the service is public and works well, and continually improved to meet user needs. Also refers to the status of the Business Architecture Blueprint, final and in-use yet subject to change based on review and feedback, usually formal change control.

Strategy and objective outcome indicators, used to measure success or progress towards a goal (or Vision).

The Quantifiable level of an indicator that the Organization uses to measure progress.

The purpose for which the Organisation exists.

Method of prioritising requirements – Must have (i.e. critical), Should have (i.e. important but not critical), Could have (i.e. desirable, but not necessary) and Wont have (i.e. least critical, lowest payback items or not appropriate at this time).

Customer (high level) requirements, See Critical to Customer (CTC)

An answer to the important ‘WHY?’ question which defined purpose, aim and direction. Also, referred to as ‘Strategic Objective’ – which are the drivers for investment.

A high level abstract and visual representation that explains how Business Operations are structured across the organisation’s constituent parts that allow it to execute its business strategy and achieve its Vision. Also see Target Operating Model (TOM)

The result of change, or the result of transition that embeds a capability in the business Organisation.

The deliverable created by a project (or Programme).

One of the subdivisions of the process (Project Management process, BRM process).

The office responsible for supporting the Portfolio Board in the managing of the whole change Portfolio.

An end objective for a change initiative which helps bound it scope.

Also referred to as ‘Backlog item’ or Product Backlog Item. An ‘item’ representing all the work a team needs to complete, includes requirements and tasks needed to complete to deliver requirement(s).

A mechanism for managing projects.

A group of senior stakeholders, responsible for providing leadership and direction for the Programme.

Describe a specific conceptual view or aspect of the Organisation and Business Architecture. A Reference Model is made up of Building Blocks and Blueprints, which provide increasingly focused detailed level view of that aspect.

High level business process(es).

Scrum is an iterative and incremental agile software development methodology for managing product development. Also see Agile.

Senior Executive or Sponsor for a project or Programme. Ultimately responsible for the realisation of benefits. In BRM, ultimately accountable for benefit realisation.

A logical representation of a repeatable business activity that has a specific outcome. A service is self-contained, maybe composed of other services, and is a “black box”

A sprint (or iteration) is the basic unit of development in Scrum. The sprint is a “time boxed” effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month.

A core team exercise to estimate the amount of development and testing effort required to deliver a completed a backlog item.

Core team members discuss the past Sprint to identify areas for possible process improvements.

The Sprint Team present work that was completed and not completed during the Sprint.

A daily 15 minute ‘standing up’ meeting by the core project members to present an update on progress and or impediments which require resolution.

A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. Typically, a sentence or two that describes who uses the story, the goal they are trying to accomplish, and any additional information that may be critical to understanding the scope of the story, including acceptance criteria. May also include NFRs.

A visual depiction of backlog cards organised by their current status, showing a left to right progression through the team’s process, that is either ‘not started’, ‘in progress’ and ‘done’. Also see Kanban.

The ‘HOW’ is the business going to achieve its Vision question. The plan of action or management mechanism needed to achieve an objective or vision.

A stage or status of a brainstormed draft outline or proposal intended to generate discussion and generation of new and better proposals. Later stage refined and improved proposals are subsequently named Wooden man, Tinman and Ironman. Originated from Ada Programming language.

A relatively quick Agile estimating technique (compared to ‘absolute’ estimation) to estimate the ‘relative’ size (Small, Medium, Large etc.) of a story or piece of work by comparing stories against each other.

Actions taken to support the Business Strategy

Target operating model is a description of the desired state of the operating model of an organisation. The target operating model is the "to be" (future) operating model. Usually done at the Enterprise level (i.e. across the Organisation), but also done for Business Units or Divisions within an Enterprise. Also refers to one of the six (6) reference models in HOBA. See Operating Model

See ‘Design Process’ above.

Tasks represent the next level of hierarchical decomposition after Activities

The description of how the Technology aspects of the Organisation is structured to support the Business Architecture in delivering on the Business Strategy, and consists of other architectures such as data, application etc. Technology Architecture makes up one half of an Organisations Enterprise Architecture (EA). The other half, and main domain is Business Architecture. Also see Business Architecture.

Strategic investment opportunities. Themes connect the Vision to the Business Strategy, and provide:

• the context for decision-making at the Portfolio/investment level, and
• the going-forward differentiators from the current state to the future state.

User Stories are usually written on index cards, usually referred to as ‘cards’ and form part of the backlog and are displayed on the Story/Kanban board.

The ‘WHY’ is the business doing this? Question. Also, a high-level statement that describes the future state from a business perspective.

A technique used to qualify and quantify a customer (internal or external to the Organisation) requirements from the customer. Often expressed in CTCs (Critical to Customer) and CTQs (Critical to Quality).

A technique used to define the scope of work and developing estimates of the work. WBS decomposes the project scope into smaller and smaller pieces, creating a hierarchy of work.