Engineering Lessons For Systems Of Systems Learned From .

Lessons Learned fromService-Oriented Systems forEngineering Systems ofSystemsSoftware Engineering InstituteCarnegie Mellon UniversityGrace A. Lewis (glewis@sei.cmu.edu)SATURN 2010May 20, 2010 2010 Carnegie Mellon University

AgendaService Orientation and Systems of SystemsWhat Has Worked Well in SOA ImplementationsWhat Does Not Yet Work Well in SOA ImplementationsFinal ThoughtsSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University2

Service OrientationService orientation has become a common approach for implementationof distributed, loosely-coupled systems Services provide reusable business functionality via well-defined interfaces. Service consumers are built using functionality from available services. There is a clear separation between service interface and serviceimplementation.– Service interface is just as important as service implementation. An SOA infrastructure enables discovery, composition, and invocation ofservices. Protocols are predominantly, but not exclusively, message-based documentexchanges.SATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University3

Components of a Service-Oriented SystemEnd rServiceConsumersSOA ceDServiceInterfacesEnterpriseInformation SystemInternal UsersLegacy or NewService CodeExternalSystemServiceImplementationSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University4

Benefits Associated with ServiceOrientationCost-Efficiency Services provide functionality that can be reused many times by manyconsumers Services become a single point of maintenance and management forcommon functionalityAgility Via service discovery mechanisms, developers can find and take advantageof existing services to reduce development timesLegacy Leverage Separation of service interface from service implementation provides trueplatform independenceAdaptability Separation of service interface from service implementation allows forincremental deployment of services and incremental modernizationSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University5

System of Systems (SoS)A System of Systems is “a set or arrangement of systems that resultswhen independent and useful systems are integrated into a largersystem that delivers unique capabilities.”** OSD Systems Engineering GuideSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University6

Notional View of a Service-Oriented SoSSoSConsumerAConsumerBConsumerN Characteristics of SoS* Evolutionary development Emerging behaviorSoS InfrastructureServiceAServiceBServiceC ServiceDCharacteristics of ConstituentSystems* Operational independenceSystemASystem BSystemN Managerial independence Geographic distribution* Maier, M. (1998), "Architecting Principles for Systems-of-Systems," Systems Engineering, Vol. 1, No. 4 (pp. 267-284)SATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University7

SOA is One Implementation Technology forSoSSystems ofSystemsimplemented vent-DrivenArchitectureCloudSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University?8

What Can We Learn from SOA Implementations?Are there SOAbest practices thatcan be useful forother types ofsoftware-reliantSoS?Systems ofSystemsRequirementsEngineeringArchitecture andDesignTesting andVerificationtest practices onService-OrientedArchitecture abstract best practices from TURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University9

AgendaService Orientation and Systems of SystemsWhat Has Worked Well in SOA ImplementationsWhat Does Not Yet Work Well in SOA ImplementationsFinal ThoughtsSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University10

What Are Some Things That Have Worked Wellin SOA Implementations?StandardizationLoose couplingStrategic service identificationService discovery mechanismsGovernanceSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University11

StandardizationEven though there are multiple ways toimplement service-oriented systems, themost common implementation is based onWS* Web ServicesBenefits Interoperability: standard interfaces toheterogeneous technologies Tool support Enablement of other aspects of serviceoriented systems: discovery, composition,etc Usage of third-party services Potential for shorter development times– All you need to know to use a service isthereSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University12

Standardization: How Does this Bridge to SoS?Bottom Line: Some level of standardization is necessary A very controversial topic in many SoS settingsBenefits for SoS Encapsulation of complexity and heterogeneity of constituent systems– Operational independence– Managerial independence– Geographic distribution Greater tool support Enablement of interface-based testingSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University13

Strategic Service IdentificationService identification is done in the problem domain Based on the premise that what changes is business and not the technology Starts from business goals for SOA adoption– Top-Down: Identification of business processes that support businessgoals– Bottom-Up: Identification of legacy capabilities that support business goalsServices represent reusable business capabilities Leads to greater and easier reuseTarget of service identification techniques is low coupling and highcohesion of service capabilities Also related to stateless nature of servicesSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University14

Strategic Service Identification: How Does ThisBridge to SoS?What is done to identify services can be done to identify capabilities Business processes map to SoS usage scenarios Services map to individual system capabilitiesAdvantage is that individual systems already have high cohesion andlow coupling At least from a consumer perspectiveSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University15

