Successfully reported this slideshow.

Socsig Frye Clohesy Presentation

503 views

Published on

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

Socsig Frye Clohesy Presentation

  1. 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. 2. Agenda <ul><li>The principles behind SOA and the difficulty in aligning to business concerns </li></ul><ul><li>Business and Technical Interoperability </li></ul><ul><li>The need for structured assets </li></ul><ul><li>A Conceptual Business Service (CBS) </li></ul><ul><li>A business services portfolio </li></ul><ul><li>Principles and Conceptual Business Services </li></ul><ul><li>Example specifications </li></ul><ul><li>Conclusion </li></ul><ul><li>Questions and Discussion </li></ul><ul><li>References </li></ul>
  3. 3. How long are we going to continue just cobbling packages together? Every organisation has the systems it deserves
  4. 4. Problem Space of Large Enterprises <ul><li>Multiple business unit enterprises based on strategy or specialisation </li></ul><ul><li>Business units may mange own profit/loss </li></ul><ul><li>Different priorities and maturities along similar business themes </li></ul><ul><li>A large number of systems </li></ul><ul><li>A variety of specialized capabilities </li></ul><ul><li>Silos of behaviors and specialized, domain specific languages </li></ul><ul><li>Limited sharing of capabilities and assets across the enterprise </li></ul><ul><li>Reduced agility </li></ul><ul><li>Duplication of capabilities </li></ul><ul><li>High complexity leading to increased delivery risk </li></ul><ul><li>Potential to culminate in a paralyzed organization </li></ul>
  5. 5. Destructive Feedback Loop
  6. 6. SOA Principles and Alignment with Business <ul><li>SOA principles provide guidance and structure </li></ul><ul><ul><li>loose coupling </li></ul></ul><ul><ul><li>abstraction </li></ul></ul><ul><ul><li>virtualisation </li></ul></ul><ul><li>Adherence to them may result in an apparent mis-alignment of business concerns from technology </li></ul><ul><li>There is a need for the business rather than the technologists, to take greater control </li></ul><ul><li>The business must have a better understanding of the business processes, services and assets that can be leveraged </li></ul>
  7. 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. 8. Promise of SOA <ul><li>SOA is an incremental improvement upon traditional enterprise application integration (EAI) approaches </li></ul><ul><li>EAI solved connectivity issues by providing technical interoperability </li></ul><ul><li>Core problem in achieving these outcomes is not one of technology, but of understanding business concepts </li></ul><ul><li>The focus must shift from that of technical interoperability to that of achieving business interoperability . </li></ul>
  9. 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 <ul><li>Technical Interoperability </li></ul><ul><li> Technical decoupling </li></ul><ul><li>Semantically coupled </li></ul><ul><li>High impact from change </li></ul><ul><li>- Quick time-to-market – initially </li></ul><ul><li>Business Interoperability </li></ul><ul><li>Technical decoupling </li></ul><ul><li>Semantically decoupled </li></ul><ul><li>Low impact from change </li></ul><ul><li>Longer time-to-market </li></ul>Consumer  Provider = EAI = Services Technical Bus Virtualizing Technology Business Bus Virtualizing Business Canonical business model – Service enabling business Impact Substitute Impact Substitute
  10. 10. Technical Interoperability <ul><li>The act of directly exposing functionality via a hub or bus model which virtualizes the computational systems </li></ul><ul><ul><li>the technology transports, </li></ul></ul><ul><ul><li>physical locations and </li></ul></ul><ul><ul><li>The technical constraints of integration are abstracted away from both the consumer and provider of the functionality </li></ul></ul><ul><ul><li>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 </li></ul></ul>
  11. 11. Business Interoperability <ul><li>Virtualization of business models </li></ul><ul><li>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 </li></ul><ul><li>Business-centric SOA approach must provide an evolution of not just technical approaches, but of architecture </li></ul><ul><li>The ability to manage a large library of services (and assets), across many business units within a large enterprise </li></ul><ul><li>Allows us to then leverage model driven architecture (MDA) approaches to create a powerful service system </li></ul><ul><li>Conceptual business services play a key role in this advanced architectural method </li></ul>
  12. 12. A MODEL DRIVEN APPROACH
  13. 13. Why Model? <ul><li>Capture the relationships between people and work they do </li></ul><ul><li>Capture the dependencies between elements </li></ul><ul><li>Understand how the many parts of a business relate to each other </li></ul><ul><li>Avoid the ‘telephone book’ of documentation </li></ul><ul><li>Uncover hidden relationships between elements </li></ul><ul><li>Provides ‘structured assets’ </li></ul><ul><li>Documents just don’t cut it anymore </li></ul>
  14. 14. Structured Assets <ul><li>A formal and organised view of an item of value </li></ul><ul><li>The intellectual property of an organisation including </li></ul><ul><ul><li>the code/applications </li></ul></ul><ul><ul><li>specifications for the functionality provided </li></ul></ul><ul><li>May be viewed in the context of the total lifecycle of the organisation’s systems when represented by rich metadata and formal diagrams </li></ul><ul><li>Typically part of a business reference model, for instance using some framework and UML </li></ul><ul><li>Important to hold structured assets or otherwise there is a likelihood of fragmented and incomplete system IP </li></ul>
  15. 15. Types of frameworks <ul><li>There are many different frameworks </li></ul><ul><li>Some examples include: </li></ul><ul><ul><li>Zachman </li></ul></ul><ul><ul><li>FEAF </li></ul></ul><ul><ul><li>TOGAF </li></ul></ul><ul><ul><li>OMG MDA </li></ul></ul><ul><li>The Business Reference Model is part of a framework and contains structured assets </li></ul>
  16. 16. A Business Reference Model <ul><li>Many different types of models with different structures </li></ul><ul><li>The following views may be present: </li></ul><ul><ul><li>Business View - a functional view of the organisation including process models </li></ul></ul><ul><ul><li>Information View - the information subject areas of interest to the organisation </li></ul></ul><ul><ul><li>Dynamic View - states for events and reference information </li></ul></ul><ul><ul><li>Technology View - a system oriented view of the organisation including applications portfolios and architectural views </li></ul></ul><ul><ul><li>Business Service View - the business service portfolio </li></ul></ul>
  17. 17. Canonical Information Model <ul><li>The information view contains the Canonical Information Model </li></ul><ul><li>The Canonical Information Model provides a single vocabulary and thus the common language for the organisation </li></ul><ul><ul><li>(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) </li></ul></ul><ul><li>The services which represent abstract business functions are termed a Conceptual Business Service (CBS) in our approach </li></ul><ul><li>The common concepts are the basis of the information required for use across the enterprise </li></ul>
  18. 18. CONCEPTUAL BUSINESS SERVICES
  19. 19. What is a Conceptual Business Service? <ul><li>Provides a package of functionality related to achievement of a business process or step </li></ul><ul><li>Reflects business concepts and events and is associated with execution of business functions </li></ul><ul><li>Resembles real world tasks and things </li></ul><ul><li>Recognisable to non-technical process performers. </li></ul><ul><li>Provides a bridge between technical domain and non-technical domain – common point of communication </li></ul><ul><li>Avoids technical descriptions, however structured and tied to technical concepts </li></ul><ul><li>Not directly implemented as code </li></ul><ul><li>Technical (or software) services are implementations of CBSs </li></ul><ul><li>Used as a point of organisation and management </li></ul>
  20. 20. Conventional Strategic Alignment <ul><li>Traditional business strategy to technology is done in a point-to-point manner </li></ul><ul><li>Strategy is developed  a project is set up  something is built </li></ul><ul><li>Creates alignment at a single point </li></ul><ul><li>Fine for an organisation that has only a single line of business in one location </li></ul>
  21. 21. Strategic Alignment via Conceptual Abstraction <ul><li>Business determines overall strategy </li></ul><ul><li>Moves through layers of business architecture (incl. operational areas, marketing, process etc.) until a project is created to deliver against strategy </li></ul><ul><li>Service portfolio is consulted to determine the CBS’s that are available or planned </li></ul><ul><li>Requirements of the project are lifted to a more abstract level and expressed as responsibilities </li></ul><ul><li>Specification of CBS to meet project needs is created and used as central point for technology build (or acquisition) </li></ul><ul><li>Service then moves through the layers and policies determined by the organisation for their SOA </li></ul><ul><li>Helps ensure alignment to strategy not just project objectives </li></ul>
  22. 22. A Business Services Portfolio <ul><li>Used to manage the organisations conceptual business services </li></ul><ul><li>Series of Business Service Domains </li></ul><ul><li>Within the service domains are a number of service portfolios </li></ul><ul><li>Utilised to move towards federation or other approaches depending on the organisation’s strategy, structure and maturity </li></ul><ul><li>The structure and some examples are shown on the following two slides </li></ul>
  23. 23. Portfolio relationships <ul><li>Service Domains contain Service Portfolios which contain Conceptual Business Services </li></ul><ul><li>Portfolios and Services have an Owner </li></ul><ul><li>Structure is used as the basis for managing demand and development </li></ul><ul><li>The Service Portfolio becomes a Structured Asset </li></ul>
  24. 24. Examples of Domains and Portfolios <ul><li>Domains and portfolios are used to organise and manage services </li></ul><ul><li>Forms part of ‘scoring’ for a roadmap </li></ul>
  25. 25. Principles and Conceptual Business Services <ul><li>Coarse-grained </li></ul><ul><li>Business aligned </li></ul><ul><li>Well-defined Contract </li></ul><ul><li>Loosely Coupled </li></ul><ul><li>Discoverable </li></ul><ul><li>Durable </li></ul><ul><li>Composable </li></ul><ul><li>Reusable </li></ul><ul><li>Complete </li></ul><ul><li>Non-duplicated </li></ul>
  26. 26. Helps realise SOA principles These principles as per Sprott [3]
  27. 27. AN APPROACH TO SPECIFYING A CBS
  28. 28. Specifying Conceptual Business Services <ul><li>This approach to specifying a CBS uses a meta-model and UML </li></ul><ul><li>The meta-model provides an overarching view of the elements that make up a service </li></ul><ul><li>It provides the connection through to the business reference model and alignment to strategy </li></ul>
  29. 29. CBS meta-model <ul><li>Meta-model provides overview of elements and relationships </li></ul><ul><li>Each of these elements is part of the specification </li></ul>
  30. 30. Potential CBS and Service Relationship <ul><li>Can build on other concepts (e.g. from CBDI Forum Service Architecture & Engineering meta-model for SOA) </li></ul><ul><li>Extension points: </li></ul><ul><ul><li>SERVICE PACKAGE::Service (notional) </li></ul></ul><ul><ul><li>SERVICE PACKAGE::Software Service </li></ul></ul><ul><ul><li>SERVICE PACKAGE:: Non-Software Service </li></ul></ul><ul><li>Relationship would usually conform to that expressed in the diagram </li></ul>
  31. 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. 32. Anatomy of a Conceptual Business Service
  33. 33. Example CBS specification
  34. 34. Example of operation detail
  35. 35. Business Context <ul><li>The business context package displays those contexts that the CBS may be used within. This is a combination of </li></ul><ul><ul><li>Brand </li></ul></ul><ul><ul><li>Channel </li></ul></ul><ul><ul><li>Region </li></ul></ul><ul><ul><li>Organisational unit </li></ul></ul><ul><ul><li>Process </li></ul></ul><ul><ul><li>Role </li></ul></ul><ul><li>Allows application of project requirements in many varieties </li></ul><ul><li>Defines the point of variation and captures the commonalities </li></ul>
  36. 36. Example Sequence Diagram Using CBS's
  37. 37. Example Service Information Model for a CBS
  38. 38. Example request message information model
  39. 39. Conclusion <ul><li>More emphasis needs to be placed on business interoperability now that technical interoperability is better understood </li></ul><ul><li>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 </li></ul><ul><li>When defining a CBS reliance is placed on the existence of a business reference model which includes a canonical information model </li></ul><ul><li>The CBS is a basis for a portfolio of business services </li></ul><ul><li>The portfolio is navigable and allows recognition of services that fulfill needs across the organisation. </li></ul>
  40. 40. Questions!
  41. 41. References <ul><li>[1] Alonso G., Casati F., Kuno H. and Machiraju V.; Web Services : Concepts, Architectures and Applications ; Springer-Verlag 2004 </li></ul><ul><li>[2] Erl T. SOA Principles of Service Design Prentice Hall PTR 2007 </li></ul><ul><li>[3] Sprott D. Service Architecture and Engineerin g CBDI Journal 2006 July/August Best Practice Report </li></ul><ul><li>http://www.cbdiforum.com/secure/interact/2006-07/serv_archi_eng.php 2006 </li></ul><ul><li>[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 </li></ul><ul><li>[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 </li></ul><ul><li>[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 </li></ul><ul><li>[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 </li></ul><ul><li>[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 </li></ul><ul><li>[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 </li></ul><ul><li>[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) </li></ul><ul><li>[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 </li></ul><ul><li>[12] Aoyama M. A Business-Driven Web Service Creation Methodology Proceedings of the 2002 Symposium on Applications and the Internet (SAINT.02w) IEEE 2002 </li></ul><ul><li>[13] Zachman J.A. A Framework for Information </li></ul><ul><li>Systems Architecture IBM Systems Journal 26, 3 </li></ul><ul><li>(1987), pp 276-292 </li></ul><ul><li>[14] Federal Enterprise Architecture Framework (FEAF) USA EGov http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html accessed 1 September 2008 </li></ul><ul><li>[15] TOGAF, The Open Group Architecture Framework, </li></ul><ul><li>http://www.opengroup.org/togaf/ accessed 1 September 2008 </li></ul><ul><li>[16] CBDI Forum Service Architecture & Engineering meta model for SOA </li></ul><ul><li>http://www.cbdiforum.com/public/meta_model_v2.php accessed 1 September 2008 </li></ul>

×