An Architecture Assumption is an un-validated assertion that something is true, but if later validated as false would introduce an impact on the architecture. Assumptions must be reasonable, in other words, they will normally have a high probability of being true. Assumptions must have general agreement with the relevant stakeholders Assumptions must have an owner who will be responsible for validating the assumption. Assumptions have a lifecycle which must be defined in terms of risk, resolution and timeframe. Assumptions are a means to allow activities to continue even though validated information is not available. The number of outstanding assumptions is a measure of the risk to the successful completion of an architecture.
Automation criteria
Define the parameters for particular object types that must be satisfied when converting a Business Information Service Interaction Model to an Information System Service Interaction Model, see Creating automation criteria for details of how to use.
BIS contract
The Business Information Services Collaboration Contract specifies the content and characteristics of the relationship between Business Information Services. The Contracts describes the rules that govern interaction behavior only with respect to information. These rules can be mandatory or optional, and can include precedence of behavior in other words, dependency on other interactions. All Business Information Collaboration contracts are essentially the same except that Component Collaboration Contracts are aggregations of the Business Information Service Collaboration Contracts that already exist between Business Information Services (see Collaboration Contract Artifacts)
This specification allows the development of service level objectives (irrespective of whether they are formalized into a service level agreement). A Business Information Collaboration Contract enables insight into the behavioral context of services, components and associated specifications.
Business Information Collaboration Contracts form an important insight to developing the critical operational path.
BS contract
The Business Services Collaboration Contract specifies the content and characteristics of the relationship between Business Services.
The Contracts describes the rules that govern interaction behavior. These rules can be mandatory or optional, and can include precedence of behavior in other words, dependency on other interactions.
Business activity
A business task or group of business tasks that are undertaken by the business to achieve a well defined goal.
•Business Activities support the realization of the Business Goals.
•Business Activities are a description of WHAT the business does in order to meet its goals.
•Business Activities are implementation independent, that is, independent of any organizational structure or process.
•Business activities have clearly defined objectives in transforming an initial state to another state.
•Business Activity provides one aspect of the element of business behavior characterized by a Business Service.
Business constraint
Describe the constraints, their nature, level of importance and so on, that impinge upon the business.
Business driver
[This placeholder topic will be updated in the next release.]
Business goal
Business Goals define what the business needs to achieve in order to fulfil its Business Objectives. Business Goals reflect the Business Objectives or describe what the business must achieve to fulfil the business mission. A Business Goal is an implementation independent, fundamental and unique contribution to the business mission. The Business Goal is the “WHY” objective for any Business Activity. They provide a reference baseline for comparing current state and future desired state. Support the definition of results related targets for the organization.
Business guideline
Implementation (including detailed Design) Guidelines set out the core structural architecture decisions that must be adhered to during the detailed design and implementation phases.
The guidelines provide the starting points and pre-conditions for implementation and describe the objectives, assumptions, constraints and design principles.
Business information service
A Business Information Service describes the communication behavior of a Business Service. As described elsewhere Business Services describe the elementary units of work a company does. The Business Information Service explicitly focuses on the use and communication aspects of information associated with the Business Services. The Business Information Service is a focus on information and its use by the business.
Business Information Services apply to any Business Service and therefore include governance, security or other supporting Business Services.
A Business Information Service makes no distinction between automated or non automated use and communication of information. It is the Business Information Service that is automated by Information System Services (you could automate a Business Service but that implies robotic automation as well, for example, automating “clean toilets” results in the automated super loos seen in France and the UK for example).
Business Information Services collaborate through the communication of Information Objects.
Business mission
The business mission describes the rationale for existence of a business.
•The business mission is usually set as a challenge for a business, which provides a goal and is meant to generate inspiration and aspiration within the organization.
•A mission statement is usually short and pithy, and is primarily a statement of direction and goal for the overall business, although they often exist as motivational statements within individual business domains.
•The mission is designed to set a strategic goal and communicate the ethos of the business to both internal staff and external partners. Mission statements tend to be static, often being re-issued to support programmes of major change. For the architecture they provide a strategic goal and a means to validate many of the architecture objectives.
Business object
A Business Object is a non-human resource used by the business that is significant to the architecture in the following ways:
•Businesses use and consume things from pencils to transport, raw materials for manufacture, and so on.
•Sometimes it is significant to the architecture (structure) to identify what these Business Objects are.
•Business Objects are used and consumed (in IAF) by Business Service which is described in an Object Contract.
•Different Business Services will use and consume Business Objects in different ways. It might be architecturally significant to understand these differences when structuring the architecture components.
•Business Objects can be or infer Information Objects.
Business objective
Describes the architecture outcomes based on the business issue(s) the architecture needs to address. Different types of business issues require different types of architecture and architecture engagements. Architecture can be used to support major strategic change and planning, or as a validation and specification exercise as a precursor to a “build” programme. The former are generally categorized as “Enterprise” while the latter is categorized as “Project”. The primary difference between the two is in the level of detail and aspect area focus. “Enterprise” architectures tend to focus on the Business and Information aspects with a top slice across the other aspect areas whereas “Project” architectures focus on the IS and TI aspect areas (with an implicit assumption that the Business and Information aspects are defined). Similarly an enterprise architecture that is created as part of a business case for major change provides just enough detail and structure to estimate costs. One that is created to define which systems will be used after a merger focuses on the current and desired structure together with life cycle management aspects of those systems and will require more detail and analysis.
The Architecture Objectives set out the outcomes of the architecture in relation to the business objectives. The Architecture Objectives communicate the issues that the architecture will address and the way that the architecture will address them. The Architecture Objectives shape the road map for the architecture engagement. The Architecture Objectives allow the appropriate deliverables for an individual architecture engagement to be determined, and the level of analysis required to achieve a satisfactory level of confidence in the outcomes.
Business service
A Business Service characterizes a unique “element of business behavior” in terms of a Business Activity, undertaken by a specific Role that together support a specific Business Goal. A business service is also defined by these things:
•Business Services are basic building blocks of the things an organization does.
•A Business Service can be understood as the elementary unit of work serving a single purpose.
•A Business Service can be internal to the business, exposed externally to a customer, partner, supplier and so on, or can be something that the business consumes from an external party.
•Business Services are independent of process, organization, and implementation A Business Service collaborates with other Business Services through a Business Service Contract
•All or part of the business can be described by Business Services and their Business Service Contracts. This includes the governance, security or other supporting Business Services.
•Business Services describe the activities undertaken by a business. They might or might not be subject to automation.
•Business Services define the fundamental behavior of the business in terms of discreet activities that can be used to describe and represent a Service Orientated Enterprise or a more Traditional Process Orientated approach (or more usually a combination of both).
•A Business Service is derived from a unique combination of a Business Goal, and the Business Activity and Role supporting that specific Business Goal.
Business specification
What the design and implementation of the architecture will be realized with:
•Organization models (re-structured, new, and so on)
•Governance models
•Process components
•SERVICE descriptions (SOA- type services)
•Job Specifications (from roles - actor)
•Interaction models
•Migration (phasing) and other Views
Business standard
What must the design and implementation of the business architecture aspects conform/comply with, for example:
•policies for governance and security
•codes of conduct
•legislation
•standards
Communication guideline
Implementation (including detailed Design) Guidelines set out the core structural architecture decisions that must be adhered to during the detailed design and implementation phases.
The guidelines provide the starting points and pre-conditions for implementation and describe the objectives, assumptions, constraints and design principles.
Communication specification
What the design and implementation of the communication architecture aspect will be realized with, typically:
•automated and non automated communications
•allocation and mapping with current state elements of the business (where automation will be applied, changed and so on)
•what form manual communication will take (phone, forms, email, and so on).
Communication standard
What must the design and implementation of the information architecture aspects conform/comply with, for example:
•policies: could include policies for email, communication with external organizations, and so on
•legislation: must use PAYE forms
•standards: examples might be EDI, BACS, possibly XML.
Constraint
An Architecture Constraint is an assertion of a fact which applies to the architecture and is recognized as having a fundamental impact on the architecture.
Constraints are inevitable when dealing with complex issues and the impact they have can have serious consequences when developing architecture.
Constraints can arise from internal or external sources and can be related to business, existing suppliers, technology or even finance. Technology selection is a common constraint for example, a stipulation that deployment must use a particular manufacturer's technology.
It is unusual to uncover additional constraints (as opposed to risks and assumptions for example) during an architecture engagement so constraints are usually identified at the outset.
Constraints usually have a lifespan which can be greater or lesser than the architecture lifespan. This is important information as it potentially affects the options available to the architect.
The purpose of identifying constraints is to be aware of potential issues in the development (and realization) of an architecture. Constraints will have impact on the way the architecture is organized and validated. Constraints can limit architectural options, make an ideal logical architecture unrealizable or simply introduce challenges which cannot be overcome.
Information guideline
Implementation (including detailed Design) Guidelines set out the core structural architecture decisions that must be adhered to during the detailed design and implementation phases. The guidelines provide the starting points and pre-conditions for implementation and describe the objectives, assumptions, constraints and design principles.
Information interaction
Describes how a Business Information Service uses an Information Object. An interaction can have a basic type of:
•Get
•Write
•Transform
An interaction can be extended with sub types to describe other modes such as Execute, Erase, Retire, and so on.
Information object
An Information Object is the subject of communication for Business Services. The Information Object describes the information that is used or communicated by Business Information Services. An Information Object is a source of information. An Information Object is not a description of data but rather indicates where data is used. An Information Object is independent of the media it is presented on. An Information Objects are characterized by STATEMENTS that have the general form of: “Blah” is a “blur” that “bleeps”.
For example: STATEMENT An (ORDER) “blah” is the (request of a CUSTOMER) “blur” that (supplies an ARTICLE) “bleeps”. An Information Object can be described by a collection of “STATEMENTS”. Automated Business Information Services will identify automated Information Objects for use by Information System Services.
Information relationship
This contains information about the relationship between a pair of Information Objects.
Information specification
What the design and implementation of the information architecture aspect will be realized with typically:
•information archive and availability specification
•audit
•interaction model (Information Store Structure)
•migration (phasing) and other views.
Information standard
What must the design and implementation of the information architecture aspects conform/comply with, for example:
•policies for back up, integrity, availability, security
•legislation for archive, access, audit
•standards: corporate canonical forms.
IS guideline
Implementation (including detailed Design) Guidelines set out the core structural architecture decisions that must be adhered to during the detailed design and implementation phases. The guidelines provide the starting points and pre‑conditions for implementation and describe the objectives, assumptions, constraints and design principles.
IS service
An Information System Service describes an element of behavior of information automation required to support automated Business Information Services.
An Information System Service supports one or more automated Business Information Services.
Information System Services describe the Information System capabilities of the architecture.
An Information System Service collaborates with other Information System Services. The interaction of an Information System Service with other Information System Services is described in an Information System Service Collaboration Contract.
IS specification
What the design and implementation of the information systems architecture aspect will be realized with, typically:
•package components
•bespoke components
•interface requirements
•quality and security specification
IS standard
What must the design and implementation of the information architecture aspects conform/comply with.
ISS contract
The Information System Service Collaboration Contract specifies the content and characteristics of the relationship between Information System Services.
The Contracts describes the rules that govern interaction behavior only with respect to information. These rules can be mandatory or optional, and can include precedence of behavior in other words, dependency on other interactions.
This specification allows the development of service level objectives (irrespective of whether they are formalized into a service level agreement). An Information System Collaboration Contract enables insight into the behavioral context of services, components and associated specifications.
Information System Collaboration Contracts form an important insight to developing the critical operational path.
ISS to TIS contract
[This placeholder topic will be updated in the next release.]
LBC contract
The Logical Business Component Collaboration Contract specifies the content and characteristics of the relationship between Logical Business Components.
LBIC contract
The Logical Business Information Component Collaboration Contract specifies the content and characteristics of the relationship between Logical Business Information Components.
LISC contract
The Logical Information System Component Collaboration Contract specifies the content and characteristics of the relationship between Logical Information System Components.
Logical BI component
A Logical Business Information Component is a grouping of Business Information Services that represent the structure of the communication aspects of a business. In the same way the Logical Business Component describe the fundamental structure of the business with respect to Role, Goal, Activity and resources (Business Objects) Logical Business Information Components describe the structure of the business with respect to the use and communication of information.
Logical business component
A Logical Business Component is the basic element of an “ideal” or “To Be” business structure created by the grouping of one or more Business Services. A Logical Business Component describes the basic elements of an “ideal” business structure in terms of groups of Business Services. The Logical Business Components describe how business objectives will be achieved. Logical Business Components maintain the interactions defined by the Business Service interactions and associated Business Service Contracts. As Business Services reflect several different aspects of Business (role, activity, goal, resources) the Business Services can be grouped into Logical Business Components from one or more of these aspects. For example grouping around common goals will result in one set of Logical Business Components that might reflect the governance model for the business, grouping around organization criteria (roles and activities for example) will create an alternative set of Logical Business Components that describe the organization, whilst grouping criteria based on activities in a common process will generate another set of Logical Business Components that describe the process components. Doing this allows the impact of the different criteria on the different business aspects to be analyzed. Note that the final Logical Business Component architecture will almost certainly be the best fit across all these alternatives. The grouping criteria of Business Services into Logical Business Components is typically justified by a combination of the Architecture Principles, Business Case and other previously identified Business Objective.
Logical information component
A Logical Information Component describes the structure of Information Objects that supports the architecture solution. The Logical Information Component describes Information Objects that have been grouped according to some grouping criteria. One usual criterion is around commonality of use by Business Information Services (or Business Services by inference). Grouping of Information Objects in this way will indicate the most efficient structure for information. Where Business Information Services are to become automated then an automation criteria can be used to create the associated Logical Information Components. In this case the Logical Information Components will indicate potential data stores Note that the grouping of Information Objects can also have an influence on the way that Business Services are grouped into Logical Business Components.
Logical IS component
A Logical Business Component is the basic element of an ideal or To Be Information system structure created by the grouping of one or more Information System Services. The Logical Information System Components represent the application components for a given solution alternative. Logical Information System Components describe the implementation independent solution for Information Systems in terms of the desired to-be state. There can be more than one alternative to-be state, each alternative using different clustering criteria and priorities. These alternatives are used to assess the merits or otherwise, for example balancing performance with cost, reliability with complexity.
The Logical Information System Components are used to build the Logical Information System Interaction Model which will depict and describe the major interfaces, and provide input to the Technology Infrastructure Aspect Area to support the derivation of Technology Infrastructure Services.
Logical TI component
Logical Technology Infrastructure Components represent logical realizable infrastructure elements, for example servers, storage array, network, firewall and so on.
Logical Technology Infrastructure Components are grouping of Technology Infrastructure Services.
Logical Technology Infrastructure Components support Information System Services (and Information System Components implicitly) and sometimes Business Information Services directly.
Logical Technology Infrastructure Components are implementation independent.
Solution Alternatives are based on grouping criteria derived from the Architecture Principles, for example centralization, consolidation, scalability and so on.
Logical technology infrastructure component
Logical technology infrastructure components:
•are an implementation independent realizable element of the to-be technology infrastructure aspects of the architecture.
•represent logical realisable infrastructure elements, for example servers, storage array, network, firewall, and so on.
•group Technology Infrastructure Services.
•support Information System Services (and Information System Components implicitly) and sometimes Business Information Services directly are implementation independent.
LTIC contract
The Logical Technology Infrastructure Component Collaboration Contract specifies the content and characteristics of the relationship between Logical Technology Infrastructure Components.
Object contract
The Object Contract describes how a Business Service uses a Business Object.
PBC contract
The Physical Business Component Collaboration Contract specifies the content and characteristics of the relationship between Physical Business Components.
PBIC contract
The Physical Business Information Component Collaboration Contract specifies the content and characteristics of the relationship between Physical Business Information Components.
Physical BI component
The implementation dependent description of a structured physical component that comprises one or more Logical Business Information Components.
A Physical Business Information Component is one or more Logical Business Information Components that defines what the logical architecture will be implemented with. Physical Business Information Components are the realization of part of the overall business structure. They are therefore the information focus of the Physical Business Components. Note that they represent how the business will communicate and use information. They are not implemented independently of the Physical Business Components. Physical Business Information Components will be aligned with the Physical Business Components when being allocated to current state components or designed and built as new components.
Physical business component
The implementation dependent description of a structured physical component that comprises one or more Logical Business Components. A Physical Business Component is one or more Logical Business Components that defines what the logical architecture will be implemented with. Physical Business Components are defined by the standards and products that implement them. In some cases the Physical Business Components can be allocated to current state components or they might need to be designed and built as new components. The grouping/allocation criteria will be driven by the Architecture Objectives and Constraints.
Physical information component
The implementation dependent description of a structured physical component that comprises one or more Logical Information Components. A Physical Information Component is one or more Logical Information Components that defines what the logical architecture will be implemented with. Physical Information Components are defined by the standards and products that implement them. In some cases the Physical Information Components can be allocated to current state components (existing data stores for example) or they might need to be designed and built as new components. The grouping/allocation criteria will be driven by the Architecture Objectives and Constraints.
Physical IS component
The Physical Information System Component Collaboration Contract specifies the content and characteristics of the relationship between Physical Information System Components. It is the implementation dependent description of a structured physical component (for example, software component) that comprises one or more Logical Information System Components. Physical Information System Components are implementation dependent groups of one or more Logical Information System Components. Grouping criteria are derived from the Architecture Principles and more importantly from the Architecture Constraints. A common principle is one that describes the preference for package solutions over custom, in this instance the logical components being grouped to package functionalities. In addition some components will be designated for custom developments.
Physical TI component
Physical Technical Infrastructure Components are implementation dependent groups of Logical Technical Infrastructure Components. The grouping criteria are derived from the Architecture Principles and Architecture Constraints Physical Technical Infrastructure Components describe real components and also define the key connectivity points for the solution and provide a view of the real information flows across the architecture thereby allowing more precise and complete view of capacity requirements.
PISC contract
The Physical Information System Component Collaboration Contract specifies the content and characteristics of the relationship between Physical Information System Components.
Principle
A statement that defines an objective (or constraint) that is used to determine the organization and structure of an architecture.
•It is a statement of belief, approach or intent which directs the formulation of the architecture. It does not have to explicitly reference architecture artefacts or structure. In this way many “Business Principles” will often be expressed within the architecture.
•It might refer to the current state or to a desired future state.
•It usually addresses more than one IAF aspect areas.
•It has an implicit hierarchical structure where an Architecture Principle can generate a number of consequential Architecture Principles, some of which might be within other aspect areas.
•It is owned and validated by the architecture owner or owners.
•It is the starting point for any architecture development. Without Architecture Principles it will be difficult to organise and structure the architecture and manage the inevitable conflicting requirements.
•It is a guidelines for the development of the architecture, as they underpin analysis and investigation of architecture options, and provide a structured set of justifications for the decisions that were made about the components in the architecture.
•It ensures that the architecture is defined consistently and in line with the business objectives.
•It is typically derived from Business mission/Strategy/objectives and any corresponding architecture assumptions, scope, constraints and objectives. Additional inputs can be found in current state, business programme information, business and technical strategies, and business consulting studies, interviews, workshops, discussions, and so on.
PTIC contract
The Physical Technology Infrastructure Component Collaboration Contract specifies the content and characteristics of the relationship between Physical Technology Infrastructure Components.
Requirement
The IAF metamodel does not yet formally support the requirement object. In System Architect all object types can be linked to requirements stored in the IBM Rational DOORS product through DOORS links.
Risk
The IAF metamodel does not formally support Risk definitions. These objects can be used within the Context Scratchpad diagram to illustrate the impact of Risk on Contextual objects.
Role
A Business Role performs a Business Activity. A Role is defined further by the following items:
•Roles are responsible for the execution of activities.
•Roles can also have accountabilities for Goals (although there will be corresponding governance activities for those goals).
•Roles should not be associated with people or systems as people have multiple roles. Roles are independent of implementation but are still needed to support the activities.
•Roles relate to specific activities and support the same Business Goal as the activity.
•Actors are classified in terms of their value and contributions, accountability and responsibility (copare with RACI-model) of an activity or service.
Service characteristic
The provision of a business service is typically governed by a range of measures and controls which determine the quality of service delivered. In the development of an enterprise services architecture it is important to consider these service characteristics and their relative values for each business operation. Across the business there will be a wide range of different quality of service requirements. Awareness and understanding of the business service characteristics of each business operation will directly support the definition of systems and technology services that will enable quality of service requirements to be met.
The IT service characteristics are the result of a process of analysis, derivation and consolidation from the Business Service Characteristics. IT service provision is less granular due to the influence of shared and common IS/IT services that support the different business services.
Service profile
Service characteristics can be grouped together to for a Service Profile.
Solution alternative
Solution Alternatives are based on grouping criteria derived from the Architecture Principles, for example centralisation, consolidation, scalability and so on, and provide a way to test and analyze the architecture against the often contradictory and conflicting Architecture Principles and other criteria that will exist. The Solution Alternatives structure the services (needs/requirements) against the same criteria but with different priorities, for example whether services should in-sourced or outsourced the balance between cost and performance. Each of these alternatives will (usually) result in different groupings of components. These groupings can have different impacts across one or more of the Architecture Aspect Areas. This process is the key to developing the optimal logical architecture. Note that since the grouping of services to produce different solution alternatives is based on different criteria and priorities the same criteria and priorities need to be applied across all Aspect Areas where applicable and the results and impacts analyzed across all Aspect Areas otherwise the architecture will not align. This is extremely important where the different architecture aspects are being developed in parallel.
TI guideline
Implementation (including detailed Design) Guidelines set out the core structural architecture decisions that must be adhered to during the detailed design and implementation phases. The guidelines provide the starting points and pre-conditions for implementation and describe the objectives, assumptions, constraints and design principles.
Technology infrastructure service
Technology Infrastructure Services describe the behavior of services that primarily support the Information System Services and can also directly support generic business objectives (for example Office Automation type services).
Technology Infrastructure Services
•are typically common or shared services that support more than one Information System Service. Primarily interact with each other to create a common or shared environment. The interaction between Technology Infrastructure Services is described through the Technology Infrastructure Service Contracts.
•are typically consumed by an Information System Service, or another Technology Infrastructure Service. In some cases a Role can consume an Infrastructure Service directly.
•can be described at different levels of granularity like other services for example, very granularly or atomic such as processing, communication, storage and so on, or less granular, more molecular such as printing, collaboration, email, web access, call center and so on.
TI specification
What the design and implementation of the technology infrastructure architecture aspect will be realized.
TI standard
What must the design and implementation of the information architecture aspects conform/comply with.
TIS contract
The Technical Infrastructure Service Collaboration Contract specifies the content and characteristics of the relationship between technical Infrastructure Services.