Socsig Frye Clohesy Presentation

Page: 111 April 2023 Page: 1

Conceptual Business Service:

An Architectural Approach for Building a Business Service Portfolio Alan Frye - the Head of Enterprise Integration Strategy, Planning and Architecture, Office of the CTO at ANZ Banking Group

Ben Clohesy - Principal Consultant SystemicLogic

Australian Computer Society - Service Oriented Computing - Special Interest Group

28th October 2008

Page: 2

Agenda

• The principles behind SOA and the difficulty in aligning to business concerns

• Business and Technical Interoperability• The need for structured assets• A Conceptual Business Service (CBS)• A business services portfolio• Principles and Conceptual Business Services• Example specifications• Conclusion• Questions and Discussion• References

Page: 3

How long are we going to continue just cobbling packages together?

How long are we going to continue just cobbling packages together?

Every organisation has the systems it deservesEvery organisation has the systems it deserves

Page: 5

Destructive Feedback Loop

Page: 6

SOA Principles and Alignment with Business

• SOA principles provide guidance and structure – loose coupling – abstraction – virtualisation

• Adherence to them may result in an apparent mis-alignment of business concerns from technology

• There is a need for the business rather than the technologists, to take greater control

• The business must have a better understanding of the business processes, services and assets that can be leveraged

Page: 7

EAI to Achieve Technical Interoperability

Enterprise Application Integration (EAI) approaches solved the technical inefficiencies of point-to-point system connectivity by providing greater levels of technical interoperability

Page: 8

Promise of SOA

• SOA is an incremental improvement upon traditional enterprise application integration (EAI) approaches

• EAI solved connectivity issues by providing technical interoperability

• Core problem in achieving these outcomes is not one of technology, but of understanding business concepts

• The focus must shift from that of technical interoperability to that of achieving business interoperability.

Page: 9

Technical versus Business Interoperability

Even if consumer change is

mitigated by consumer mediation adaptors, count how many are

impacted by provider

substitutions

Service enabling of systems

Consumer Provider

Technical Interoperability Technical decoupling Semantically coupled High impact from change- Quick time-to-market – initially

Business InteroperabilityTechnical decoupling Semantically decoupled Low impact from change Longer time-to-market

Consumer Provider

= EAI = Services

Technical BusVirtualizing Technology

Business BusVirtualizing Business

Canonical business model – Service enabling business

Impact SubstituteSubstitute

Impact

Page: 12

A MODEL DRIVEN APPROACH

Page: 13

Why Model?

• Capture the relationships between people and work they do

• Capture the dependencies between elements

• Understand how the many parts of a business relate to each other

• Avoid the ‘telephone book’ of documentation

• Uncover hidden relationships between elements

• Provides ‘structured assets’

• Documents just don’t cut it anymore

Page: 14

Structured Assets

• A formal and organised view of an item of value• The intellectual property of an organisation including

– the code/applications– specifications for the functionality provided

• May be viewed in the context of the total lifecycle of the organisation’s systems when represented by rich metadata and formal diagrams

• Typically part of a business reference model, for instance using some framework and UML

• Important to hold structured assets or otherwise there is a likelihood of fragmented and incomplete system IP

Page: 15

Types of frameworks• There are many different frameworks• Some examples include:

– Zachman– FEAF– TOGAF– OMG MDA

• The Business Reference Model is part of a framework andcontains structured assets

Page: 16

A Business Reference Model

• Many different types of models with different structures

• The following views may be present:– Business View - a functional view of the

organisation including process models– Information View - the information subject

areas of interest to the organisation– Dynamic View - states for events and

reference information– Technology View - a system oriented view

of the organisation including applications portfolios and architectural views

– Business Service View - the business service portfolio

Page: 17

class Information Architecture High Lev el Vi...

Financial Actor

+ Actor

+ Organisation

+ Person

+ Actor Roles and Relationships

+ Actor Role Types

+ Actor Relationship Types

+ Customer

Financial Objectiv es

+ Actor Need

+ Actor Objective

+ Need Type

+ Objective Amount

+ Objective Type

+ Plan

+ Plan Need

+ Plan Objective

+ Plan Product

+ Plan Role

+ Plan Role Type

+ Plan Score

+ Plan Status

+ Plan Status Type

+ Plan Type

+ Business Motivation

+ Objective TypesFinancial Agreement

+ Agreement

+ Agreement A sset Usage

+ Agreement Item

+ Agreement Role

+ Agreement Role Type

+ Agreement Status

+ Agreement Status Type

+ Agreement Term

+ Asset Role

+ Asset Role Type

+ Asset Usage Type

+ Financial Agreement Type

+ Agreement Item Type

+ Agreement Term Types

+ Assets

Financial Products and Serv ices

