2. Definitions

For the purposes of this document, the following terms and definitions apply. Merriam-Webster’s Collegiate Dictionary should be referenced for terms not defined in this section.

2.1. Accountability

The obligation to demonstrate task achievement and take responsibility for performance in accordance with agreed expectations; the obligation to answer for an action. (Source: Vanderhaegen 2019)

2.2. Alignment Diagram

Any map, diagram, or visualization that reveals both sides of value creation in a single overview. It is a category of diagram that illustrates the interaction between people and organizations. (Source: Kalbach 2016)

2.3. Allowable Lead Time

The time available between starting a product development initiative or process and finishing it in order to satisfy customers.

2.4. Architectural Runway

Consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay. (Source: Scaled Agile, Inc.)

2.5. Architecture

  1. The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (Source: ISO/IEC/IEEE 42010:2011)

  2. (System Engineering Context) The embodiment of concept, and the allocation of physical/informational function (process) to elements of form (objects) and definition of structural interfaces among the objects. (Source: Crawley 2016)

2.6. Architecture Principle

A qualitative statement of intent that should be met by the architecture. (Source: The TOGAF® Standard 2018)

2.7. Architecture Style

A coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style. (Source: Fielding 2000)

2.8. Capability

  1. An ability that an organization, person, or system possesses. (Source:TOGAF Standard 2018)

  2. The ability to achieve a desired outcome. (Source: CJCSM 2005)

2.9. Catchball

A dialog between senior managers and project teams about the resources and time both available and needed to achieve the targets.

Note

Once the major goals are set, planning should become a top-down and bottom-up process involving a dialog. This dialog is often called catchball (or nemawashi) as ideas are tossed back and forth like a ball.

(Source: LEI)

2.10. Continuous Architecture

An architecture with no end-state that is designed to evolve to support the changing needs of the digital enterprise.

2.11. Customer Experience

The sum-totality of how customers engage with your company and brand, not just in a snapshot in time, but throughout the entire arc of being a customer. (Source: Richardson 2010)

2.12. Customer Journey

The series of interactions between a customer and a company that occur as the customer pursues a specific goal. (Source: Forrester®)

2.13. Design Thinking

A methodology for creative problem solving that begins with understanding unmet customer needs. (Sources: Stanford 2010 and MIT)

2.14. Digital Platform

A software system composed of application and infrastructure components that can be rapidly reconfigured using DevOps and cloud-native computing.

2.15. Digital Practices

A synthesis of methods and guidance from a wide variety of practitioners and professional communities active in digital technology (Lean, Agile, DevOps, etc.) designed to create and manage products with an increasing digital component, or lead their organization through Digital Transformation.

2.16. Digital Technology

A powerful, accessible, and potentially game-changing technology (social, mobile, cloud, analytics, Internet of Things (IoT), cognitive computing, and biometrics) often used in combination and usually characterized by its ability to positively impact an enterprise’s business model, customer experience, product, or operating system to enable innovation and growth.

2.17. Digital Transformation

The use of digital practices supported by digital technologies to achieve a shift in the business model, value proposition, operating system, or distribution system to radically improve customer relationships, profitability, internal processes, performance, accessibility, and market reach of an enterprise.

2.18. Domain Model: Domain-Driven Design

The representation of a selected abstraction of domain knowledge that is rigorously organized.

Note

It is not necessarily a particular diagram; it can also be captured in carefully written code or in a well-written text.

(Source: Evans 2003)

2.19. Ecosystem

The complex community of organisms and their environment, functioning as an ecological unit.

Note

In the mathematics of dynamic ecosystems, a common result is that the more aligned the objectives of the various components of the system, the healthier the system.

(Source: Wind 2015)

2.20. Epic

  1. (Classical Agile) A large user story that cannot be delivered as defined within a single iteration, or is large enough that it can be split into smaller user stories.

Note

There is no standard form to represent epics. Some teams use the familiar user story formats (as a, I want, so that or in order to, as a, I want), while other teams represent them with a short phrase.

(Source: Agile Alliance®)

  1. (Scaled Agile) The highest-level expression of a customer need. Development initiatives that are intended to deliver the value of an investment theme and are identified, prioritized, estimated, and maintained in the portfolio backlog. (Source: Leffingwell 2011)

2.21. Event Storming

The identification of domain events, commands, persona, or entities to facilitate a structured conversation about the domain.

2.22. Evolutionary Architecture

An architecture that supports guided, incremental change across multiple dimensions. (Source: Ford™ 2017)

2.23. Evolvability

A meta-non-functional requirement that aims to prevent other architecture requirements, in particular the non-functional ones, from degrading over time.

2.24. Feature

The functional characteristic of a product (goods or services).

Note

It provides a factual description of how a product delivers its outcomes.

2.25. Hardware

Tools, machines, wiring, and other physical components of a system.

2.26. Information Security

