BIAN Metamodel v1 En

Banking Industry ArchitectureNetwork

A BIAN Architecture Document

The BIAN Metamodel

Author: BIAN WG Architecture Framework & FoundationVersion: 1.0Last Change: July 1, 2009

BIAN Architecture Document BIAN Metamodel v1.0

© 2009 BIAN e.V.P/O-Box 16 02 5560065 Frankfurt

Germany

Page 2 of 12

Organization

Working Group MembersRole Name Company

Dave Banko SunGard

Reinhard Barkow Steria Mummert

Pierre-Philippe Delmarcelle Callataÿ & Wouters

Victor Dossey Microsoft

Sheldon Fletcher Standard Bank

David Frankel SAP AG

Dr. Stephan Güsken Postbank Systems

Claus Hagen Credit Suisse

Bindia Hallauer Microsoft

Oliver Kling SAP AG

Stephen Lindsay SWIFT

Dr. Uwe Meyer Deutsche Bank

Kevin Perera Temenos

Dr. Peter Röwekamp Steria Mummert

Leo Slegers ING

Pieter Steyn Standard Bank

Vladyslav Yurchenko Axon Global

Reference DocumentsTopic Type of Document Reference to Document

Meta Model - ExplanatoryNotes

Explanation of Meta Model

Version History:Version Date of Change Author

1.0 01/07/2009 BIAN


Copyright© Copyright 2009 by BIAN Association. All rights reserved.

THIS DOCUMENT IS PROVIDED "AS IS," AND THE ASSOCIATION AND ITS MEMBERS, MAKENO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITEDTO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,NONINFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANYPURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANYPATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

NEITHER THE ASSOCIATION NOR ITS MEMBERS WILL BE LIABLE FOR ANY DIRECT,INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ORRELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT UNLESS SUCH DAMAGES ARECAUSED BY WILFUL MISCONDUCT OR GROSS NEGLIGENCE.THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE,OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS TO THEASSOCIATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE ASSOCIATION.

Typographical ConventionsThe type styles shown below are used in this document to distinguish programming statements from ordinaryEnglish. However, these conventions are not used in tables o section headings where no distinction is necessary.

Lucida Sans bold - OMG Interface Definition Language (OMG IDL) and syntax elements.

Courier bold - Programming language elements.

Lucida Sans - Exceptions

Terms that appear in italics are defined in the glossary. Italic text also represents the name of a document,specification, or other publication.



Germany

Page 4 of 12

Table of Contents

1 Introduction..............................................................................................................52 Metamodel Diagram .................................................................................................63 BIAN Metamodel elements.......................................................................................73.1 Remark......................................................................................................................73.2 Description of Terms..................................................................................................73.2.1 Actor ..........................................................................................................................73.2.2 Activity .......................................................................................................................73.2.3 Atomic Activity............................................................................................................73.2.4 Business Area............................................................................................................83.2.5 Business Domain .......................................................................................................83.2.6 Business Object .........................................................................................................83.2.7 Business Subdomain..................................................................................................83.2.8 Component ................................................................................................................93.2.9 Compound Activity .....................................................................................................93.2.10 Constraint ..................................................................................................................93.2.11 Interface.....................................................................................................................93.2.12 Invariant.....................................................................................................................93.2.13 Message .................................................................................................................. 103.2.14 Message Component ............................................................................................... 103.2.15 Pre- and Post-condition............................................................................................ 103.2.16 Service Group.......................................................................................................... 103.2.17 Service Operation .................................................................................................... 103.2.18 Use Case................................................................................................................. 114 References ............................................................................................................. 12



Germany

Page 5 of 12

1 IntroductionThis document defines the Metamodel of the BIAN architecture in the form of a class model, defining thetypes of architectural elements that are used in the architecture products of BIAN and the relationshipsamong the elements. Note that this is work in progress, reflecting the current insights in BIAN. It isexpected to change to keep pace with the evolving architectural and business models of the BIAN as anintegral part of the BIAN activities.