+ Functional Setting

+ Product

+ Product Category

+ Product Cost

+ Product Feature Category

+ Product Portfolio

+ Product Price Component

+ Product Profitabil ity

+ Product Revenue

+ Applicabil ity

+ Market

+ Product Category

+ Product Feature

+ Product Rules and Regulations

+ Geography

Financial Serv ice Deliv ery

+ Channel

+ Documentation

+ Financial Accounting

+ Financial Account

+ Financial Account Transaction

+ Bil ling

+ Work Delivery

+ Technology

Name: Information Architecture High Level ViewAuthor: SystemicLogicVersion: 0.9.5Created: 1/11/2007 15:52:21Updated: 27/10/2008 16:55:59

A Customer has specific financial needsand objectives. The Financial Institution provides for those needs through its products and services by forming an product or service agreement with the Customer.

The Product or Service Agreement stipulates the terms and rules on which the relationship between the Customer and Financial Institution wil l operate.

The Customer's receives or requests service which is bound by the product or service agreement provided by the Financial Insitution. The provisions of service to the Customer is executed through Service Delivery.

Canonical Information Model

• The information view contains the Canonical Information Model• The Canonical Information Model provides a single vocabulary and

thus the common language for the organisation

(e.g. concepts such as account are not consistently used or understood. An account may be seen as one of: a customer or party, a set of transactions with balances, a product type)

• The services which represent abstract business functions are termed a Conceptual Business Service (CBS) in our approach

• The common concepts are the basis of the information required for use across the enterprise

Page: 18

CONCEPTUAL BUSINESS SERVICES

Page: 19

What is a Conceptual Business Service?

• Provides a package of functionality related to achievement of a business process or step

• Reflects business concepts and events and is associated with execution of business functions

• Resembles real world tasks and things • Recognisable to non-technical process performers.• Provides a bridge between technical domain and non-technical domain

– common point of communication• Avoids technical descriptions, however structured

and tied to technical concepts• Not directly implemented as code • Technical (or software) services are

implementations of CBSs

• Used as a point of organisation and management

pkg Customer Relationship Conceptual Business Serv ice Diagr...

«ANZ Business Service»Customer Relationship

+ InquiryProvide a l ist of party to party relationshipsProvide a l ist of parties who are related to one another through an active arrangement

+ AddAdd a party to party relationship

+ ModifyModify a party to party relationship

tagsAvailabil i ty = SilverHours of Operation = Standard Australian Business HoursMax Response Time = 15 secondsPeak Usage = MediumPriority = HighResponse Times = StandardSecurity = Confidentiality and Integrity controls must be consideredSupportabil ity = To be able to maintain relationship type valuesTransactional = FalseTransactional Control = Not applicableUsabil ity = English language only; Code to be translated to meaningful terms

notesProvides a business service to manage the related customers and the relationship types for a given customer

Page: 20

Conventional Strategic Alignment

• Traditional business strategy to technology is done in a point-to-point manner

• Strategy is developed a project is set up something is built

• Creates alignment at a single point

• Fine for an organisation that has only a single line of business in one location

Page: 21

Strategic Alignment via Conceptual Abstraction

• Business determines overall strategy• Moves through layers of business

architecture (incl. operational areas, marketing, process etc.) until a project is created to deliver against strategy

• Service portfolio is consulted to determine the CBS’s that are available or planned

• Requirements of the project are lifted to a more abstract level and expressed as responsibilities

• Specification of CBS to meet project needs is created and used as central point for technology build (or acquisition)

• Service then moves through the layers and policies determined by the organisation for their SOA

• Helps ensure alignment to strategy not just project objectives

Page: 22

A Business Services Portfolio

• Used to manage the organisations conceptual business services

• Series of Business Service Domains• Within the service domains are a number of service

portfolios• Utilised to move towards federation or other approaches

depending on the organisation’s strategy, structure and maturity

• The structure and some examples are shown on the following two slides

Page: 23

Portfolio relationships class Domains and Portfolios

Service Domain

Service Portfolio

Conceptual Business Service

Owner

11.. *

+Portfolio 1

+BusinessServices 1.. *

0..*+PortfolioOwner

1

• Service Domains contain Service Portfolios which contain Conceptual Business Services

• Portfolios and Services have an Owner

• Structure is used as the basis for managing demand and development

• The Service Portfolio becomes a Structured Asset

Page: 24

Examples of Domains and Portfolios• Domains and

portfolios are used to organise and manage services

• Forms part of ‘scoring’ for a roadmap

Page: 25

Principles and Conceptual Business Services

• Coarse-grained• Business aligned• Well-defined Contract• Loosely Coupled• Discoverable• Durable• Composable• Reusable• Complete• Non-duplicated

Page: 27

