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

288
views

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
288
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
    • 12. A MODEL DRIVEN APPROACH
    • 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
    • 18. CONCEPTUAL BUSINESS SERVICES
    • 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]
    • 27. AN APPROACH TO SPECIFYING A CBS
    • 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
      • http://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 Information
      • Systems 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 SOA
      • http://www.cbdiforum.com/public/meta_model_v2.php accessed 1 September 2008