The Metamodel documentation consists of two documents:- BIAN Metamodel_v1: this document- BIAN Metamodel - Explanatory Notes_v1: gives an in depth description of the Metamodel and

positions it within the broader architectural context, including the rationale behind the decisionsmade in its creation.

A related document, BIAN Architecture Glossary, contains more complete definitions of and commentson all relevant architectural terms used in BIAN. The Metamodel definitions are also included in theArchitecture Glossary.

If a definition is taken from an external source, a reference is put between brackets. The precise source ofthe definition is indicated in the reference section.



Germany

Page 6 of 12

2 Metamodel Diagram

Figure 1 - BIAN Meta Model Overview



Germany

Page 7 of 12

3 BIAN Metamodel elements

3.1 RemarkThis section provides definitions and descriptions plus outline explanatory notes. The binding source fordefinitions of terms is the BIAN Architecture Glossary.

3.2 Description of Terms

3.2.1 ActorAn Actor specifies a role played by a user or any other (external) system that interacts with the systemunder consideration.

Commentso Actors are key elements of use case modelso An Actor models a type of role played by an entity that interacts with the subject (= system under

consideration, for example, by exchanging signals and data), but which is external to the subject (i.e.in the sense that an instance of an actor can never be a part of the instance of its correspondingsubject). Actors may represent roles played by human users, external hardware or software, or othersubjects. Note that an actor does not necessarily represent a specific physical entity but merely aparticular facet (i.e. a “role”) of some entity that is relevant to the specification of its associated usecases. Thus, a single physical instance may play the role of several different actors and, conversely,a given actor may be played by multiple different instances.

o As BIAN defines services at a logical level, examples of Actors include business functions andbusiness areas/domains which are the logical equivalent of (groupings of) organizations and ITsystems.

o When looking at services from a provider perspective, the consumers are the actors; from aconsumer perspective, the provider can be seen as an Actor.

Related Conceptso Unified Modeling Language - Actor [UML]

3.2.2 ActivityAn Activity is a generic term for work that a company performs. An Activity can be atomic or non-atomic (compound).

Commento As BIAN is not focusing on standarization of processes the term activity is used as an anchor point

into the world of Business Process Modeling representation e.g. by BPMN.

Related Conceptso Business Process Modeling Notation [BPMN].o Event Driven Process Chains – EPC [EPC]

3.2.3 Atomic ActivityAn Atomic Activity is a task that is included within a process. An Atomic Activity is used when thework in the process is not broken down to a finer level of detail. Hence, an Atomic Activity may beconsidered a leaf node in any process, as it cannot be decomposed further.

Commento An Atomic Activity is a specific realization of an Activity, which has a broad meaning.

Related Conceptso Business Process Modeling Notation [BPMN].



Germany

Page 8 of 12

3.2.4 Business AreaFrom an IT perspective, Business Areas are formed by a broad set of capabilities and responsibilitiesand are an element at the highest level of the hierarchy used to decompose the functions of financialinstitutions. This decomposition is primarily driven by the business understanding and complemented byapplication and information-specific needs.

Commentso BIAN has for example identified (amongst others) the following business areas:

- Sales & Services- Operations & Execution- Analytics

o Business Areas are decomposed (i.e. subdivided) into Business Domains.o Business Areas are part of the Service Landscape of BIAN.

3.2.5 Business DomainA Business Domain represents a coherent set of capabilities and responsibilities.It is an element of the functional decomposition of the banking business functions in the context of theService Landscape. Business Domains are linked to certain skills and knowledge, which are clearlyidentifiable in the banking business.

Commentso A Business Domain belongs to exactly one Business Area and can be decomposed into

Business Subdomains if needed.o Business Domains are part of the Service Landscape

