Your SlideShare is downloading. ×
Socsig Frye Clohesy Presentation
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Socsig Frye Clohesy Presentation


Published on

Conceptual Business Services: An architectural approach for building a business service portfolio

Conceptual Business Services: An architectural approach for building a business service portfolio

Published in: Business, Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • 07/11/06
  • Transcript

    • 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 28 th October 2008 9 June 2009 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
    • 3. How long are we going to continue just cobbling packages together? Every organisation has the systems it deserves
    • 4. Problem Space of Large Enterprises
      • Multiple business unit enterprises based on strategy or specialisation
      • Business units may mange own profit/loss
      • Different priorities and maturities along similar business themes
      • A large number of systems
      • A variety of specialized capabilities
      • Silos of behaviors and specialized, domain specific languages
      • Limited sharing of capabilities and assets across the enterprise
      • Reduced agility
      • Duplication of capabilities
      • High complexity leading to increased delivery risk
      • Potential to culminate in a paralyzed organization
    • 5. Destructive Feedback Loop
    • 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
    • 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
    • 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 .
    • 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 Interoperability
      • Technical decoupling
      • Semantically decoupled
      • Low impact from change
      • Longer time-to-market
      Consumer  Provider = EAI = Services Technical Bus Virtualizing Technology Business Bus Virtualizing Business Canonical business model – Service enabling business Impact Substitute Impact Substitute
    • 10. Technical Interoperability
      • The act of directly exposing functionality via a hub or bus model which virtualizes the computational systems
        • the technology transports,
        • physical locations and
        • The technical constraints of integration are abstracted away from both the consumer and provider of the functionality
        • SOA approaches to date have provided an incremental evolution of connectivity . The benefits achieved are typically limited to single business units, small service libraries or small organizations
    • 11. Business Interoperability
      • Virtualization of business models
      • The use of a mature framework, common reference language or model and skilled professionals are keys to this facilitation within a reasonable time and cost frame
      • Business-centric SOA approach must provide an evolution of not just technical approaches, but of architecture
      • The ability to manage a large library of services (and assets), across many business units within a large enterprise
      • Allows us to then leverage model driven architecture (MDA) approaches to create a powerful service system
      • Conceptual business services play a key role in this advanced architectural method
    • 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
    • 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
    • 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 and contains structured assets
    • 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
    • 17. 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
    • 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
    • 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
    • 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
    • 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
    • 23. Portfolio relationships
      • 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
    • 24. Examples of Domains and Portfolios
      • Domains and portfolios are used to organise and manage services
      • Forms part of ‘scoring’ for a roadmap
    • 25. Principles and Conceptual Business Services
      • Coarse-grained
      • Business aligned
      • Well-defined Contract
      • Loosely Coupled
      • Discoverable
      • Durable
      • Composable
      • Reusable
      • Complete
      • Non-duplicated
    • 26. Helps realise SOA principles These principles as per Sprott [3]
    • 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
    • 29. CBS meta-model
      • Meta-model provides overview of elements and relationships
      • Each of these elements is part of the specification
    • 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
    • 31. CBS Item and corresponding UML artefact A sample of UML artefacts and CBS items CBS 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
    • 32. Anatomy of a Conceptual Business Service
    • 33. Example CBS specification
    • 34. Example of operation detail
    • 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
    • 36. Example Sequence Diagram Using CBS's
    • 37. Example Service Information Model for a CBS
    • 38. Example request message information model
    • 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.
    • 40. Questions!
    • 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 Engineerin g CBDI Journal 2006 July/August Best Practice Report
      • 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 Information
      • Systems Architecture IBM Systems Journal 26, 3
      • (1987), pp 276-292
      • [14] Federal Enterprise Architecture Framework (FEAF) USA EGov accessed 1 September 2008
      • [15] TOGAF, The Open Group Architecture Framework,
      • accessed 1 September 2008
      • [16] CBDI Forum Service Architecture & Engineering meta model for SOA
      • accessed 1 September 2008