The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide integrity, confidentiality, and availability.

Note
  • Integrity, which means guarding against improper information modification or destruction, and includes ensuring information authenticity and non-repudiation

  • Confidentiality, which means preserving authorized restrictions on access and disclosure, including the means for protecting personal privacy and proprietary information

  • Availability, which means ensuring timely and reliable access to, and use of information

2.27. Integrality

The system’s property of being made up of elements that behave consistently as a whole.

(Source: Miraglia 2014)

2.28. Intentional Architecture

A purposeful set of statements, models, and decisions that represent some future architectural state.

2.29. Job-To-Be-Done

What the customer hopes to accomplish.

Note

“Job” is shorthand for what an individual really seeks to accomplish in a given circumstance.

(Source: Christensen 2016)

2.30. Journey Mapping

Laying out the entire end-to-end customer experience.

2.31. Lead Time

The time between the initiation and completion of a process.

2.32. Lean Value Stream

All of the actions, both value-creating and non-value-creating, required to bring a product from concept to launch (also known as the development value stream) and from order to delivery (also known as the operational value stream).

Note

These include actions to process information from the customer and actions to transform the product on its way to the customer.

(Source: LEI)

2.33. Modularity

The system’s property of being made up of elements that present a high independence of other elements.

(Source: Miraglia 2014)

2.34. Modularization

Design decisions which must be made before the work on independent modules can begin.

Note

Every module is characterized by its knowledge of a design decision, which it hides from all others. Its interface or definition is chosen to reveal as little as possible about its inner workings.

(Source: Parnas 1972)

2.35. Operating System

The combination of assets and processes required to deliver a product or a service.

Note
  • Assets: main processing resources utilized by the firm, including human resources and capital resources that either add value or are necessary for the processing and delivery of the product

  • Processes: flows through a network of activities that transform the product or service from input to output

(Source: Van Mieghem 2015)

2.36. Outcome

The result of an activity conducted by a provider and experienced by a consumer.

2.37. Persona

A fictional character which is created based upon research in order to represent the different user types that might use a service, product, site, or brand in a similar way. (Source: Friis Dam 2020)

2.38. Platform Business Model

Business model that is based on the two-sided market theory.

2.39. Process

Any activity or group of activities that takes an input, adds value to it, and provides an output to an internal or external customer.

Note

There is no product and/or service without a process. Likewise, there is no process without a product or a service.

(Source: Harrington 1991)

2.40. Product

A bundle of services and/or goods offered to customers.

Note

Products have features, which are the functional attributes that define how the products work and deliver benefits to customers. Agile product architecting focuses on segmenting products, so they:

  • Meet the needs of customers (product/market fit)

  • Offer differentiated features to customer segments

  • Can be delivered incrementally by an Agile team or team of teams

2.41. Product Backlog

A list of the new features, changes to existing features, bug fixes, infrastructure changes, or other activities that a team may deliver in order to achieve a specific outcome. (Source: Agile Alliance)

2.42. Product-Centric Organization

An organization structured around permanent teams by opposition to temporary teams or projects.

2.43. Refactoring

The process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure.

Note

It is a disciplined way to clean up code that minimizes the chances of introducing bugs.

(Source: Fowler 2019)

2.44. Responsibility

The obligation to carry forward a task to its successful conclusion.

Note

With responsibility goes the authority to direct and take the necessary action to ensure success.

(Source: Vanderhaegen 2019)

2.45. Service

  1. (Business context) An act performed for the benefit of another.

Note

Services involve at least two parties. One applies competence (a provider) and another experiences an outcome (a consumer). For example, a taxi ride is a service used by a person for travelling (outcome) and is delivered by a taxi driver (provider). Audio typing is a service used by a person to produce a written document based on their speech (outcome). It is delivered by an audio-typer (provider).

  1. (Software context) An encapsulated component that delivers its outcomes through well-defined interfaces.

Note

Well-designed services are self-contained and provide Application Program Interfaces (APIs) that shield their consumers from their implementation details. Web services are a popular kind of software service, in which interface calls occur over the Internet using standard Internet protocols.

2.46. Social System

People, their behavior, cultural beliefs, skills, and expertise, and how work teams are forming and interacting, as well as organizational leadership, strategy, structure, policy, and procedures.

2.47. System

A set of entities and their relationships, whose functionality is greater than the sum of the individual entities. (Source: Crawley 2016)

2.48. User Story

A brief statement of intent that describes something the system needs to do for the user.

Note

A simple story template is as follows:

  • As a [type of user]

  • I want to [do something]

  • So that I can [get some benefit]

(Source: Patton 2014)

2.49. Value Stream

End-to-end collection of value-added and non-value-added activities that create an overall result for a customer, stakeholder, or end user.

2.50. Work System

Human participants and/or machines perform processes and activities using software, hardware, and other resources to deliver products or experiences.