The document discusses leveraging a service-oriented and model-driven approach to enterprise architecture. It introduces key concepts like enterprise architecture, service-oriented architecture, and model-driven architecture. It provides an example of modeling a "Dealer Network" as a services architecture using these concepts.

1. Leveraging a Service-Oriented and Model-Driven Approach to Architecting Your Enterprise Ed Seidewitz 29 October 2009

2. The Issues Organizations run complex, critical software to support their business. Often, several critical software systems must work together to support this processing, but there may be no integrated view of the entire software architecture. Nevertheless, the entire architecture must evolve as necessary to meet both new business requirements (e.g., market changes, regulation changes, etc.) and new technical approaches (e.g., Web-based delivery, service-oriented architecture, etc.).

3. Addressing the Issues with Architecture Enterprise Architecture To ground technical solutions in the needs of the enterprise Service Oriented Architecture To provide a common paradigm for business, system and technical integration Model Driven Architecture To drive business requirements consistently to successful solutions Architecture Driven Modernization To transition effectively from the as-is to the to-be architectures

4. What is Architecture? Architecture as a Product “ A set of design artifacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change).” (John Zachman) Architecture as a Practice “ The practice of finding creative design solutions that meet the needs of the client, fit the environment in which they are to be deployed, and are feasible to implement.” Architecture provides the bridge between desires of the client and the capabilities of available technology.

5. What is Enterprise Architecture? Enterprise: A system of business endeavor within a particular business environment. 1 Enterprise Architecture: A design for the arrangement and interoperation of business components (e.g., policies, operations, infrastructure, information) that together make up the enterprise's means of operation. 1 1 Interoperability Clearinghouse Glossary, http://www.ichnet.org/glossary.htm This positions “EA” as the architecture of the enterprise, not a technology architecture

6. What is Service Oriented Architecture? Service: A logical representation of a repeatable business activity that has a specified outcome, is self-contained, may be composed of other services and is a “black box” to consumers of the service. 1 Service Oriented: A way of thinking in terms of services and service-based development and the outcomes of services. 1 Service Oriented Architecture: An architectural style for a community of providers and consumers of services to achieve mutual value, that: 2 Allows participants in the community to work together with minimal co-dependence or technology dependence Specifies the contracts to which organizations, people and technologies must adhere in order to participate in the community Provides for business value and business processes to be realized by the community Allows for a variety of technologies to be used to facilitate interactions within the community 1 The Open Group, SOA Definition v1.1, June 2006, http://www.theopengroup.org/projects/soa/doc.tpl?CALLER=doc.tpl&gdid=10632 2 Object Management Group, SOA SIG, Draft SOA Definition , April 2006

7. What is Model Driven Architecture (MDA)? Computation Independent Model (CIM) The business model Platform Independent Model (PIM) Technology independent logical system model Conforms to the business model (CIM) Platform Specific Model (PSM) Technology specific (e.g., middleware, application platform, etc.) system implementation Conforms to the logical system model (PIM) An (OMG) approach to system specification that separates (models for) the specification of functionality from the specification of the implementation of that functionality on a specific technology platform. Object Management Group (OMG) Terminology (as commonly applied)

8. What is a Model? A model is a set of statements in some modeling language made in order to describe or specify some system or domain. Standard modeling languages: Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), Systems Modeling Language (SysML), Service Oriented Architecture Modeling Language (SoaML), etc. Models are intended to represent and communicate the results of analyses and proposals for new syntheses. No model can represent everything – but, to be useful, a model must effectively promote general understanding and communicate important details. Typical kinds of models: Business process model Business information model System requirements model System design model Data model

9. What is Architecture Driven Modernization (ADM)? A process for understanding and evolving existing software assets Business Architecture (Business Model) System Architecture (Logical System Model) Technical Architecture / System Implementation MDA ADM

10. The Service Oriented Enterprise Think about the enterprise as a set of interacting participant roles providing and using services. This enables agility and an effective transition framework. Externally The enterprise is part of the global supply chain, providing services to customers and using the services of suppliers. Internally Consider parts of the enterprise as providing services to other parts of the enterprise, and in turn using the service of others. Internal services are just like external services, the services just happen to be done inside the organization. Business is modeled in terms of interacting roles – providing and using services – the essential concepts of business SOA.

