A. Service Landscape Viewpoint
A. Service Landscape Viewpoint
This diagram highlights key elements of the service landscape.
The ultimate goal of BIAN is to arrive at a set of standardized IT services for banking. A first approach was to get agreement on a common application landscape that could be used as a framework to position the standardized Service Operations. However, we quickly realized that the existing application landscapes of the BIAN banks were too different to allow consolidation into a common application landscape. Indeed, these application landscapes were developed over a long period of time in a rather isolated way. They started out looking like the business world, but gradually diverged from it for lots of reasons: available technology, people and budgets, strategic decisions, mergers and acquisitions, opportunities, and many other accidental events.
To reap the benefits of the agility and interoperability promises of SOA, implementation independence is a key aspect. We therefore headed towards getting a consensus on a common logical functional landscape, consisting of coherent sets of logical capabilities/functionalities. It is called the Service Landscape (and not IT function landscape) to emphasize its role as a framework for supporting the definition and management of the BIAN Service Operations.
By progressively refining this Service Landscape, we have a systematic top-down approach to obtaining elementary functions that expose capabilities through Service Operations. It should be noted that, in reality, the approach BIAN follows is a combination of top-down and bottom-up: we heavily draw upon experiences from the BIAN participants for identifying candidate Service Operations and use the top-down approach mainly for checking consistency, completeness, detecting missing services, etc.
In fact, the Service Landscape is a very powerful instrument for many reasons:
- it acts as an “index” to the service catalogue, offering overview and facilities for discovery and look up
- it helps in organizing the management of Service Operations, assigning ownership
- it is the basic instrument for service portfolio management, i.e. managing the complete set of services as a whole, allowing reporting, monitoring, impact analysis, trend surveys, usage statistics, completeness and consistency checks, etc.
- it serves as a reference framework for migration roadmaps (by projecting existing and target application landscape on the service landscape) or for gap analysis (by projecting a packaged solution and the existing application landscape on the service landscape)
In view of the key role it plays in the BIAN activities and for the management of Service Operations in general, we consider the Service Landscape to be a major deliverable of BIAN. [Currently no comparable standard – besides individual or commercial models - is known within BIAN]
Within BIAN, we identified the need for distinguishing three levels in the IT function tree, each of them having a specific role:
- Business Area
- Business Domain
- Service Domain
BIAN does not define specific BusinessAreas and BusinessDomains as canonical standards. It is not possible to force a particular hierarchical decomposition of business function on all banks. The BusinessAreas and BusinessDomains that BIAN publishes in its service landscape comprise a reference model only. The BIAN ServiceDomains, on the other hand, are canonical, and are designed to fit into an arbitrary number of BusinessArea-BusinessDomain hierarchies.
Class BIANConstraint
package BIAN::Level1
BIANConstraint is a specialization of ISO20022 Constraint.
What makes BIANBusinessAttribute different from ISO20022 BusinessAttribute is that it is a subclass of BIANElement and a subclass of TaggableElement, and thus inherits additional properties from those two superclasses.
"BIAN" was added to the name of this class in order to make its distinction from ISO20022 Constraint obvious, but it was not strictly necessary for disambiguation since two UML classes can have the same unqualified name as long as they are in separate packages.
Direct Superclasses
Associations
Attributes
Constraints
Class BusinessArea
package BIAN::Level1
A BusinessAreas is formed by a broad set of capabilities and responsibilities and lies at the highest level of the service landscape hierarchy. BusinessAreas are used to decompose the functions of financial institutions. This decomposition is primarily driven by business understanding and complemented by application and information-specific needs.
Comments
- BIAN has identified (amongst others) the following business areas:
- Reference Data
- Sales & Service
- Operations & Execution
- Analytics
- Business Support
- BusinessAreas are decomposed (i.e. subdivided) into Business Domains.
- BusinessAreas are part of the Service Landscape of BIAN.
Direct Superclasses
BIANElememt, RepositoryConcept, TaggableElement
Associations
businessDomain : BusinessDomain [1..*]
The BusinessDomains that fall within the BusinessArea. The association is a composition in which BusinessArea plays the role of composite and BusinessDomain plays the role of component.
Attributes
Constraints
Class BusinessDomain
package BIAN::Level1
A BusinessDomain is an element of the functional decomposition of the banking business functions in the context of the Service Landscape. Business Domains are linked to certain skills and knowledge, which are clearly identifiable in the banking business.
Comments
o A BusinessDomain belongs to exactly one BusinessArea
o BusinessDomains are part of the Service Landscape
Direct Superclasses
BIANElememt, RepositoryConcept, TaggableElement
Associations
businessArea : BusinessArea [1]
The BusinessArea to which the BusinessDomain belongs. The association is a composition in which BusinessArea plays the role of composite and BusinessDomain plays the role of component.
serviceDomain : ServiceDomain [1..*]
The ServiceDomains that fall within the BusinessDomain. The association is a shared aggregation in which BusinessDomain plays the role of aggregate and ServiceDomain plays the role of aggregee.
Attributes
Constraints
Class Postcondition
package BIAN::Level2
A Postcondition of a ServiceOperation specifies a condition of the system that must be true at the time when the ServiceOperation has completed executing. It is distinct from a Precondition, which is a condition that must be true when the ServiceOperation is called by a service consumer.
Postcondition is a subclass of BIANConstraint.
Comments
o As we describe ServiceOperations at the level of business semantics, the Postconditions are of a business nature. They are distinct from technical postconditions, which have to be specified in a technical specification of a ServiceOperation.
o Postconditions of ServiceOperations are typically expressed in terms of the BusinessObjects that are involved in the execution of the ServiceOperation.
o Whereas the consumer of a service is responsible for ensuring that Preconditions are met, the service provider ensures / guarantees an outcome described via the Postconditions.
Direct Superclasses
BIANConstraint, TaggableElement
Associations
serviceOperation : ServiceOperation [1]
The ServiceOperation that the Postcondition constrains. The association is a composition in which ServiceOperation plays the role of composite and Postcondition plays the role of component.
Attributes
Constraints
Class Precondition
package BIAN::Level2
A Precondition of a ServiceOperation specifies a condition of the system that has to be true at the time when the ServiceOperation is called in order for the behavior of the ServiceOperation to be well defined. It is distinct from a Postcondition, which must be true after a ServiceOperation has been executed successfully.
Precondition is a subclass of BIANConstraint.
Comments
o As we describe ServiceOperations at the level of business semantics, the Preconditions are of a business nature.
o The Preconditions of ServiceOperations are typically expressed in terms of the BusinessObjects that are involved in the execution of the ServiceOperation.
o The consumer of a service typically is responsible for ensuring that Preconditions are met, whereas the service provider ensures / guarantees an outcome described via the Postconditions.
Direct Superclasses
BIANConstraint, TaggableElement
Associations
serviceOperation : ServiceOperation [1]
The ServiceOperation that the Precondition constrains. The association is a composition in which ServiceOperation plays the role of composite and Precondition plays the role of component.
Attributes
Constraints
Class ServiceDomain
package BIAN::Level1
A ServiceDomain represents an ‘atomic’ logical design. Atomic means that a BIAN Service Domain represents the smallest practical capability or functional partition that can be service-enabled as a discrete and unique business capability.
All BIAN Service Domains taken together make up a ‘peer set’ with each performing its own specific business function or purpose. BIAN arranges this collection of Service Domains into a reference framework called the BIAN Service Landscape.
A ServiceDomain owns a set of ServiceGroups, each of which owns a set of ServiceOperations. A ServiceDomain also owns a BusinessObject called its focusObject.
Direct Superclasses
BIANElememt, RepositoryConcept, TaggableElement
Associations
businessDomain : BusinessDomain [1..*]
The BusinessDomains within which the ServiceDomain is grouped. The association is a shared aggregation in which BusinessDomain plays the role of aggregate and ServiceDomain plays the role of aggregee.
providedContract : ServiceGroup [1..*]
The ServiceGroups that the ServiceDomain is contractually obligated to provide. The association is a composition in which ServiceDomain plays the role of composite and ServiceGroup plays the role of component.
consumedContract : ServiceGroup [0..*]
The ServiceGroups that other ServiceDomains provide and that this ServiceDomain consumes.
responsibility : Responsibility [1..*]
The Responsibilities that the ServiceDomain assumes. The association is a composition in which ServiceDomain plays the role of composite and Responsibility plays the role of component.
focusObject : BusinessObject [1]
The BusinessObject whose instances are managed by the ServiceDomain.
referencedObject : BusinessObject [0..*]
The BusinessObjects whose instances the ServiceDomain references but does not manage.
delegation : Delegation [0..*]
The Delegations that target this ServiceDomain.
notification : Notification [0..*]
The Notifications to which this ServiceGroup subscribes.
relevantScenario : BusinessScenario [0..*]
The BusinessScenarios in which the ServiceDomain is involved.
Attributes
businessPurpose : string [1]
A description of the ServiceDomain's unique business purpose,
Constraints
Class ServiceGroup
package BIAN::Level2
A ServiceGroup is a set of ServiceOperations, and is owned by a ServiceDomain. In essence, it is an interface to the ServiceDomain that is defined in terms of business semantics rather than in technical IT terms.
Direct Superclasses
BIANElememt, RepositoryConcept, TaggableElement
Associations
provider : ServiceDomain [1]
The ServiceDomain that is contractually obligated to provide the ServiceGroup's ServiceOperations. The association is a composition in which ServiceDomain plays the role of composite and ServiceGroup plays the role of component.
serviceOperation : ServiceOperation [1..*]
The ServiceOperations that make up the ServiceGroup.
consumer : ServiceDomain [0..*]
The ServiceDomains that consume the ServiceGroup's ServiceOperations when delegating a Responsibility.
realization : ImplementationInterface [0..*]
The ImplementationInterfaces that realize the ServiceGroup.
Attributes
Constraints
Class ServiceOperation
package BIAN::Level2
A ServiceOperation represents a service defined at the level of business semantics, specifying the access to one or more capabilities of a ServiceDomain.
Comments
o ServiceOperations are grouped into ServiceGroups.
o A ServiceOperation has a provider and consumers.
o Information is passed in and out of a ServiceOperation by the means of Messages.
Related Concepts
o WS*-Standards [W3C] define service operations via WSDL
o OASIS SOA Reference Model [OASIS]
Direct Superclasses
BIANElememt, RepositoryConcept, TaggableElement
Associations
serviceGroup : ServiceGroup [1]
The ServiceGroup to which the Operation belongs. The association is a composition in which ServiceGroup plays the role of composite and ServiceOperation plays the role of component.
inputMessage : Message [0..1]
The Message that serves as the ServiceOperation's input parameter.
outputMessage : Message [0..1]
The Message that serves as the ServiceOperation's output parameter.
faultMessage : Message [1]
The Message that serves as the ServiceOperation's fault Message.
realizedDelegation : Delegation [0..1]
The Delegations that ServiceDomains realize by consuming this ServiceOperation
realizedCapability : Capability [1..*]
The Capabilities that are carried out via this ServiceOperation.
precondition : Precondition [0..*]
The Preconditions that constrain this ServiceOperation. The association is a composition in which ServiceOperation plays the role of composite and Precondition plays the role of component.
postcondition : Postcondition [0..*]
The Postconditions that constrain this ServiceOperation. The association is a composition in which ServiceOperation plays the role of composite and Postcondition plays the role of component.
Attributes
invocationKind : InvocationKind [0..1]
The ServiceOperation's invocation style.
Constraints
The target ServiceDomain of a Delegation that the ServiceOperation realizes is the ServiceDomain that owns the ServiceOperation.
[realizedDelegation.target = self.serviceGroup.provider]
Each Capability that the ServiceOperation realizes fulfills a Responsibility of the same ServiceDomain that owns the ServiceOperation
[realizedCapability->forAll( fulfilledResponsibility.responsibleServiceDomain = self.serviceGroup.provider)]
The precondition property is derived by using the constraint property inherited from ISO20022's RepositoryConcept element. The derivation rule is: start with the set of all Constraints that pertain to the ServiceOperation, and from that set collect only those Constraints that are Preconditions. In practice it is unlikely that ServiceOperations will have Constraints that are neither Preconditions nor Postconditions.
[precondition = constraint->collect (c | c.oclIsKindOf(precondition))]
The postcondition property is derived by using the constraint property inherited from ISO20022's RepositoryConcept element. The derivation rule is: start with the set of all Constraints that pertain to the ServiceOperation, and from that set collect only those that are Postconditions. In practice it is unlikely that ServiceOpertions will have Constraints that are neither Preconditions nor Postconditions.
[postcondition = constraint->collect (c | c.oclIsKindOf(postcondition))]
Enumeration InvocationKind
The invocation style of a ServiceOperation.
package BIAN::Level2
Literals
WITH_RESPONSE
NO_RESPONSE
NOTIFICATION