Architecture Building Blocks
Architecture Building Blocks (ABBs) describe the capability/competencies our organisation requires and provide the basis for the specification of Solution Building Blocks (SBBs) that will implement that capability.

Building blocks represent (potentially re-usable) components  that we combine with other building blocks to deliver our architectures and solutions. Our building blocks can be defined at various levels of detail, depending on the stage of architecture development has been reached.

For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" (things that guide and shape what we have and do) or "solutions" (things we have to execute what we do).

Below is our current list of used/reusable architecture building blocks. Each link opens a catalogue. When you are looking for connections between entries in different catalogues first open the catalogues for each entry and if a link exists to entries in other catalogues it will be shown against that entry.

All new or changed solutions should normally use existing ABBs. If there is a need to use new or changed ABBs they should be reviewed as part of the solution conformance process and given either architecture approval or a dispensation in order to progress to the build phases of development.

Item ABB Type Name Details
01 Business Capabilities The potential/ ability that our organisation has that may or may not yet have been turned into competent delivery. We use capabilities to develop a high level model of what our organisation is able to do.
02 Business Competencies The distinctive abilities we have to deliver effective outcomes that our organisation possesses. We use competencies to develop a model of how well we perform against other organisations in those areas of competence.

Capabilities/competencies are delivered by executing business function and are typically expressed in general and high-level terms requiring a combination of people, organisation, processes, information and technology (POPIT) to achieve.
03 Business Organisation units A structure with our organisation used to group and manage  resources.

The grouping may be for various reasons (such geography, business function, market properties, operational effectives etc.). Organisation units are often termed "business functions".
04 Business Products (Logical) An offering generated by our organisation that we provide to our customers with associated commercial terms and conditions made from a set of ABBs.

A product may be physical thing or a service (i.e. we sell products and services).

Products are also visible in the solutions continuum where they represent the actual combination of SBBs that make up our offerings to our customers.
05 Business Business services The managed business activities/processes we carry out aligned to our contracts for the operation of these services. A service level agreement (SLA) is a contract about the nature of the specific outcomes to be delivered from a defined service. The contract identifies service qualities and the expected performance measures.

A service has an interface (how it can be requested), a contact (what should be assumed and what should happen if the assumptions hold) and an implementation (how it will be carried out).

Services can be data centric (they perform simple CRUD activities on specific data) or process centric (they carry out more complex business logic enabling capabilities through performing activities on data).

Business services are usually described using processes.
Application or information system services are usually described in terms of application component interactions that realise business processes.
Platform services provide the environments (devices and networks)on which application components executing application services can run.
Data services (as identified above) perform the basic CRUD operations on stored or provided data required by the application components.
06 Business Actors Our people and systems performing roles in support of our business processes.
07 Business Roles

The behaviour and performance we expect of our actors (people or systems in their day to day work running our business processes).
08 Business Business processes How we organise and manage resources to deliver business function in specific combinations and circumstances generating specific outcomes to our process customers (internal or external).

 A process represents a sequence of activities that together achieve a specified outcome.

They can be decomposed into sub-processes, and  may generate/respond to multiple events in order to satisfy one or more activities.

Each process may include controls - decision-making steps with accompanying decision logic used to determine execution approach for a process or to ensure that a process complies with governance criteria. For example, a sign-off control on the purchase request processing process that checks whether the total value of the request is within the sign-off limits of the requester, or whether it needs escalating to higher authority.

As we manage our business operations using the concept of services our processes implement the activities needed to deliver our services and the service contract represents the agreed outcome that the process (or set of processes) should create for its customers.
09 Business Business function The specific business capability/competency in a specific context that we deliver. Business function is usually coordinated and delivered through our business processes.

A business function is usually a concept agreed within an industry or business context rather than being specific to one organisation.

(Note the term "business functions" - with an (s) - is often used in business management. This use usually refers to an organisation unit that normally delivers this business capability rather than the business capability itself.
10 Business / Data Business terms / information The information needed by our business to operate effectively.

At the business level data it is represented by terms that would be used by our business experts and operatives representing the information they need to do their work.
11 Data Conceptual data entities The information structures that group multiple attributes together into information structures that reflect the business terms / information required by the business.
12 Data Logical data entities The information structures required to create the information systems/application components needed to support the design, build and execution of the application components that will manage and manipulate our business information. This will include specific attribute types and sizes but not the implementation technology concerns.
13 Data Logical data components The component types to be used for storing and managing data, information and knowledge.

These may need to support many types of data as required (e.g. operational data, analytical data, big data, large grained objects, dynamically changing objects)
14 Data Data and information patterns The way in which we organise and structure our approach to knowledge, information and data and the effective patterns and structures we have in place to control, manage and exploit our data.

Today this requires that we deal with many different structures and concepts such as operational data, analytical data, data warehouses, big data, data files, data pools, data flows and all of the associated management, controls and security.
15 Application User stories The approach we use to capture a high level understanding of our customers needs and wishes.

A user story is the result of a conversation with system users and captures 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.
16 Application Use cases The approach we use to capture a formal definition of specific tasks that our customers wish to be implemented in software systems.

A use case is a goal directed sequence of steps that delivers value to the user of the case. It supplements our user stories when more detail is needed.
17 Application Information system services The automated elements of our business services. Our information system services may deliver or support part or all of one or more business services.
18 Application Information system service patterns

Our set of useful reusable patterns of the structure and interactions between services that we use to develop our initial information systems service designs.
19 Application Logical application components Our set of structure and descriptions of the boundaries, integration and functionality of the application components that we wish to develop to implement our information system services.

The encapsulation of application functionality is independent of a particular implementation.
20 Application / Technology Software code patterns Our set of the standardised patterns for the structure and flow of useful software code modules / components / services and their interaction.
21 Technology Platform services Our set of structures and descriptions for the combination of technology products and components that we use to host and run our application components and manage our data.
22 Technology Platform service patterns Our set of the standardised patterns for the structure and flow of useful platform services and their interaction.
23 Technology Logical technology components Our set of structure and descriptions of the boundaries, interactions and functionality of the technology components that we wish to develop to implement our information system services.

The encapsulation of technology functionality is independent of a particular implementation.

  Created by M.J. Anniss Ltd.                                               -top                                            By using this website, you agree with this website disclaimer.