This blog describes where the availability and use of BIAN deliverables influences the way in which the TOGAF ADM phases are performed.

 

1. RELATING BIAN TO THE PHASES OF THE ADM

For each TOGAF ADM phase, only those BIAN deliverables are included that are a direct input for that ADM phase. Since the impact of those BIAN deliverables is fully integrated in the output of that ADM phase, the influence on later ADM phases is fully covered, see figure 75.

Applying the TOGAF ADM produces and enriches the BIAN Service Landscape and BIAN Business Scenarios specific to the organization. Furthermore, the results can be fed back to the BIAN community to extend and enrich the BIAN deliverables.

Figure 75: Relating BIAN to the phases of the ADM

 

1.1 Preliminary phase

The Preliminary phase is about de defining “where, what, why, who and how we do architecture” in the organization we are looking at. This phase considers:

• • That the existence of the BIAN network contributes to the awareness and acceptance of an architectural approach and, in that sense, can be used to create sponsorship and general commitment for the approach.
• • That the use of the BIAN SOA Design Framework and related deliverables may be prescribed by the architecture.
• • Whether or not to use BIAN input and principles during the architecture work.

1.2 Architecture vision

Phase A is about validating the starting points, defining the scope and approach of the architecture development cycle, and recognizing key success factors:

• • Relate the architecture development cycle to the use of BIAN deliverables. In the first instance, a decision must be made regarding the relevance and tress-for-purpose of the BIAN deliverables for this architecture engagement.
• • The parts of the BIAN Service Landscape and BIAN Business Scenarios that are relevant for the project can be used to identify possible stakeholders.
• • The BIAN Service Landscape can also be used to identify other architecture developments in related areas of the organization.
• • When using BIAN, certain re-use requirements may be applicable.

1.3 Business architecture

The main objectives of Phase B are to describe the Baseline Business Architecture, to develop a Target Business Architecture, and to identify any gaps.

• • The BIAN Business Scenarios can be used as a starting point, as an example, in describing the Baseline Business Architecture and de ning the Target Business Architecture. e scope of a BIAN Business Scenario can be compared to that of a conventional high-level business process. The BIAN Business Scenarios are an example of how some BIAN Service Domains might collaborate in response to a business event. BIAN Business Scenarios can be matched to the internal (baseline and target) processes at a bank, whilst the BIAN Service Domains and their associated Service Operation boundaries can be used as an assessment framework. As noted previously, the BIAN Business Scenarios are indicative and, in matching them to a specific location, their sequencing and content may need to be changed to reject the prevailing business rules and practices.
• • The BIAN Service Landscape is structured according to a common reference hierarchy: a business breakdown in Business Areas and Business Domains. Although not a Target Business Architecture in itself, the BIAN Service Landscape can be used as a starting point (or at least be used as a source of inspiration) next to the BIAN Business Scenarios for the set-up of the Target Business Architecture.
• • As the BIAN Service Landscape is directly derived from the business breakdown, and validated via the BIAN Business Scenarios, it should be clear if and where the set-up of the Target Business Architecture deviates from this breakdown. This insight is needed to apply the BIAN Service Landscape in Phase C.

1.4 Information systems architecture

The objective of Phase C is to develop Target Architectures for the data and/or the application systems domains and identify the gaps between the Baseline and the Target Architecture. Information Systems Architecture focuses on identifying and defining the applications and data considerations that support an enterprise’s Business Architecture. It does so by de ning views that relate to information, knowledge, application services, etc.

• • BIAN provides the BIAN Service Landscape speci c to the nancial services industry, constructed of re-usable building blocks related to application components and data entities. As such, the BIAN Service Landscape can be used as a reference point for de ning or assessing the Target Application Architecture of the organization. Its breakdown into Business Areas, Business Domains, and BIAN Service Domains can be applied in order to structure the application landscape. The principles applied in constructing the BIAN Service Landscape can be translated into application and data principles for the organization.
• • A core activity is to relate the identified BIAN Service Operations at the target application level to the Target Business Architecture (developed in Phase B), to recognize the relationship between business processes and applications, and to analyze the relationship between business objects and data. The BIAN Business Scenarios in particular can support this mapping activity. In addition, the mapping of the main BIAN deliverables on the TOGAF Content Metamodel supports the execution of this activity.
• • Equally, the BIAN initiative could benefit from this phase by updating the BIAN Service Landscape and BIAN Business Scenarios with the output of this analysis; e.g., the split-up or repositioning of a certain service, or the (updated) execution of a (new) business process.

