Socsig Frye Clohesy Presentation

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:

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

How long are we going to continue just cobbling packages together? Every organisation has the systems it deserves

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

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

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

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 .

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

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

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

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

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

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

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

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

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

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

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

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

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

Examples of Domains and Portfolios Domains and portfolios are used to organise and manage services Forms part of ‘scoring’ for a roadmap

Principles and Conceptual Business Services Coarse-grained Business aligned Well-defined Contract Loosely Coupled Discoverable Durable Composable Reusable Complete Non-duplicated

Helps realise SOA principles These principles as per Sprott [3]

AN APPROACH TO SPECIFYING A CBS

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

CBS meta-model Meta-model provides overview of elements and relationships Each of these elements is part of the specification

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

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

Anatomy of a Conceptual Business Service

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

Example Sequence Diagram Using CBS's

Example Service Information Model for a CBS

Example request message information model

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.

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

Socsig Frye Clohesy Presentation

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Socsig Frye Clohesy Presentation (20)

Recently uploaded (20)

Socsig Frye Clohesy Presentation

Editor's Notes