socsig frye clohesy presentation
DESCRIPTION
Conceptual Business Services: An architectural approach for building a business service portfolioTRANSCRIPT
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