1.5 Technology architecture

The Technology Architecture phase seeks to map application components defined in the Information Systems Architecture phase onto a set of technology components. Since the BIAN service de nitions are implementation-independent, BIAN does not contribute to this phase directly. However, the result of Phase C will certainly contain specific technical requirements arising out of the BIAN service interfaces. (Note that BIAN Service Operations will be related to other standards such as ISO, IFX, etc., which may imply specific technology components.)

1.6 Opportunities and solutions

Phase E generates an architecture roadmap, which delivers the target architecture. This typically includes deriving a series of Transition Architectures that deliver continuous business value (i.e., capability increments).

• • The BIAN Service Landscape and other BIAN deliverables are created in co-operation with so ware vendors serving the nancial services industry. Hence it is fair to assume that BIAN services leveraged in previous ADM phases will also be (in due time) physically available in the market as COTS so ware solutions or application components.
• • The BIAN Service Landscape and BIAN Business Scenarios can also be used in requirements gathering and vendor and package selections, assessing the compliance of vendors and products with these BIAN deliverables. The compliance of products with the BIAN Service Landscape and BIAN Business Scenarios will increase the seamless integration of the so ware products in an existing (BIAN-compliant) target Business and Application Architecture and thus reduce integration costs.
• The BIAN Service Landscape and Business Scenarios can be used as enablers for designing COTS products in the financial industry space.

1.7 Migration planning

The objectives of Phase F are to nalize the Architecture Roadmap and the detailed Implementation and Migration Plan.

There are no specific BIAN deliverables that act as direct input for this ADM phase. All relevant BIAN input is included in the output of previous ADM phases.

1.8 Implementation governance

The goal of this phase is to govern and manage the implementation and deployment process. There are no specific BIAN deliverables that are direct input for this ADM phase. All relevant BIAN input is included in the output of previous ADM phases.

1.9 Architecture change management

The goal of Phase H is to establish an architecture change management process for the new enterprise architecture baseline.

There are no specific BIAN deliverables that are direct input for this ADM phase. All relevant BIAN input is included in the output of previous ADM phases. However, the tracking of BIAN changes and initiatives should be incorporated into the architecture change management.

 

2 REQUIREMENTSMANAGEMENT

The goal of requirements management is to define a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases.

Leveraging BIAN deliverables in the ADM would guide and structure the capturing of requirements, along the BIAN Service Landscape (including its Business Areas and Business Domains) and BIAN Business Scenarios.

 

3 RELATING BIAN TO TOGAF GUIDELINES AND TECHNIQUES

This section focuses on specific guidelines and techniques related to the ADM cycle that are relevant when using BIAN deliverables in an architectural engagement.

3.1 Applying the ADM at different enterprise levels

The ADM is intended to be used as a model to support the de nition and implementation of architecture at multiple levels within an enterprise.

In general, it is not possible to develop a single architecture that addresses all of the needs of all stakeholders. As can be seen from gure 76, an enterprise can be partitioned into different areas, according to ‘Subject Matter’, ‘Time Period’, and ‘Level of Detail’.

The BIAN Service Landscape and BIAN Business Scenarios are especially useful in the following areas:

• • The definition and/or assessment of the target architectures, especially business and information systems architectures (application and data) and the related definition of change from baseline to target.
• • The assessment and selection of COTS solutions in the market, aimed at achieving compliance with BIAN deliverables and thus reducing integration costs.
• • The BIAN Service Landscape is based on SOA principles. It uses a hierarchical decomposition of the business in terms of Business Areas and underlying Business Domains. BIAN Business Scenarios and the Business Domains from the BIAN Service Landscape might serve as a source of inspiration to de ne ‘segments’ and their relations (cooperation). For each Business Domain, the relevant BIAN Service Domains are recognized and described. is is more related to the ‘capability architecture’ level; however, BIAN does not provide the overall architectural insight at all levels of an organization (company, business unit, division, department, etc …).

3.2 Using TOGAF to de ne and govern SOAs

This chapter discusses the factors related to the adoption and deployment of SOA within the enterprise.

 

Figure Figure 76: Different areas of an enterprise

 

• • The BIAN Business Scenarios can be a useful vehicle to help introduce the BIAN service-oriented designs. ey are initially used in a manner much like a conventional business process, representing the ow of activity associated with a familiar business event in a form that can easily be recognized and understood. The same BIAN Business Scenario representation can then be used to explain the concept of BIAN Service Domains by exposing the discrete role each plays in handling the selected business event.
• • The BIAN Service Landscape is based on SOA principles. Hence, the architect should be aware of if and how SOA is leveraged within the organization. Where necessary, the architecture engagement should include activities required to apply SOA principles in the organization.
• • To be effective, it is necessary to align TOGAF and BIAN terminology beforehand.

