Achieving Organization Agility Through a Service Oriented Architecture (OA-SOA)

1. Achieving Organization Agility Through a Service Oriented Architecture (OA-SOA) Bridging the Gap Between Business Operations and the IT Automation which Supports It Thomas Pole, Harris Corp.tpole@Harris.com

2. Logistics • You will need 2 Number 2 pencils • Sound familiar? Yes there will be an quiz. • We will need access to a copy machine • Schedule/Breaks, appoximate • 12:00 - Noon start • 12:45-12:50 - 5 minute break • 1:25 - Break to have your work sheets copied • 1:30 - Exercising Organization Agility • 1:45 - Stop time

3. Abstract • Efficiently run enterprises have well defined, repeatable business processes, and employ IT systems to automate some or most of the tasks required to follow those processes. In reaction to changes in their operational and technology environments, as well as to improve their efficiency, enterprises must adapt to change and evolve their processes. In turn the automation which supports those evolving processes must also change to be kept in synch with those processes; which can be costly, time-consuming, and can introduce significant risk. • This tutorial on Organizational Agility through SOA will concentrate on how to use an SOA to bridge the gap between an enterprise’s business processes and the automation systems which support them, in order to minimize the effort and the risk in keeping evolving business processes and their supporting automation in synch.

4. Outline I. Goals of Tutorial II Introduction of Concepts - defining the terms and concepts as they will be used for the day's presentation, not necessarily proposing industry standards definitions III. Organizational Agility: what, why and how IV. Three Part Diagram Model: Business Process, SOA Interface/Integration, Software and IT Infrastructure V. Example of an Instance of the Three Part Diagram: Administration and Collaboration Processes for a Part Time Graduate University Program VI. Applying the OA through SOA Method, Step by Step VII. Student Exercise in the OA through SOA Method VIII. Self Evaluation of Exercise IX. Summing Up and Where to go for more information, including shameless self promotion of the Johns-Hopkins Software Engineering and Architecture programs

5. I. Goals of this Tutorial • Set the scope of this topic within the larger topics of SOA, BPR, and Information System development, sustainment and maintenance. • Present a method, a tool which can be used to achieve organizational agility for an enterprise, through the adoption of an SOA as a bridge between business operations and IT systems which automate all or parts of those operational processes.

6. II. Introduction of Concepts • Concepts and Definitions • Goal: Maximize our time today by minimizing semantic ambiguities • Coming to a common understanding on what we mean when we use specific terms • Our focus is on IT support of business processes, and keeping automating and business process in synch • This is a business process oriented view point • Definitions are not meant to be universal, but useful to reduce ambiguity, today, now, for this discussion

7. Concept Definitions • Object Oriented • Software design based upon modules which are objects, logical collections of both function and state, which employ well-defined interfaces to achieve information hiding and abstraction • Distributable or Distributed Objects • Software design based upon “object like” modules which are dynamically compilable and autonomously executable (e.g. CORBA, DCOM) • Service • A module of an automation system, the scope of which is a complete biz process, or process step of a business process for which it supplies automation support • Web Service • A distributed component which publishes its interface in an operating system and programming language agnostic protocol, and uses a stateless message based inter-process communication medium; one implementation method for services • Service Oriented Architecture • An IT architecture which integrate services to implement the automation to support the business processes it automates • Organizational Agility • The ability of an organization to change its processes in reaction to influences both internal and external, and change the automation which supports those processes as a nearly simultaneous activity • More to come (e.g. BPR)

8. III. Organization Agility • What is it? • Why do we think it’s a good idea? • What problem(s) does it solve and/or what advantages does it offer? • How do we achieve it? • We’ll present one way, not the only way to achieve this.

9. Organizational Agility: What? • Start with our definition • The ability of an organization to change its processes in reaction to influences both internal and external, and likewise change the automation which supports those processes as a nearly simultaneous activity • Categories of change • Business process improvement efforts • Market or business domain changes • Technology changes that enable or drive business process changes

10. Organizational Agility: Why? • Because business is about competition, and processes define (among other things) how we compete • They change because they often need to • “Constant process improvement” • Changing processes without changing supporting automation means trouble, as we must choose: • To ignore the process change • To do without automation support • To reengineer the IT automation to support the changed processes • Reengineering IT systems or replacing them is expensive, and takes calendar time, delaying implementation of process improvement • His problem is not a new discovery, but current methods for keeping BPR and IT projects in synch have not solved the problem of developing Agile Organizations.

11. Types of Process Change, Based on their Source What causes change, and must the reaction to change be different based on the type? • Business Process Reengineering (BPR) • Business Domain/Market change • Mergers and acquisitions • Merging the processes of two similar organizations • Tech platform change (e.g. OS or other COTS changes behavior)

12. Warning: What Executives Do NOT Want to Hear After the BPR • Hey, great new business processes! • Spend N months and/or years accomplishing that BPR project, huh? • Well, that’s just great, in about 18 months we’ll have changed the IT systems to match all the business process changes you’ve just made • Just one thing, during the next 18 months make sure you don’t change anything else or we’ll have to start our system reengineering and system replacement projects all over again