3.2.6 Business ObjectBusiness Objects are individually distinguishable elements and are characterized by the fact that theyhave a well defined identity, structure and behavior.

Commentso In UML the term object denotes an instance of a class. However, in daily IT language, and also within

BIAN, the term object is used synonymously with the formal meaning of class. When used, themeaning inferred by the term object should be clear from the context: an instance or a class.Originally, the object modeling technique was developed as a design technique for object orientedsystems, as is the case for most of the UML modeling techniques.However, as there is a strong need for modeling languages at higher abstraction levels and no suchstandard formal languages are available, the use of UML has been gradually extended to the fullrange of enterprise architecture models, covering all levels of abstraction (conceptual, logical andphysical) and the different perspectives (business, application and infrastructure). The UML conceptof stereotype is used to make clear where a given model is positioned.

o The BIAN object models are at the logical level and are made from an application perspective.o The object replaces the traditional notion of entity (as in entity relationship diagrams). The object

notion is somewhat more precise than the entity notion, but both concepts have an equally broadscope. They can be used to model “anything of interest” of the system being studied.

Related Conceptso Unified Modeling Language - Object [UML].

3.2.7 Business SubdomainA Business Subdomain is the decomposition of a Business Domain to reduce complexity andincrease manageability. A Business Subdomain can be decomposed into further Subdomains whereappropriate. Business Domains define the main units of coherent sets of capabilities as seen from theoutside. Business Subdomains are the internal units of functionality: they are not strictly needed forusing Service Operations, but for organizing the work from the provider perspective.



Germany

Page 9 of 12

3.2.8 ComponentComponents (and Interfaces) are placeholder(s) for platform-specific implementations of services. AnInterface realizes a Service Group, and a Component provides one or more Interfaces and maycall (use) other Interfaces provided by other Components. These placeholder elements establish thelink between semantic definitions of the logical domain and the physical domain of software to be built.The rationale for Component and Interface being placeholder elements is that BIAN focuses onsemantic definitions and does not specify or build implementation of functionality.

Commento The term component is widely used in IT, for example in concepts described in Service Component

Architecture and Windows Communication Foundation [SCA], [WCF].

Related Conceptso Service Component Architecture [SCA],o Windows Communication Foundation [WCF].

3.2.9 Compound ActivityA Compound Activity is an Activity that is composed of other Activities.

Related Conceptso Business Process Modeling Notation [BPMN].

3.2.10 ConstraintA Constraint is a Boolean assertion about a model.

Commento A machine-readable constraint is written in the form of an expression. For example, a Constraint

may be defined using the Object Constraint Language [OCL]o See also: Pre- and Postconditions, Invariants

Related Conceptso Object Constraint Language [OCL]

3.2.11 InterfaceInterfaces are abstract implementation artifacts that link Service Groups (the conceptual description)to the implementation of the relevant functionality (capabilities). See also above.

Commento See Component.o Interfaces build the bridge into platform dependent modeling.

3.2.12 InvariantInvariant is a subtype of Constraint. An Invariant is an assertion about an element (or elements) ofa model that must be true in order for the constrained elements to be well formed.

Commento An Invariant has a context, which can be a Message, a Message Component, or a Business

Object. When the Invariant refers to elements of the model, it does so from the point of view of thecontext element. For example, if the context element is a Business Object that has a balanceproperty, when “balance” appears in the Invariant expression in an unqualified fashion it is assumedto refer to that property.



Germany

Page 10 of 12

3.2.13 MessageA Message is a structured set of information exchanged in the context of a Service Operation. AMessage is assembled from Message Components.

3.2.14 Message ComponentA Message Component is a potentially reusable set of data elements that is a building block forassembling messages. It is linked to one or more a Business Objects.

Commento Modeling, composition and reuse of Message Component in messaging are described by IS0-

20022 (for example).

Related Conceptso ISO-20022 [ISO20022]

