Service Oriented Architectures (SOA): What Users Need to Know.

1. Service Oriented Architectures (SOA): What Users Need to Know. OGF 19: January 31, 2007 Charlotte, NC John Salasin, Ph.D, Visiting Researcher National Institute for Standards and Technology

2. Purpose(s) Of Workshop • Discuss “Predictive Metrics” that can help SOA system developers determine if project is “on track” • Discuss potential value of a metrology basis for SOAs • How could this be used to better inform design, development, acquisition, operation? • What are the measurement needs wrt: • Consistency supporting reuse • Match to business requirements • Policy / Security • Performance and Behavior • Total Cost of Ownership – Technical Aspects

3. Purpose(s) (of talk) • Introduce potential framework for SOA Predictive Metrics • The start of an ontology of metrics • Provide examples to stimulate Discussion

4. Outline of Talk • Claimed advantages of SOA-based systems • Objects of interest • System Components • Enterprise characteristics

5. Claimed advantages of SOA-based systems • Direct mapping between business processes and automated services • Understandability • Simplified reuse • Modifiability/co-evolution/adaptability • Rule/script-based modifications by business managers rather than system experts • Dynamic orchestration mapped to business work flow • Common interaction protocol(s) – often Grid Services • N rather than N x N interface protocols • Standard infrastructure tools/components (e.g., ESB) • Adaptable to heterogeneous platforms • Integrate separately developed “stovepipe” systems • Based on meta-data describing data and services • Enables “smart” systems • Selection of most appropriate process component • Automatic data transformations

6. System Components Business processes Service Components • Data • Procedures • Computation/transformation • Accept input (sensing / monitoring) • Business process execution • System health/status (?) • Rules/Policy (including security) • Change / evolution • Connectors / links/ configuration • Work flow / orchestration (and evolution) • System health/status (?) • Rules/Policy (including security) • Change / evolution

7. Enterprise Characteristics • Pervasiveness of function • Size, variation, dispersion • Functional characteristics • Customer requirements • Degree of homogeneity/heterogeneity • Extent of definition / formalization • Value of SOA capabilities to customer(s) • Broader coverage • More current / accurate

8. Dimensions of the Metric Space(Top Down) Total Cost of Ownership (TCO) is theme • Effort to maintain congruence between business processes and system • Similarity of (formal) representations at highest level • Fit to functional organization of business • System development/modification effort • Automatic generation of checks of correctness for refinement • Use of legacy components (wrapping technology) • Rule/script based specification of, e.g.: • Dynamic orchestration • Rule monitoring and enforcement • Business data monitoring, collection, and triggering action • Monitoring system health / performance

9. Dimensions of the Metric Space (Cont.) • Effectiveness • Usability by all customer(s) • Impact on productivity • Comprehensiveness of information for decisions • Effort to specify/modify information collection and analysis • Evolvability (modification by business managers) • Actual and opportunity costs for deployment and modification • Efficiency • Reliability • Response time • Resource use

10. Potential Taxonomy(Bottom up) Architecture/Scope • SOA-BP congruence • % of “mappable” functions • Comprehensiveness of service – all info needed? • % info needed by customer provided by system • Scope of events monitored (sensing capabilities) Notations • SOA-BP documentation allowing analysis (including of policy/procedure effectiveness and efficiency) • Effort writing code/rules/validity checks/data transformations – skill, training • Effort to modify – change propagation across models and in refinement • Scope of events monitored (scripting language) Utility • Added value of SOA-enabled info (enterprise-wide, timely) • Use by intended customers as function of time • Use and adoption by other organizational units as function of time • Impact on productivity/costs to deliver service or product

11. Potential Taxonomy (Conc.) Extensibility • Automated service discovery • Ability to combine multiple data and process specifications • SLA specification and enforcement • Anomaly detection and correction, load balancing • Ability to specify multi-step atomic transactions with rollback/recovery mechanisms • Rule consistency checking when changes made Likelihood of metastasis in organization(s) • Ability to incorporate legacy – wrapping, data reconciliation, data transformation capabilities –overhead for run-time operations • Ability of other units to use services developed for SOA • Organizational "fit“(Percent of services that map to a more global Functional Architecture)

12. Next Steps • Extend and validate candidate metrics • Prune and augment candidate set • Improve quantification • Develop metrics ontology • Relationships among measures • controlled vocabulary to describe objects and the relations between them • a grammar for using the vocabulary terms to express something meaningful within a specified domain of interest.

13. How you can help • Review draft document to suggest: • Useful measures • Additions/deletions http://www.antd.nist.gov/~salasin/PRM_Influenced_SOA_Indicators_v-1-055.doc • Provide comments jsalasin@nist.gov