End of Day 1 whiteboard

[<Stavros.Isaiadis@uk.fujitsu.com>]

GOALS OF MEETING:
- Enfranchise other groups
 Enterprise management
 CEP people
 Cloud
 Healthcare?
 SmartGrid?
- ????

WHAT IS SAF?
- "SAF is a catalog-based, XML knowledge framework that
    enables problem remediation, prevention and optimization of
    the operational and business characteristics of complex
    systems. The framework has applicability to both IT domains,
    e.g., cloud computing, service management, governance, and
    security as well as non-IT domains, e.g., energy, eGov,
    financial, healthcare, manufacturing, and more."
- Interop framework for rules-based, federated participants across domains?
- A "Bridge" across islands (enterprises) and their complex events
- It's the collaboration through the catalog
- A shared "eco-system" within the context of the framework (share and interoperate at a certain level)

Key Success Factors
 Ability to annotate raw "event" data to enable composition at higher level

Value Points for the individual components of SAF:

   Symptom Single Port of Call and Envelope for:
   - Events (state transition)
   - Conditions
   - Facts
   - Policies triggered conditions
   - Historical context
   - Identified semantics for each symptom defined

   Protocols and Prescriptions
   - Framework for defining things we can do
   - Identified semantics for each protocol defined
   - Generalization of process (Protocol) from specific implementation (Prescription)

   Syndromes
   - Alone are of little value

   Syndromes and Symptoms
   - A simple monitoring and alerts system

Over all SAF value:
- Glue for everything
- Interoperability framework
- Declarative rules
- Clearly differentated roles (Emitter, Diagnostian, Practictioner)
- Monitoring and Responses in the same solution
- Simplified bridging between domains, e.g.
 - Between cloud customer and provider
 - Between business and operational sides of the enterprise

Adoption Issues
- Confusion with Event processing
- Conflict with vendor business goals especially in cloud (proprietary needs time to grow before consider standards)

DIFFERENCES WITH RULES-BASED SYSTEMS?
- Collaboration

DIFFERENCES WITH CEP?
- CEP normaly internal only

Q: What is the fundamental, unique value of SAF?
A2: It bridges the business and operational sides of the enterprise.

Q: What is the fundamental, unique value of SAF in the Cloud?
A2: The chasm between the business and IT is significantly widened due to the lack of context between cloud-provider and cloud-consumer. SAF bridges the chasm by enabling business-relevant conditions to enable meaningful business-relevant responses.

Q2: What technical problem is Symptoms trying to address?
A: Cross-domain problem determination, remediation, and optimization is too costly, labor-intensive, reactive, and complex

A2: Signficiant barriers empede effective collaborative decision-making (operations) across and within enterprise domains, especially in the areas of problem determination, remediation, and optimization. SAF enables effective collaboration by providing a role-based framework that enables the creation and utilization of collaborative catalog-based rules and actions that can help different domains work together more effectively, solve problems, xxxxx, etc.

Q1: Can you summarize the benefit?
A: Symptoms provides a common format to consistently analyze and remediate problems based on events from multiple domains and multiple vendors, and allows on-site management to extend and optimize the capabilities of their deployment beyond what vendors provide out of the box.

A2:  It's hard for different enterprises and domains to work together to fix problems and respond to their customer's needs. SAF provides a collaborative framework that enables enterprise and domains to address these issues at lower cost and more effectively.

Q: How does Symptoms relate to Cloud computing
A: Simply put, applications, services, and processes hosted in the cloud tend to have even more moving parts and layers than when more traditionally distributed and deployed. In fact, adding the extra layers of abstraction across multiple vendors and domains will likely increase the cost of support and optimization without a standard like SAF to enable a more automated approach.

SAF supports not only the autonomic management of individual layers in the Cloud deployment stack, i.e. IaaS, PaaS, SaaS, but also it facilitates the communication of problem (and optimization) information across the boundaries. For example, a Symptoms enabled PaaS could accept application level information from SaaS to optimize provisioning at the IaaS level

A2: Cloud services embrace concepts such as self-service, pay-per-use, and capacity-on-demand. SAF enables the concept of self-service by enabling cloud consumers and providers to both publish information about key conditions and an appropriate responses that enable them to optimize their business relationship.

Q: What are the focus areas for this framework?
A: Although we started with the IT domain we also see business processes as fitting the model and have factored that into the initial design.

A2: IT Systems, Cloud management, and Green IT/SmartGrid.

Q: What audiences should be interested in this work?
A: Software Architects, Developers, Problem Analysts, Service/Support Personnel, Testers, and Integrators.  Moreover, we’ve defined a set of roles – diagnostician, practitioner, emitter, and so forth – that map reasonably well to existing roles in the problem determination / operations design space, and having parallels in other domains as well.

A2: Government, industry verticals and the IT industry generically should be interested in using SAF to improve business and operational synergy.

Q: Why the use of medical terminology?
A2: It provides an analogy many people are already familiar with so they can more easily understand the work and help it succeed, nothing more.