Loose CouplingDifferent architectural patterns emphasize different forms of loosecoupling — however, there is always some form of coupling Data centric — data model Event driven — events and event mechanism Service orientation — interfaces and communication mechanismsTwo forms of loose coupling in service orientation Between provider and consumer– Service provider and consumer know as little as possible about each other– SOA infrastructure mediates a lot of the differences between providers andconsumers– SOA infrastructure also provides centralization of support for key qualityattributes Between interface and implementation– Service location– Service implementation technologiesSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University16

Loose Coupling: How Does this Bridge to SoS?Hide technology of constituent systems Technology should not bleed through system interfaces, e.g. obfuscation oferror messagesProvide integration mechanisms that are technology-neutral, e.g. XMLProvide an infrastructure to mediate differences between constituentsystems, e.g. the ESB VETRO patternSource: Dave Chappell, "Enterprise Service Bus" (O’Reilly: June 2004, ISBN 0-596-00675-6)SATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University17

Service DiscoveryIn a service-oriented environment, as services are created they arepublished in a place that is accessible to consumers and can be queriedfor desired capabilities, e.g. service registry, web page, directorySome environments have service repositories with additional servicemetadata that can be used to identify desired capabilities Specification (Contract) — minimum required informationDescriptionClassificationUsage historyTest caseTest resultsQuality metricsDocumentationSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University18

Service Discovery: How Does This Bridge toSoS?Consider having a capability repository There is considerable tool support that can be leveraged Include in it everything that is needed to reuse a capability — minimizesinteraction between developers and therefore promotes agilityMetadata should be published along with the capability, not only to helpwith the discovery process, but also to know how to use that capabilityonce it is discovered Quality attributes, e.g., performance limitations Assumptions, e.g., encryption mechanisms Constraints, e.g., usage contextKeep in mind that system-capabilities-as-a-service is another “quantumleap” in granularitySATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University19

GovernanceSOA Governance is the set of policies, rules, and enforcementmechanisms for developing, using, and evolving service-orientedsystems, and for analysis of the business value of those systems Design-time governance Runtime governance Change-time governanceSOA Governance was created to solve a problem created by SOA Way to add control and enforce consistencyMany (but not all) aspects of SOA governance can be automated andembedded in the SOA infrastructure, e.g. Execution of services according to policies Runtime logging and monitoringSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University20

Governance: How Does This Bridge to SoS?Something similar to SOA Governance is necessary to provideagreement on aspects such as Characteristics of central registryDesign-time, runtime and change-time policiesService Level Agreements (SLAs)Tool supportDue to the independent nature of constituent systems, change-timegovernance is key to SoS How are problems in constituent systems reported?What happens if a constituent system changes?How are changes and upgrades in constituent systems communicated?How will capabilities of constituent services be tested?SATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University21

AgendaService Orientation and Systems of SystemsWhat Has Worked Well in SOA ImplementationsWhat Does Not Yet Work Well in SOA ImplementationsFinal ThoughtsSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University22

Things That Have Not Been Solved in the SOAWorld 1Multi-organizational SOA implementations, e.g. Distributed development tasks, e.g. assurance Multi-organizational concerns, e.g. trust, federation, securityStandardization on how to specify quality attributes Key for service discovery and SLA management and monitoringSupport for interoperability at higher levels Above syntactic: semantic and process interoperabilityAutomation of service discovery Many efforts, but still not widely usedSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University23

Things That Have Not Been Solved in the SOAWorld 2Many aspects of SOA governance cannot be automated As stated by AgilePath: “Governance is behavior (90%), not technology(10%)” Makes it difficult to enforceUntil these things are solved, it will be difficult to build virtual SoS wherecapabilities are identified and invoked on the flySATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University24

AgendaService Orientation and Systems of SystemsWhat Has Worked Well in SOA ImplementationsWhat Does Not Yet Work Well in SOA ImplementationsFinal ThoughtsSATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University25

SoS Types 1Maier defines four types of SoS based on their management structure* Directed: the systems are integrated and built to fulfill specific purposes Acknowledged: SoS has recognized objectives, a designated manager, andresources Collaborative: constituents voluntarily agree to fulfill central purposes Virtual: no central authority or centrally agreed purposeCurrent technologies used in service-oriented systems can supportdirected and acknowledged SoS Requirements of collaborative and virtual SoS are beyond technology* Maier, M. (1998), "Architecting Principles for Systems-of-Systems," Systems Engineering, Vol. 1, No. 4 (pp. 267-284)SATURN 2010 – SOA and SoSMay 20, 2010 2010 Carnegie Mellon University26