© Boris Lublinsky, Michael Rosen 2008 SOA Architecture and Design Strategies Boris Lublinsky, NAVTEQ. Mike Rosen, Wilton Consulting Group Copyright is held by the author/owner(s). OOPSLA 2008, October 19–23, 2008, Nashville, Tennessee, USA. ACM /08/10.

© Boris Lublinsky, Michael Rosen 2008 Slide 2 SOA Governance SOA Governance is not optional – Its imperative Paolo Malinverno

© Boris Lublinsky, Michael Rosen 2008 Slide 3 What is SOA Governance? n SOA governance is the creation, communication, enforcement, and adaptation of policies used to direct and control the life cycle of services, including their design, implementation, deployment, usage, versioning and deprecation. It is both design-time and run-time administrative capability that no organization trying to implement SOA should be without. n Simply put, governance sets policies in place, and provides the mechanism to enforce them. n Governance itself is not a process that is unique to SOA - it can be applied to any business domain used to accomplish business objectives. n SOA governance does have some unique characteristics, different from those of general governance, as it applies to the service life cycle n SOA governance is necessary for providing guidance and keeping things in order, thus increasing the chances of SOA implementation success

© Boris Lublinsky, Michael Rosen 2008 Slide 4 Responsibilities of Governance Group n Position SOA as a critical element of IT tool set and align it with the Enterprise Business strategy. Define business opportunities for SOA adoption and implementation. n Create clear ownership, supervision, and escalation of SOA specific issues, thus providing quick and efficient resolution of SOA-related issues. n Define SOA funding approaches, including reuse charge backs, and so on. n Enable SOA maturity tracking and its controlled evolution based on the metrics for SOA adoption benefits, services reuse, and so on. n Align SOA strategy with other enterprise strategies, including security, presentation, portfolio management, and so on. n Ensure adherence to service definition and implementation policies and processes. n Ensure infrastructure readiness for SOA n Maintain and advertise major SOA artifacts—services, business processes, and so on.

© Boris Lublinsky, Michael Rosen 2008 Slide 5 SOA Governance Phases n Design-Time Governance refers to the defining and controlling creation of the enterprise services. It involves creation of enterprise policies used to ensure that they directly support enterprise business model and are properly funded within the enterprise n Deploy-Time Governance involves the process of testing and controlling compliance to enterprise policies in order for services to be deployed. It involves creation of deployment options and topologies, and ensures that all services are properly deployed in the enterprise SOA environment. n Run-Time Governance refers to the process of enforcing the adherence to run- time service policies. In addition to policy enforcement, this term is often used to include aspects of SOA management as it relates to these policies and to include real-time policy compliance monitoring, auditing, and measuring and collecting result statistics. n Change-Time Governance involves managing services through their cycle. Change-time governance focuses on such issues as service versioning, deprecation, and run-time policy adaptation. Governance tools can be used to achieve such strategies as adding service intermediaries to intercept messages and route them to the appropriate previous versions of services.

© Boris Lublinsky, Michael Rosen 2008 Slide 6 SOA Governance Lifecycle

© Boris Lublinsky, Michael Rosen 2008 Slide 7 SOA Governance Stakeholders n Solution Lead — A business architect tasked with solving a particular business problem. This stakeholder’s responsibilities mostly revolve around the translation of business requirements into a service proposal. n Functional Architect — An architect who maintains and enhances an enterprise functional model. He or she maintains enterprise business model and messaging dictionary (semantic messaging) that ensures interoperability between enterprise services. n Portfolio Architect — An architect managing an application portfolio that includes services, this stakeholder ensures that services are aligned with the directions for a particular portfolio. He or she also maintains the business relationships with business units, as well as other portfolios. Finally, he or she serves as a Subject Matter Expert on the existing functionality of the applications within the portfolio. n Enterprise Architect — This stakeholder plays a pivotal role in service identification and design. He or she is responsible for making sure that each service fits into the overall enterprise context. In addition, the architect is responsible for the integration approaches and adapter designs. The architect chooses appropriate implementation platforms for services and is responsible for nonfunctional requirements for services and their implementation. n Business Process Architect — An architect managing enterprise business processes and their evolution, he or she works closely with the functional architect, ensuring the alignment of services with the current and future business processes.

© Boris Lublinsky, Michael Rosen 2008 Slide 8 Governance Stakeholders (continued) n Services Librarian — A person responsible for maintenance of the service registry, a backbone of service governance. This stakeholder works to ensure that all of the service information is in a standardized form, accurate, up-to- date, and properly classified. n SOA Runtime Architect — An architect responsible for maintenance of and enhancements to the service run time, including standardization of services APIs, and services run-time support—registry, monitoring, and so on. n Application Developer — This stakeholder is a developer building and maintaining business functionality for base services. n Services Assembler — The developer building and maintaining business functionality for composite services (business processes). n Service Tester — A quality assurance (QA) representative responsible for testing of the services. n Services Infrastructure Specialist — An infrastructure engineer responsible for the creation of the services deployment diagrams and topologies, and maintenance of the services registry and service management solution. He or she also monitors services usage and SLA adherence.

© Boris Lublinsky, Michael Rosen 2008 Slide 9 Service Identification This process is dictated by the SOA governance group, and it is driven off of the functional (business) model, process definition, and semantic information model, resulting in a proposal for a new service.

© Boris Lublinsky, Michael Rosen 2008 Slide 10 Service Design and Specification A key aspect of the design process involves the use of the service repository, reviewing and updating the semantic information and functional models, and placing the resulting design in the repository. The design itself includes service interface as well as run-time service policies.

© Boris Lublinsky, Michael Rosen 2008 Slide 11 Service Implementation Each service implementation differs and depends on the service type. A set of standards, guidance, blueprints, and best practices for implementing different service types, established by the governance team, has to cover all of the possible cases.

© Boris Lublinsky, Michael Rosen 2008 Slide 12 Service Deployment Service deployment includes the configuration of the deployment of the individual service instance and the topology for multiple instance design, where multiple instances of services are deployed simultaneously to support load-balancing and fail–over and/or multiple run- time service policies. It also includes definitions of services access transports (for example, messaging vs. HTTP) and interaction styles supported by different deployment instances. Deployment information is used for updating the service registry, service monitoring solution and service repository.

© Boris Lublinsky, Michael Rosen 2008 Slide 13 Service Usage All services are monitored and their execution/utilization statistic is gathered so that results can be analyzed for troubleshooting, policy enhancements, deployment topology changes, capacity planning and other potential enhancements and changes. All activity, exceptions and errors are logged in such a way that the enterprise managers can have a “big picture” view of the SOA functioning

© Boris Lublinsky, Michael Rosen 2008 Slide 14 Service Retirement Service retiring encompasses not only the undeployment of the service run time instance(s), but also removal of the service information from the registry (thus ensuring that it will be never invoked) along with removal of the service information from the services’ monitoring/management solution and archiving service information in repository.

© Boris Lublinsky, Michael Rosen 2008 Slide 15 Acknowledgements n To our coauthors – Kevin T. Smith and Marc J. Balcer. n Numerous people for fruitful discussions on what SOA is and what it is not and how to design it better.

© Boris Lublinsky, Michael Rosen 2008 Slide 16 Thank You! “Every complex problem has a solution that is clear, simple…and wrong” — H.L. Mencken, 1949