Q:  How does Symptoms differ from traditional rule-based systems?
A: SAF utilizes two types of “rules”: (1) pattern recognition signatures and (2) automated action directives.  These “rules” differ from traditional systems in their ability to handle partial information, consider event adjacency, decouple recognition from actions, and achieve interoperability.

A2: SAF utilizes some principles from rules=based systems, but defines a roles-based framework that enhances the value of rules-based systems by focusing on cross-domain and business/operational bridging and collaboration in synergy with existing rules-based environments.

Q2:  How does Symptoms differ from traditional complex event processing (CEP) systems?
A: No. The SAF uses existing events as one of its possible inputs. By decoupling the actions taken from event management, SAF is a more generic tool suitable for many different application domains.

A2: SAF embraces the world of CEP by integrating into the event-driven world. Symptoms are light-weight envelopes that might contain events and typically signify higher-level, often cross-domain conditions. SAF functions as a bridge. Symptoms are matched against a collaborative catalog of Syndromes and Protocols that translate those conditions into meaningful actions that might include the emission of relevant events in another domain or level of the business.

Q: Without the Symptoms Autonomic Framework how might these problems be tackled, and what is wrong with these approaches?
Q2: Without the Symptoms Automation Framework, how might these problems be tackled, and what is wrong with these approaches?
A: The traditional approaches to this type of problem detection and remediation process are largely manual. Where automatic solutions exist they tend to be highly constrained to single platforms or domains, whereas SAF is an open framework supporting a wide range of disciplines.
A2: ERASE THIS QUESTION

 

USE CASE TARGET
- Collaboration,
- Pain Point clearly identified
- Emphasize dynamic composition aspects

Use Case 1: Automation of Increased Provisioning Precipitated by Consumer Business Conditions

   Actors: Cloud Provider and Cloud Consumer

   Scenario:
   - Provider contributes (and publishes) a Protocol to add additional resources (VM, etc)
      (could be straight out of DMTF or OCCI, for example)
   - Consumer contributes Syndromes (including signature based on the Symptoms he will emit).
      Also adds references from Syndromes to appropriate Protocols (as provided by the Cloud provider).
      One Syndrome is increased business activity (sales), which is mapped to a need for greater
      IT resources in the provider.
   - The provider knows nothing of the consumer business semantics and vica versa.

   Business Value:
   - Mapping consumer business conditions to provider cloud responses

Use Case 2: Automation of Decreased Provisioning Precipitated by Changes in Cloud Load

   Actors: Cloud Provider and Cloud Consumer

   Scenario:
   - Provider publishes a Syndrome template that detects multiple idle VMs allocated to a given consumer.
   - The consumer fills in the Syndrome template to specify the level of idle VMs that are unacceptable.
   - This Syndrome also refers to a Protocol template (filled in by the consumer)
     for decommissioning the appropropriate number of VMs within the environment.
   - Consumer takes the published Syndrome and Protocol (possibly modifies parameters specific
      to their needs, such as VM shutdown process) and adds this to the catalogue.

   Business Value:
   - Provider uses SAF to gain competitive advantage by providing opportunity for consumers to decrease cost

[[Paul]] Wouldn't be more useful if the consumer could add *business-relevant* aspects to the pattern instead of a VM shutdown process? The provider is far more expert than the consumer in that area. Also, standards like DMTf cloud incubator (and most other cloud APIs) will allow you to shut down a VM and enhancements to standards like CIM might allow the detection of an idle VM.  I would suggest that the Consumer add something like a pattern that detects when a "sale" is about to be launched. When that sale flag is set, idle VMs are NOT decommissioned because we will be needing to respond to a wave of sales soon and don't want to have slow response times discourage sales. Try to do that with a conventional spec! :-)

Use Case 3: Green Policy Management

  Actors: Cloud Provider and Cloud Consumer

  Scenario:
   - The Provider emits a Symptom relating to the current CO2 burn of the customer's current computational estate.
   - The Provider might (optionally) publish Protocols to enable actions such as decommissioning virtual infrastructure or even switching to a lower-carbon,       higher cost energy provider.
   - The Consumer could essentially encode their green policy by creating Syndromes that map various QoS requirements and CO2 levels to the Protocols        that control energy utilization and/or energy provider.
   - The consumer's SAF diagnostician (internally or hosted/provided by the provider) to modify their QoS to keep CO2 below some policy determined level.

 Business Value:
- An entirely new business model and opportunity for Cloud providers and consumers enabling a carbon-aware hybrid Cloud enterprise.

[[Paul]] I like this a lot. We should talk to the OASIS Emix TC about this. Emix feeds the money and carbon cost as Symptoms to a framework that reflects corporate *business and regulatory policy!* Try to encapsulate that with a simple management spec! This is multi-faceted with real business value.

______________________________________________________________________

Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469

This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan does not guarantee that
it has not been intercepted or amended nor that it is virus-free.