AN APPROACH TO SPECIFYING A CBS

Page: 28

Specifying Conceptual Business Services

• This approach to specifying a CBS uses a meta-model and UML

• The meta-model provides an overarching view of the elements that make up a service

• It provides the connection through to the business reference model and alignment to strategy

Page: 29

CBS meta-model class Simplified Ov erv iew of Serv ice Portfolio Meta Model

CBS Elements

Conceptual Business Service

Service Portfolio

Service Domain

Owner

BusinessProces sActor

ProcessRole

ProcessSte p

UseCas e

Business Contex t

Change Cas e

Serv ice Information Model

Responsibility

Goal

Objective

Strategy

Tactic

Project

Requirement

Serv ice Operation

Message Information ModelCommon Information Model

0..*

0..*

0..*

+PortfolioOwner 1

+Portfolio 1

+BusinessServices 1.. *

1.. *

1.. * 11.. *

• Meta-model provides overview of elements and relationships

• Each of these elements is part of the specification

Page: 30

Potential CBS and Service Relationship• Can build on other concepts

(e.g. from CBDI Forum Service Architecture & Engineering meta-model for SOA)

• Extension points:– SERVICE

PACKAGE::Service (notional)

– SERVICE PACKAGE::Software Service

– SERVICE PACKAGE:: Non-Software Service

• Relationship would usually conform to that expressed in the diagram

pkg CBS and Serv ice (notional)

Conceptual Business Service

Service (notional)

Nonsoftware Service Software Service

Page: 31

CBS Item and corresponding UML artefactCBS Item UML Artefact

Conceptual Business Service Class Stereotyped as «CBS»

Operation Operation in a Class

Domain Package

Portfolio Package

Responsibility Requirement

Service Information Model Class Diagram

Message Information Model Class Diagram

A sample of UML artefacts and CBS items

Page: 32

Anatomy of a Conceptual Business Service

Page: 33

Example CBS specification pkg Party Relationship Conceptual Business Serv ice Diagram

Business Contex t

+ AML Customer Relationship

+ Private Bank Customer Relationship

Back to Customer Relationship Portfolio Diagram

View the Service Information Model

«Conceptual Business Service»Party Relationship

+ Add+ Inquire+ Modify

tagsAvailability = SilverHours of Operation = Standard Australian Business HoursMax Response Time = 15 secondsPeak Usage = MediumPriority = HighResponse Times = StandardSecurity = Confidentiality and Integrity controls must be consideredSupportability = To be able to maintain relationship type valuesTransactional = FalseTransactional Control = Not applicableUsability = English language only; Code to be translated to meaningful terms

notesProvides a business service to manage the related customers and the relationship types for a given customer

View the Customer Relationship Change Case Diagram

Change Case s

+ Add Asia

+ Add corporate client relationships

+ Add New Zealand

+ Add third party products

+ Extended relationship record controls

+ Extended relationship record controls

+ None

+ Provide add capability

+ Provide modify capability

+ Relationship type inclusion/exclusion list

+ Relationship type inclusion/exclusion list

Page: 34

Example of operation detail

Page: 35

Business Context

• The business context package displays those contexts that the CBS may be used within. This is a combination of – Brand– Channel– Region– Organisational unit– Process– Role

• Allows application of project requirements in many varieties• Defines the point of variation and captures the

commonalities

pkg Customer Relationship Conceptual Business Serv ice Di...

Customer Relationship Business Context View

+ AML Customer Relationship Business Context

+ Private Bank Customer Relationship Business Context

Page: 36

Example Sequence Diagram Using CBS's

:SystemUnderDiscussion:CSO«CBS»:Party

Add CustomerAdd Customer

AddAdd

Confirm := Customer IDConfirm := Customer ID

«CBS»:PartyDetails

Change customer detailsChange customer details

Modify (Customer ID, Changes)Modify (Customer ID, Changes)

ModifyModify

Page: 37

Example Service Information Model for a CBS class Customer Relationship Serv ice Information Model

Party

- Operating Context: Operating Context [0..*]- PartyDisplayName: char

PartyPartyRelationship

- PartyPartyRelationshipEffectiveDate: date- PartyPartyRelationshipExpiryDate: date

«enumeration»PartyPartyRelationshipType

«enum» AlsoKnownA s IsBusinessCardBill ingGroupOwnerOf IsGroupCreditPolicyMemberWith IsChairmanOf IsCLGMemberOf IsDirectorOf IsKeyContactFor IsManagingDirectorOf IsPartnerIn IsFamilyMemberOf IsSubsidiaryOf IsSubsidiaryOwnerOf IsSecretaryOf IsSpouseOf IsTradingA s IsTreasurerOf

PartyIdentifier

- PartyIdentifierValue: char

«enumeration»PartyIdentifierType