13. Organizational Agility: How? • Well, that’s really the remainder of this presentation….. • Capture in a semi-formal, non-ambiguous form the organization’s business processes • Perform a functional analysis, and define OOD style interfaces for the underlying application which supply the functionality that supports and automates all or part of those processes • Define a SOA which represents the business entities and process steps in the business processes which are automated by the underlying applications, as services and service operations. • Explicitly identify the linkage between the business process steps and the SOA operations which automates them • Explicitly identify the linkage between the service operations and application interfaces which supply the underlying functionality to implement those operations • In the future, as business process change, update the automation by: 6.1 First attempt to synch process changes to automation by reusing and reordering existing SOA services and operations 6.2 If necessary, define new operations, or even new services and their operations that are implemented by reuse of existing applications 6.3 If necessary, define new application functionality or even new applications

14. IV. Three Part Diagram Model • The Result: the Three Part Diagram • The Business Process Layer • The SOA Interface Layer (or at least a part of it) • The Software Application Layer • The Model • Top layer: Semi-formal definition of business processes, either as is or to be, or both • Bottom layer: OOD style interfaces of applications which supply the underlying functionality to support the business processes • Middle layer: Definition of SOA layer which links and relates, in a loose coupling the business processes to the automation which support them • The Method: One option among several

15. Generic Three Part OA-SOA Diagram

16. V. Example: Purchase Order Process • A company receives purchase orders (PO) from a regular customer. • When they are received, they check to make sure that the PO form is complete according to the common business rules these B2B partners have agreed to. • If the PO format is correct, it is passed on to the marketing department for processing, which in turn: • Determines if all the items on the PO are in inventory, • ..and price the PO according to the rules appropriate for the items ordered, and the relationship this supplier has with the customer. • If it is not in the correct form, it is transformed into the correct XML based form, • …validated • …and, if needed, completed, • …and then passed on for processing.

17. 1 Capture Business Processes • Capture in a semi-formal, non-ambiguous form the organization’s business processes • Both narrative and graphical forms should be created, each has its strengths • Narrative form needs to be in a “recipe” form • List the ingredients (aka data and resources) • Identify in order, the step by step processes • The narrative will be a describe what the diagram depicts

18. 2. Capture/Create Application Interfaces • Perform a functional analysis, and define OOD style interfaces for the underlying application which supply the functionality that supports and automates all or part of those processes • OOD/OOP are still legitimate methods for the implementation of applications which support the SOA • All legacy apps which are not, should be “wrapped” with interfaces (e.g. API’s) using the appropriate protocols • The existing legacy design artifacts may need to be updated

19. 3. Define SOA Bridge • Define a SOA which represents the business entities and process steps in the business processes which are automated by the underlying applications, as services and service operations. • We focus on task centric business oriented services • Entity centric business oriented services, control services (e.g. orchestrations) and utility services (e.g. service wrappers around legacy functionality) are important too; but beyond the scope of this presentation. • Operations represent specific process steps, and services either collections of related operations, or operations on common data, or a common part of the information model

20. 4. Link Processes to SOA • Explicitly identify the linkage between the business process steps and the SOA operations which automates them • At this point, your three part diagram is partially complete, layers done, but not linked • Define in the 3-part diagram, the logical links, the relationships between the business process steps (top level), and their relative service operations (middle level)

21. 5. Link SOA to Application Interfaces • Explicitly identify the linkage between the service operations and application interfaces which supply the underlying functionality to implement those operations • Define in the 3-part diagram the relationship between each service operation and the (probably multiple) functions/methods in the application layer which supply the underlying functionality and state which implement those operations • Your 3-part diagram is complete • There will be one diagram per business process

22. 6. React to Change • In the future, as business process change, update the automation by: • Updating the business process diagrams (top level) to reflect the change • Take note of new process steps and business entities • Trace process changes to SOA, not where changes affect SOA • In most significant process change, some application level engineering will be required

23. 6.1 Reuse SOA Services and Operations • First attempt to synch process changes to automation by reusing and reordering existing SOA services and operations • In some cases, an implicit reordering of the orchestration (controlled sequence) of operations will be a sufficient update • Sometimes, an operation used by other process 3-parts can be reused to satisfy the change • Only the design artifacts (e.g. 3-part diagrams) and any automation of the 3-part diagram (e.g. use of BPEL orchestration) need to be updated

24. 6.2 Reuse Application Functionality • If necessary, define new operations, or even new services and their operations that are implemented by reuse of existing applications • In most cases, a new operation, or update of an operations occurs; a new service might be defined, and the underlying application functionality is not linked to the SOA • Existing application functionality must be exposed through the API, and operation(s) linked to those API features through the 3-part diagram

25. 6.3 Reengineer Application Functionality • If necessary, define new application functionality or even new applications • In some cases, the existing services and operations in the SOA can’t satisfy the updated business processes and existing applications do not supply the required functionality. • The application layer must be reengineered and/or new applications must be created • Then, the new application functionality must be linked to the SOA layer