11. Benefits Agile way to understand and plan the enterprise Oriented around business concepts of roles, responsibilities and services Allows business units the flexibility to define their own business processes (the way they will deliver a service) while supporting common business processes Allows business units the flexibility to buy or build their own supporting technology while supporting common components and shared services The business model drives the technology Smooth transition strategy, in terms of the business and the supporting technology Automation provides interoperable solutions quickly and with less cost

12. Example – The “Dealer Network” The dealer network models an “industry community” of dealers, shippers and manufacturers. The community defines the SOA architecture by which they all work together.

13. Service-Oriented, Model Driven Approach Business Concerns Technology Specification JEE, JMS, Web Services WSDL, BPEL, XML Schema… Logical System Model Technology Services (t-SOA), Components, Compositions Interfaces, Messages & Data Business Model Business Services (e-SOA) Roles, Collaborations & Interactions Process & Information

14. Focus on the Business Model Business Concerns Technology Specification JEE, JMS, Web Services WSDL, BPEL, XML Schema… Logical System Model Technology Services (t-SOA), Components, Compositions Interfaces, Messages & Data Business Model Business Services (e-SOA) Roles, Collaborations & Interactions Process & Information

15. The Dealer Network Order GetItThere Freight Shipper Acme Industries Manufacturer Mechanics Are Us Dealer A participant in the network The role played by the participant in the network An interaction between participants Confirmation

16. The Dealer Network Order Ship Req GetItThere Freight Shipper Acme Industries Manufacturer Mechanics Are Us Dealer A participant in the network The role played by the participant in the network An interaction between participants Confirmation

17. The Dealer Network Order Confirmation Shipped Ship Req Shipped Status GetItThere Freight Shipper Acme Industries Manufacturer Mechanics Are Us Dealer A participant in the network The role played by the participant in the network An interaction between participants

18. The Dealer Network Order Confirmation Shipped Ship Req Shipped Delivered Status GetItThere Freight Shipper Acme Industries Manufacturer Mechanics Are Us Dealer A participant in the network The role played by the participant in the network An interaction between participants Physical Delivery

19. Marketplace Services Status Order Confirmation Shipped Shipper (Provider) Requester (Consumer) Vendor (Provider) Orderer (Consumer) Recipient (Consumer) Shipper (Provider) GetItThere Freight Shipper Mechanics Are Us Dealer Acme Industries Manufacturer The role played by the participant for a specific service A service contract grouping the interactions required for providing a specific service Ship Req Shipped Delivered Physical Delivery

20. Fundamental SOA Concepts Participant – A specification of the responsibility to perform specific functions in the context of a business process. Services Architecture – A set of two or more participants interacting to carry out a business process to achieve some joint purpose. Service Contract – A collaboration that defines a conversation in which a service or services is provided to consumers by providers. This conversation may be extended over time (i.e., responses of one participant to the other may not be immediate).

21. SOA Modeling Language (SoaML) SoaML is an OMG standard profile of the Unified Modeling Language (UML). It adapts best-practice UML modeling techniques for the specific purpose of modeling service-oriented architectures. SOA Concept UML Modeling Technique Services Architecture (SOA)  Collaboration Participant  Collaboration Role Service Contract  Collaboration/Interaction Service Use  Collaboration Use But all the rest of UML is still available to use as appropriate.

22. Services Architecture for the Dealer Network A Services Architecture (or SOA) is a network of participant roles providing and consuming services to fulfill a purpose. The services architecture defines the requirements for the types of participants and services that fulfill those roles. Shipping service Delivery service Ordering service Manufacturer Participant – provides and consumes services Dealer Participant – provides and consumes services Shipper Participant – provides services