«enum» CustomerNumber CLGNumber

AccountPartyRelationship

- DirectIndirectIndicator: char

«enumeration»AccountPartyRelationshipType

«enum» SoleOwner CoOwnerFirst CoOwnerOther TrusteeFirst TrusteeOther DirectBeneficiary PrimaryResponsibil ity ThirdPartySignatory Beneficiary IndirectTrusteeFirst IndirectTrusteeOther Guarantor PowerOfAttorney

Account

- AccountName: char- AccountNumber: int

«enumeration»AccountStatus

«enum» Ope n Inactive NotAvailable

Back to the Customer Relationship Service Information Package Diagram

Arrangement

0..* 1

0..* 1

+PartyPartyRelationshipType

0..*

1

+PtyIdTp

0..*

1

+AccountPartyRelationshipType

0..* 1

+AccountStatus

0..*

1

0..*1

Page: 38

Example request message information model

class Customer Relationship Inquiry Request - MIM

Party

- Operating Context: Operating Context [0..*]

Party Identifier

- Party Identifier Value: char

Back to Customer Relationship Service Information Package Diagram

«enumeration»Party Identifier Type

«enum» CustomerNumber CLGNumber

Page: 39

Conclusion

• More emphasis needs to be placed on business interoperability now that technical interoperability is better understood

• To achieve business interoperability an approach is required that defines function and corresponding services at a high enough level of abstraction to allow strategic alignment

• When defining a CBS reliance is placed on the existence of a business reference model which includes a canonical information model

• The CBS is a basis for a portfolio of business services• The portfolio is navigable and allows recognition of services that fulfill

needs across the organisation.

Page: 40

Questions!

Page: 41

References[1] Alonso G., Casati F., Kuno H. and Machiraju V.; Web Services : Concepts, Architectures and Applications; Springer-Verlag 2004[2] Erl T. SOA Principles of Service Design Prentice Hall PTR 2007[3] Sprott D. Service Architecture and Engineering CBDI Journal 2006 July/August Best Practice Reporthttp://www.cbdiforum.com/secure/interact/2006-07/serv_archi_eng.php 2006[4] Lewis, Grace A.; Morris, Edwin; Simanta, Soumya; Wrage, Lutz; Common Misconceptions about Service-Oriented Architecture Sixth International

IEEE Conference on Commercial-off-the-Shelf (COTS)-Based Software Systems (ICCBSS'07) 2007[5] Anderson W. What COTS and Software Reuse Teach Us about SOA Sixth International IEEE Conference on Commercial-off-the-Shelf (COTS)-

Based Software Systems (ICCBSS'07) 2007[6] Wei Tan; Zhong Tian; Fangyan Rao; Li Wang; Ru Fang; Process Guided Service Composition in Building SOA Solutions: A Data Driven Approach

Web Services, 2006. ICWS '06. International Conference on Page(s):558 - 568 Sept. 2006[7] Kotonya, Gerald; Hutchinson, John A Service-Oriented Approach for Specifying Component-Based Systems Sixth International IEEE Conference

on Commercial-off-the-Shelf (COTS)-Based Software Systems, 2007 (ICCBSS '07) pp.150 – 162 Feb. 26 2007-March 2 2007[8] Zdun U. Carsten Hentrich C. and Dustdar S. Modeling Process-Driven and Service-Oriented Architectures Using Patterns and Pattern Primitives

ACM Transactions on the Web, Vol. 1, No. 3, Article 14, Publication date: September 2007[9] Zdun U. Avgeriou P.Hentrich C.and Dustdar S. Architecting as Decision Making with Patterns and Primitives SHARK’08, May 13, 2008, Leipzig,

Germany 2008[10] Pfadenhauer, K. Dustdar, S. Kittl, B. Challenges and Solutions for Model Driven Web Service Composition, Proceedings of the 14th IEEE

International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprise (WETICE’05)[11] Feenstra R., Janssen M. Service Portfolios for Managing Modular Networks May 2008: Proceedings of the 2008 international conference on

Digital government research (DGO'08) 2008[12] Aoyama M. A Business-Driven Web Service Creation Methodology Proceedings of the 2002 Symposium on Applications and the Internet

(SAINT.02w) IEEE 2002[13] Zachman J.A. A Framework for InformationSystems Architecture IBM Systems Journal 26, 3(1987), pp 276-292[14] Federal Enterprise Architecture Framework (FEAF) USA EGov

http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html accessed 1 September 2008[15] TOGAF, The Open Group Architecture Framework,http://www.opengroup.org/togaf/ accessed 1 September 2008[16] CBDI Forum Service Architecture & Engineering meta model for SOAhttp://www.cbdiforum.com/public/meta_model_v2.php accessed 1 September 2008