The meeting was a joint session with the QoS Task Force and
The Enterprise Management Forum.
Wednesday morning focused on Customer requirements for QoS and SLAs,
the SLA Survey and White Paper, and Volume 4 (authored by The Open
Group's QoS Task Force) of the SLA Handbook, which is centered on
Enterprise SLA requirements.
Dr. Deborah Goldsmith, Lead Scientist, Networking Systems &
Distributed Systems at the MITRE Corporation presented the Customer
story.
The presentation (Powerpoint slides here)
focused on the problem of how to meet QoS Service
Level Agreements (SLAs) for practical/deployed platforms across an
end-to-end circuit in a defense environment. The end-to-end circuit
crosses multiple administrative domains contained within the ultimate
administration f the DoD. Convergence of applications to an IP
infrastructure was given as an assumption. It was observed that the
problem crosses hierarchical SLA boundaries. To simplify the problem,
the mobility aspect of the scenario was ignored. DiffServ was explored
as a potential mechanism for implementing the SLA's but the consistent
implementation of DiffServ across multiple administrative domains, and
the provisioning of the core (WAN) versus the edge (tactical nodes) were
raised as issues.
John Saperia, (PowerPoint slides here) JDS Consulting. Jon Saperia provided an overview of
Industry-Wide Research that was conducted by the QoS Task Force in 2002.
This survey of customer requirements for SLAs included how internal and
external SLAs are employed and what were the customer requirements
around them. John's presentation focused on the observations,
conclusions and possible next steps for work in this area. Some of those
conclusions, observations and next steps were: · SLAs are more useful
by traffic or application type yet many do not have this ability. We
should look at cost/benefit analysis of deployment of technology in this
area. · Definition of terms used with technologies used for SLAs mean
different things for users and technologists: need to understand terms
like marking and metering - so that SLAs could be written more
accurately. · No clear set of services and metrics: Range of services
are broad. Is there a high-level services that are emerging for which
standard metrics would be useful. · Management is a problem: too many
non-integrated pieces. · Need to increase the availability of
management statistics, such as latency, MTBF · Few companies 'mark'
traffic: URL id is most common(certain web pages go to dedicated
servers)
David Banes, TenTen Communications. David covered the work that he and
the QoS Task Force have been doing with the TeleManagement Forum on the
SLA Handbook. The QoS Task Force is writing volume 4 of that Handbook,
which focuses on enterprise requirements for SLAs and how they translate
to Service Provider parameters. While emphasizing that SLAs happen at
multiple boundaries within the enterprise and between business partners,
service providers etc, the majority of the presentation covered the
Enterprise side of the Enterprise/Service Provider domain. Hi
presentation focused on: · Mapping of Business objectives to
Applications and to the resources below to come up with Service Level
Agreement that takes those objectives and business rules/constraints
into account. · Need for managing application throughput and real-time
monitoring. · Representative business apps: office, call center,
brokerage, retail, wholesale, healthcare, etc. · Services: voice, VTC,
streaming, telemetry, transaction, email, office automation, help desk,
broadcast, tele-working, intranet, extranet, internet. · What SLA
Monitoring and Reporting involves from the enterprise perspective. ·
What qualities/parameters an enterprise SLA would require.
Managing Applications, Status of Standards Today
Karl Schopmeyer reviewed the background to the work in the DMTF and
The Open Group.
The objectives of his presentation (PowerPoint
slides here) were:
- Determine what such a group can contribute to application
management.
- Determine if we want to make such a group work
- Determine what the basic charter for such a group is
- Determine who we want involved from the user and supply sides.
Management of Applications does not work well, and will not work well
without a fundamental architectural switch. The scope of the problem is vast, from single applications to the
largest implementations of systems like SAP. The challenge is becoming increasingly hard because of the vast
number of applications on the most basic of system, and because of the
increasingly dispersed nature of integrated applications. There is not
even a common understanding of what an application is.
Users expectations of the performance of applications are
consistently not met, and users are still asking the same questions they
were asking 8 years ago. Finally, despite of all the pressures from users, they do not express
their needs early enough in the development cycle.
Systems are being moved from large systems to small ones to grid
systems, and so on.
Application Management means different things to different people:
the subject includes the Management of Deployment, Configuration,
Fault, Resource, Performance, Service Levels, Business Services.
User requirements are growing, but any solution has to be developed
from the bottom up, so that at each level there is an infrastructure
that can be built upon.
Standards are needed because somewhere we have to be able to define
the instrumentation that enables us to define service levels.
Modeling is important because of the need to have common information with
agreed semantics, with a management abstraction so that there is a
mechanism such that the semantics are understood by the object doing the
managing and by the object being managed.
| Management
Applications |
Manageability interface, common
protocols, information and semantics |
Management
Models and Information |
Management APIs |
Managed
Applications |
Some inhibitors to develping a solution:
- There is not common view of what Application Management is
- Applications are becoming highly dynamic
- Most key applications are legacy
The problem is not management but manageability. The key is to
create an environment for manageability
There is no clear understanding of the importance of models, and
instrumentation and models are not connected.
People will only become interested if we do something that is of
interest to the supplier community, that will have results in a short
and measurable time, and we work with everybody else.
Discussion: the problem is that for both Customer Organizations and
Application Suppliers Management is not a high business priority.
Enterprise Management
Tom Bishop, CTO, VIEO, Inc. Tom's PowerPoint
slides are here.
Management has been a problem for years, and it has not been
solved. Not only is the need becoming more and more pressing, but
the solution is increasingly hard to find.
Two organizations have built effective management systems - AOL and
eBay, and they invested enormous resources in order to build their
solution.
They are able to monitor transactions in real-time and to control
their systems.
Resources are not infinite, so in the end any system has to make
tradeoffs. The aim is that business systems should be able to take
the decisions that need to be made, but that they should be provided
with the information they need to take those decisions.
There is ultimately a need for a separate network to support
management - because otherwise a problem that affects the application
may well affect the managing system.
Current Standards situation
All that is required is something like 25-50 measures - 20% of the
work would provide 80% of the benefit.
Any initiative would of necessity need the involvement of companies
like IBM, HP, Sun, Microsoft .... This could kill any initiative,
but it is a reality of life that without them it could not work.
Wednesday - Afternoon Follow-On Round-Table (4:00 - 5:30)
This interactive working session focused on responding to the
challenges of Application Manageability as set out in the previous
session by engaging in a Requirements Gathering Session to capture:
- The issues around Application Manageability
- How standards can be used to address the requirement of specific
industries or enclaves
- How to break the issues down into prioritized focus areas where
progress can be made
- What we need to do to generate interest, increase the value
proposition for working on application solutions that are standards
based, and get people to commit to participate in a collaborative
effort in this area.
Notes on Brainstorm
- What about the Network?
- Application Metrics - a common understanding and agreement of what
metrics to support
- Metrics for all areas - network, application, operating systems, ...
- Make sure underlying metrics are relevant to applications
- Get input from vendors and users depending on the area
- How do you gain a deep visibility of resources from applications
- Behavior often follows patterns - J2EE applications tend to do the
same sorts of things
- Recommend a way to incorporate external entities (e.g. legacy
systems) into the Framework and extensions to Framework
- How do you know if a service level is acceptable?
- How do you correlate the metrics to identify the root cause of a
problem?
- The metrics won't be right at the beginning - the approach should be
to pick a set and then validate
- Dependency Extraction
- Inferring relationships from dependencies and metrics
- The Framework should not be too prescriptive, and it should not be
dependent on any particular application architecture.
- Need to consider key applications - SAP, BAAN, Oracle
- Identify a small subset of metrics that is mandatory
- Issues
- AQoS
- ready to do something
- willing to work inside The Open Group
- organizations who are already involved
- Organization Types:
- IT users: DoD, Boeing, Fidelity, Citibank
- Vendors, HP, IBM, Microsoft, Fujitsu, Cisco
- Control Developers like Oracle, Peoplesoft, SAP, Rational
- Software Developers, big ISVs, CA
- Outsourcers - HP, IBM, EDS
- Next step is to find the contributors out of the list above
- Agreed that Open Group staff would work with Tom Bishop to produce a
Call-to-Arms which would be used to encourage participation.
- Aim should be to meet in around 6 weeks, so that work can be done
during April that would enable the meeting in Austin at the end of April
to do real work.
- Aim should be to pursue high potential sponsors.
- The activity should be presented as enlightened self-interest.
Karl Schopmeyer proposed that the DMTF's CIM should be used as the
base model for the work.
Collaboration
- SNIA - Storage Networking
- OASIS - Management Web Services
- W3C - Web Services, Architecture and technologies
- GGF - Resource sharing and provisioning (Model and Services)
- DMTF - Model Unifications and Distributed Management
Infrastructure
- Other Management Standards Organizations
Benefits - one unified model, coordinated development processes,
shared technologies, expertise and competencies.