23. “ Place Order” Service Contract: High Level View This view of a service contract only identifies the service name and the roles each participant plays in the service. This is a high-level summary view. A service contract is the specification of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will flow between them. It specifies the service without regard for realization, capabilities or implementation. The orderer role (the consumer) and its Order Placer interface The vendor role (the provider) and its Order Taker interface

24. “Place Order” Service Choreography An optional interaction to request a quote A reply to return the quote A required interaction to place an order A reply to accept or reject the order This is a more detailed look at the same service. Note that this models a fully asynchronous interaction – like most business interactions. (The interaction message types are detailed later.) A second reply to confirm shipment

25. Drilling down - Inside a Manufacturer Order Confirmation Shipped Ship Req Shipped Delivered Fulfillment Production Accounting Acme Industries Not every manufacturer is going to be the same inside – this shows some of the internals of “Acme”

26. Services Architecture Inside of Acme This shows a “drill down” of the services architecture inside of a particular manufacturer, Acme. Other manufactures may have different internal architectures and processes. The Acme architecture realizes the Dealer Network participant role. This participant is within the Acme organization. This participant (from the Dealer Network architecture) is external to Acme

27. Acme Manufacturing Business Process A business process represents the desired behavior among the various participants in a services architecture. Each participant is given a swimlane containing the actions carried out by that participant within the business process. Interactions between participants must be consistent with their service contracts. (Note: for simplicity, the optional “quote” interaction is not shown here.)

28. “Place Order” Message Types This is the detail for the message types that correspond to the interactions for the Place Order service. Note that at the technology level this model can be used to produce the implementation specification of the messages, e.g., XML schema. The messages passed between roles in a service contract are specified using message types.

29. Customer Order Information Model An information model is a model of individually identifiable business entities and relevant information about them.

30. Linking Messages to Business Information Messages can reference and include parts of the logical information model – forming a connection between SOA and enterprise data.

31. Producing the Logical Systems Model Business Concerns Technology Specification Web Services, JEE, .NET WSDL, BPEL, XML Schema… Logical System Model Technology Services (t-SOA), Components & Compositions Interfaces, Messages & Data Business Model Business Services (e-SOA) Roles, Collaborations & Interactions Process, Information & Rules

32. Interfaces for Participant Roles These interfaces will correspond with parts of WSDL in a web services implementation. Each role in the service that receives interactions has an interface . This is the interface for a logical technology component and is implemented by components providing or using this service. The service is bi-directional – messages flow in both directions – so there is an interface on each side.

33. Service Interfaces on Participants Ports on the participants provide and require the service interfaces for each service provided or consumed Service contracts imply service interfaces on participants Participants and services may be used in multiple architectures.

34. Service Interfaces on Participants Service contracts imply service interfaces on participants Participants and services may be used in multiple architectures. Ports on the participants provide and require the service interfaces for each service provided or consumed Provided interface Required interface “ Conjugated” interfaces

35. Logical System Components Components implement the service interfaces providing the link to systems. A component may realize a services architecture.

36. Composite Application Components Components can be assembled from other components by linking their services. This corresponds to the architecture for Acme. Ideally, IT components directly play the roles of SOA participants. This component is defined as a composition of other components. This is a service delegation to an internal subcomponent. This is a service channel connection between a consumer and a provider.

37. Legacy Application Architecture In reality, the legacy architecture of most enterprises often does not reflect the business service architecture clearly. Participant roles are played primarily by human workers using ad-hoc IT interfaces. A request point is a port that is used to request services provided by a corresponding service point. Human participants may also interact without the aid of IT.

38. Acme Order Processing: Initial Service Implementation This is Acme’s initial pilot service-oriented solution architecture. Existing enterprise systems can be integrated using adapter components This new component provides full back-end support for fulfillment. The new component uses back-end service interfaces directly based on the business services architecture.

39. Adapting Enterprise Systems This is the inside of the SAP AR component – also a composition, it uses the existing SAP interfaces and adapts them to the service contract. This separates the concerns of a particular enterprise system from the enterprise SOA. Sometimes the system interfaces are used directly or adapted by an Enterprise Service Bus (ESB).