3.2.15 Pre- and Post-conditionPre-condition and Post-condition are subtypes of Constraint.A Pre-condition of a Service Operation specifies a state condition of the system that has to be fulfilledat the time when the Service Operation is called in order for the behavior of the Service Operation tobe well defined. A Post-condition of a Service Operation specifies a state condition of the systemthat must be true after a Service Operation has been executed successfully; in essence, a Post-condition describes an effect of the execution of a Service Operation.Pre- and Postconditions additionally play an important role in the definition of Use Cases.

Commentso As we describe Service Operations at a logical level, the Pre- and Post-conditions are of a

business nature. They are distinct from technical Pre- and Post-conditions, which have to bespecified in a technical specification of a Service Operation.For example, a Post-condition for the Create Business Partner Service Operation is that thebusiness partner is created correctly. A technical Post-condition could be that an address iscomplete (contains all required elements).

o The Pre- and Post-conditions of the Service Operations are typically expressed in terms of theBusiness Objects that are involved in the execution of the Service Operation.

o Where the consumer of a service typically is responsible for ensuring that Pre-conditions are met,the provider ensures / guarantees an outcome described via the Post-condition.

3.2.16 Service GroupA Service Group is a grouping of Service Operations of the same Business Subdomain thatsemantically belong together. As a rule of thumb, Services Operations focusing on the sameBusiness Object are grouped into the same Service Group.

3.2.17 Service OperationA Service Operation represents a logical IT service, specifying the access to one or more capabilitiesof a Business Subdomain.

Commentso A Service Operation is grouped into a Service Group.o A Service Operation has a provider and consumers. Service Operations are linked to Use

Cases, describing the environment for which a specific Service Operation is typically intended.Consumers are represented as Actors of these Use Cases.

o Information is passed to a Service Operation by the means of Messages.



Germany

Page 11 of 12

o The access to the implementation domain is provided using a prescribed Interface (see above) andis exercised consistent with Constraints and Policies (not defined yet) as specified by the ServiceOperation.

Related Conceptso WS*-Standards [W3C]o OASIS SOA Reference Model [OASIS]

3.2.18 Use CaseUse Cases are scenarios that specify the required usage of one or more Service Operations. Typicallythey are used to capture the requirements of a Service Operation, defining the behavior of a ServiceOperation.

Related Conceptso Unified Modeling Language [UML]



Germany

Page 12 of 12

4 References

[BPMN] Business Process Modeling Notation- www.bpmn.org- Especially: Link to the BPMN Specification:

http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%201-0%20Spec%2006-02-01.pdf

[EPC] Event Driven Process Chains- http://www.ids-scheer.com/en/ARIS/Modeling_Standards/EPC/79740.html

[OCL] Object Contstraint Language- http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL

[OASIS] SOA-Reference Model- www.open-oasis.org- Especially: Link to the Reference Model:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

[SCA] Services Component Architecture- www.osoa.org- Especially: Link to SCA Assembly Model Specification:

http://www.osoa.org/download/abttachments/35/SCA_AssemblyModel_V096.pdf

[UML] : Unified Modeling Language:- Superstructure Specification - version 2.0 – 04 July 2005,- www.omg.org

[ISO20022] Universal Financial Messaging Standard- www.iso20022.org

[W3C] Web Services- http://www.w3.org/2002/ws/

[WCF] Windows Communication Foundation- http://msdn2.microsoft.com/en-us/netframework/aa663324.aspx

http://www.bpmn.org/

http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%201-0%20Spec%2006-

http://www.ids-scheer.com/en/ARIS/Modeling_Standards/EPC/79740.html

http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL

http://www.open-oasis.org/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

http://www.osoa.org/

http://www.osoa.org/download/abttachments/35/SCA_AssemblyModel_V096.pdf

http://www.omg.org/

http://www.iso20022.org/

http://www.w3.org/2002/ws/

http://msdn2.microsoft.com/en-us/netframework/aa663324.aspx