3.3 Architecture principles

This chapter describes principles for use in the development of an enterprise architecture. The definition of a principle is: “a qualitative statement of intent that should be met by the architecture”. This applies to principles that:

• • Govern the architecture process;
• • Affect the development, maintenance, and use of the enterprise architecture;
• • Govern the implementation of the architecture.

BIAN has developed various design rationales and supporting design techniques, mainly to define a BIAN Service Domain. Examples include:

• • BIAN Service Domain Operational properties: clearly bounded and with a unique business purpose, a focus object record with full lifecycle handling of its focus object, exclusively service-based, loose coupled and location independent.
• • BIAN Service Domain Design techniques: right-sizing the BIAN Service Domain’s focus objects, assigning a single functional pattern and con rming its role through BIAN Business Scenarios.
• • Not all BIAN design principles are canonical and fully and explicitly described in the BIAN Metamodel. As the construction of the BIAN Service Landscape is based on these specific design principles, it is important to make them as explicit as possible during the execution of the different ADM phases.

3.4 Architecture patterns

In TOGAF a ‘pattern’ is de ned as: “an idea that has been useful in one practical context and will probably be useful in others”.

Patterns describe how, when and why building blocks can be applied, and which trade- offs must be made in doing so. In that sense, BIAN can be used as an additional source for best practices. The BIAN Business Scenarios describe typical patterns of service usage and service interaction. Additionally, BIAN provides patterns for service design.

3.5 Interoperability requirements

Defining the degree to which the information and services are to be shared.

This is a very useful architectural requirement, especially in a complex organization and/or extended enterprise and key in BIAN’s focus. BIAN provides guidelines (in terms of structure with the business landscape or BIAN Service Domain design principles) and content (the BIAN Business Scenarios) that should be met with respect to interoperability.

 

4 BIAN AND THE TOGAF ARCHITECTURE CONTENT FRAMEWORK

The TOGAF Architecture Content Framework consists of the relevant artifacts produced in the ADM cycle. As shown earlier in Section A2.1, the use of BIAN is relevant to several phases of the ADM. These dependencies make it straightforward to map the BIAN deliverables onto the TOGAF Content Metamodel.

It should be noted that the only BIAN deliverables that are mapped are those that provide a direct input in an ADM phase. This means that not all parts of the TOGAF Metamodel are related to specific BIAN deliverables.

4.1 Deliverables, artifacts and building blocks

Figure 77 shows the relations between the different concepts (deliverables, artifacts and building blocks) in TOGAF. Building blocks refer to descriptions of specific parts of an architecture. They are devised in terms of architecture building blocks and solution building blocks.

Figure 77: Deliverables, artifacts and building blocks

 

BIAN focuses on those IT services relevant to the nancial services industry. The structure is based on a common understanding of the business and systems in use. The BIAN Business Scenarios are used to validate the completeness of the Service Landscape. In TOGAF terminology, the BIAN Service Landscape is a structured description of the various architecture building blocks needed to provide the required capabilities in the nancial services industry.

4.2 Mapping the BIAN deliverables to the TOGAF Content Metamodel

The BIAN deliverables listed below can be mapped onto the TOGAF Content Metamodel; BIAN Service Domain principles ensure consistency within a Business Domain:

• • The BIAN Business Scenarios used to validate the BIAN Service Landscape and to ensure completeness can be used as best practice process templates.
• • BIAN focuses on application-to-application integration relevant for the various logical application components.
• • BIAN service de nitions are canonical, implementation-independent descriptions of logical components; hence, physical and technical layers are out of scope.
• • BIAN Services are clustered around focus objects and manage their full lifecycle.
• • Focus objects are relevant to logical Data Architecture.

Using BIAN deliverables in an architecture engagement may require a TOGAF Content Metamodel extension with respect to the BIAN Service Landscape and BIAN Business Scenarios. The services extension is intended to allow more sophisticated modeling of the service portfolio by creating a concept of IT services in addition to the core concept of business services.

 

Figure 78: Mapping BIAN deliverables onto the TOGAF Content Metamodel

 

 

Additional courseware:

      

Click on one of the books for more information!

The post BIAN and TOGAF’s ADM phases appeared first on EN | Van Haren Publishing.