40. Acme Order Processing: Re-Architected Service Implementation Acme next decides to implement a new Fulfillment Component, with external service interfaces, while continuing to use adapter interfaces to back-end AR and Inventory Management systems.

41. Provisioning Technology Artifacts Business Concerns Technology Specification JEE, JMS, Web Services, .NET WSDL, BPEL, XML Schema Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data Business Model Business Services (b-SOA) Roles, Collaborations & Interactions Process, Rules & Information

42. How Do You Implement a Service Oriented Enterprise? “Implementing” the Service Oriented Enterprise can mean several things: Re-engineering enterprise business processes to a target service-oriented business architecture. Re-aligning enterprise organization for service delivery. Establishing effective IT support for enterprise business services An Enterprise Service Implementation Platform provides a consistent set of IT technologies for implementing a Service Oriented Enterprise. By wrapping and adapting existing systems By creating new applications Using “code free” configuration

43. Enterprise Service Implementation Platform: Solution Approach Service Delivery Service Orchestration & Workflow Solution Architecture Business Process Management (BPM) Business Rule Management Enterprise Service Bus (ESB) User Interface/Portal Persistence/Database Model/Metadata Repository Provisioning Service Operations & Governance Service Registry Operational Monitoring Performance Instrumentation

44. Standards in the Web Services Stack Source: SUN, 2007

45. Example Provisioning to JEE Web Services How SoaML is provisioned to technology artifacts, such as Web Services, is not yet standard. This illustrates one approach. The components to be provisioned are dropped into a technology specific provisioning node (in this case JEE and web services).

46. Custom Business Logic Components Application Framework Generated Component Wrapper Custom Code Framework Component Application components provide service implementations with user supplied logic. These “plug into” the users architecture as composite application components Framework components add infrastructural capabilities by extending the platform (E.G. JBI) and are called by the provisioned code or platform configuration XSLT Java Etc. As MDA progresses, there will be less and less need for custom components, but the capability will remain. Custom part is separate from the generated part

47. Model-Driven Development Using a standard-conforming UML modeling tool With custom business logic components Developers write the custom logic code Technologists specify the implementation platform The models are provisioned onto the target platform Architects create the models

48. Model Driven Development With fully executable models Using a standard-conforming UML modeling tool Using a standard-conforming UML execution tool The models are the source code. Analysts validate the models by executing them in a simulated test environment Technologists specify the implementation platform The models are provisioned as executing artifacts on the target platform Architects create the models

49. Conclusion Architecture builds bridges from business needs to solution design to successful implementation. The concept of a service provides a common basis for tying business to system to technical architecture. Business service System service Technical (Web) service Models provide the basis for description, specification and communication at all levels. Provisioning enables models to be the source for executable artifacts. Executable architecture models Executable business process models Executable system models

50. Relevant OMG Standards OMG Model Driven Architecture http://www.omg.org/mda/ - See http://www.omg.org/cgi-bin/doc?omg/03-06-01 for MDA Guide OMG Unified Modeling Language (OMG UML) Superstructure , Version 2.2 (formal/2009-02-02) www.uml.org Service Oriented Architecture Modeling Language (SoaML) , Beta 1 (ptc/2009-04-01) www.soaml.org See http:// www.omg.org /spec/SoaML/Current for latest spec doc Semantics of a Foundational Subset for Executable UML Models , Beta 1 (ptc/2008-11-03) See http:// www.omg.org /spec/FUML/Current for latest spec doc In progress: Concrete Syntax for UML Action Language, Request for Proposals (ad/2008-09-09) See http://www.omg.org/cgi-bin/doc?ad/2008-9-9 for RFP

51. Relevant Tools Open Source ModelPro Provisioning Engine – http://modelpro.modeldriven.org ModelPro SoaML Cartridge – http://soamlcartridge.modeldriven.org fUML Reference Implementation – http://fuml.modeldriven.org Commercial MagicDraw/Cameo-SOA+ – http:// soaplus.cameosuite.com IBM Rational Software Architect 7.5.4 – http://www-01.ibm.com/support/docview.wss?rs=3539&uid=swg27014043