26. Reverse Engineering • A required tool for any Architect implementing Organizational Agility through SOA • One SOA-OA becomes a enterprise wide standard policy, reverse and re-engineering may no longer be required • Reverse Engineering: • Working the system development life cycle in reverse: inferring the design from the implementation, or the requirements from the design • Reengineering: • (optionally) Reverse engineering a system, altering the earlier life cycle work product(s), forward engineering reusing all work products (design artifacts or source code) that are not affected by the change as is, changing or replacing work products that are affected by the change

27. Purchase Order 3-Part Diagram

28. VI & VII Exercising the Method • The method has been summarized above • In this exercise you will apply that method to another example problem

29. Exercise: Applying the Method • Work Sheets: • Defining the process • Narrative of process • Graphing the work flow • Capturing and (optionally) reengineering the automation support for the process • Creating the SOA bridge • Assembling the Three Part Diagram • Reacting to change with Organization Agility • Now: We will take copies of the next 5 ‘work sheet, WS:’ slides 30 thru 34 and set them aside for the exercise • WRITE YOUR NAME ON THE FRONT OF EACH WORKSHEET, IN THE CORNER ABOVE THE TITLE

30. (WS-1) Step 1a: Capture the Business Process - Narrative

31. (WS-2) Step 1b: Capture the Business Process - Graph

32. (WS-3) Step 2: Capture/Create Application Interfaces

33. (WS-4) Step 3: Define the SOA Bridge

34. (WS-5) Steps 4 and 5: Link Processes to SOA, SOA to Application Interfaces

35. Exercise Example – Process • Student signing up and being enrolled for a class in the engineering school at the world’s best graduate program for professionals, Johns-Hopkins University’s Whiting School of Engineering at the Applied Physics Laboratory • School processes the enrollment, for one class in this process definition • Make sure the class exists, there is an open seat, and the student has taken the prerequisite classes, is in the correct programs, etc.

36. Review: Steps in the Method • Step 1: Define the Business Process (BP) • Narrative: Probably already done by the operations staff or business executives • Create a semi-formal process definition, using flow chart symbology • Step 2: Capture the application layer, the software interfaces that make available the underlying functionality to automates all or part of the process • Capture and update design documentation of the legacy system(s) used • Add new automation features or systems that must be created • Step 3: Create the SOA to act as a bridge between the BP and the Applications • Services and their operations are in BP ‘speak’. Use the semantics of the problems to be solved, not the language of the solution. • If a term does not exit in the process narrative of this or some other process, then it should not exist in the names of services and their operations • Steps 4 and 5: Assemble the three part diagram • Explicit links between business process and SOA services and operations • Explicit links between SOA operations (NOT services but specific operations) and the interfaces to automation systems that implement the specific functionality that is needed to perform that operation

37. Step 1a: Defining the Process Narrative • In a hierarchical outline form, write a narrative describing the process • I. Step • A. Substep of Step I • B. Second Substep of Step I • Step II … etc. • Do NOT use “engineer speak” or “architect speak”, use the language of your systems end users

38. Step 1b: Graphing the Work Flow • Use the ‘usual’ pictorial forms for process step: , entity/thing , • start/end , and decision .

39. Step 2: The application interfaces • Use OO methods, usually • Do NOT force the application interfaces to reflect the SOA services on a 1 to 1 basis • Application layer is a decomposition of the system into components according to engineering principles • SOA layer is decomposed into services according to related business process and business entities

40. Step 3: Define the SOA Bridge • Explicitly reflects the tasks steps and entities (roles and information model objects) in the business processes • Do NOT force the SOA layer to reflect the application layer interfaces on a 1 to 1 basis

41. Step 4 & 5: Links Between Layers • Link process steps to SOA operations • Link SOA operations to the interfaces of application components which supply the underlying functionality that implements that operation.

42. Reacting to Change • Did we succeed? • Is your organization agile? • Does your SOA support agility? • Take your penciled ORIGNIAL work sheets to perform this exercise • We will take your work sheets and Xerox them. • React to the following process changes

43. (WS-5 copy) Step 6: Reacting to Change • Make these changes to the originals: • Before a class enrollment is completed, but after the student applies to enroll: • Instructor will be given students records to assure they have the background needed, classroom and/or work experience • Instructor either approves or identifies additional prep. Needed before student can enroll • If student is approved enroll student • If not, student receives “additional prep” • Student either submits additional work experience, etc. to show they have the background, or cancels app to enroll • If student resubmits additional work experience, etc. return to process step 1 • If not, cancel students app to enroll in this class

44. VIII. Evaluation of Exercise • How did it turn out? • Did your 3-part diagram require changes in the top layer? • They had better! • In the middle layer? • Again, they had better • In the bottom layer? • Probably • Links from layer 1 to layer 2? • Yes, especially to represent new process steps • Links from layer 2 to layer 3? • Probably

45. IX. Summing Up • Final question? • Final comments • My contact info: • Thomas Pole • tpole@Harris.com