Managing Applications Status of Standards Today

1. Managing ApplicationsStatus of StandardsToday February 5 2003 Open Group Members Meeting San Francisco Karl Schopmeyer

2. An Application Manageability Group • Objectives Today • 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. • User side • Supply side

3. Network-based, loosely coupled tiers enabled by distributed computing and management technologies Loosely coupled tiers enabled by distributed computing and management technologies The changing IT environment • Business Awareness Shift • Tactical: Management of IT resources • Strategic: Optimization of Business • Fundamental architecture shift • From • Distributed, n-tiered topology • Difficult and expensive to manage • Big footprint • Marginally reliable computing • Many I/O media • To • Distributed, n-tiered topology • Rich, policy-based management • Reduced footprint • Highly scalable, reliable computing • Converged I/O medium • Application transparency

4. Today’s Challenges • New web-based applications introduce unpredictable loads on IT infrastructure, increasing cost and problems • Complex, heterogeneous, n-tiered application environments are difficult and costly to manage • Lacks insight into application resource inventory and utilization, and how the state of application infrastructure affects business performance • Unable to meet user expectations for Application Quality of Service • Systems management offerings have failed to deliver on their promises • Business priorities are not reflected in IT infrastructure. • Management is not important until after a system is developed and installed.

5. Fundamental OS Shift • Limited instrumentation • No control • Limited visibility • Result: • Configurators and Monitors • Ineffective Policy Mgt • Rich instrumentation • Complete control • Great visibility • Result: • Measure, analyze, and Affect • Powerful Policy Mgt

6. Means different things to different people Deployment Management Configuration Management Fault Management Resource Management Performance Management Service Level (QoS) Management Business Service Management Operational Control Different Views Of Application Management Business Management Service Management Fault Management Etc. What is Application Management?

7. Business Management Service Management End-to-End IT Management Application Management Device Management The Changing Requirements • The user requirements are changing faster than the solutions technologies. • Users want business and Service management • The suppliers are still trying to instrument • Users want to integrate applications across platforms • Suppliers don’t really have a model for applications management • Architectures are changing • Dynamic, Components, runtime integration • Integrating WEB Services • Manage the business, not the technology • But we cannot manage the business until we manage the technology. • Modeling the “management” components of the Business is even more difficult than managing the technology • Applications are becoming largely integration • We still cannot instrument the base, thus cannot manage the integration

8. Business Applications Systems Management Resource - Device Management Resources-Devices Climbing The Management Mountain SLA, QOS Business Managmenet The Users The User requirements are growing The suppliers are significantly behind the user requirements We cannot build on “empty air”. Management functionality must be a growing infrastructure.

9. Solution Requirements • Measure, analyze, and affect the entire application environment • Affect and visualize in real-time, dynamic infrastructure changes and understand their effects on the business • Provide integrated dashboard to measure business productivity against objectives • Install, maintain and operate easily • Be non-disruptive • Standards-compliant • Secure • Reduce management TCO; deliver fast and measurable ROI • Common and interoperable information.

10. Why Standards? • Common Instrumentation • Difficult to instrument for management • Nobody works on management until the end of the project • Manage across components • Need common data • Integrate management information from multiple components into common management views • The user wants to manage the environment, not islands • Instrument for what we want to manage • Service Level, Business Management, etc. • Models must drive instrumentation

11. Why is modeling Important? • Common Information • The right Information • Ex. Service Level management needs information • Putting Semantics on information • Create common Semantics, not simply common syntax • Provide interoperability of information • Providing a management “abstraction” Some people simply do not understand the value of data models We have not convinced the world why they are important yet.

12. Management info Models In Context Manageability/Management Interface Management Models And Information Applications Applications Applications Applications Management Applications Management Applications Management Applications Management Applications Management Applications Applications need management APIs Common understanding of protocols, syntax, and semantics Manageability Interface Common protocols and Information

13. Why is Application Management Important? • Managing systems is not managing the applications that run on them • Getting information from applications and controlling them is the key to the next step, managing services and managing the IT business. • Applications are becoming inherently “multi-system” • Users buy IT to do work, not to look at their OS. • OS performance, quality, etc. is often not a direct indication of application performance, quality, etc.

14. Some inhibitors • There are so many of them • They are different, every one of them • Everybody has a different view of what it means to manage applications • Applications are becoming highly dynamic with very late binding. • Management is an afterthought • There is very little “long-lasting” instrumentation support for applications. • Many key applications are legacy – We will never touch them again but they will run for years. • Some Laws of Nature • You can’t push on a rope • Water flows downhill • Management only becomes important when it’s too late

15. Separating the Problem • Management vs. Manageability • We want to define manageability so that applications can be managed in a common open manner • Good manageability will drive good management • Components of managing Applications • Lifecycle – Deployment management • RunTime Management

16. The Open Group APIs ARM API AIC API XSLM – License Mgt API QOS DMTF Modeling Application deployment App Server Runtime Database model (based on SNMP MIB) Application runtime management Unif of Work Metrics Policy SNIA SAN based open management IETF SNMP App based MIBs XMLConf Polichy Mgt Global Grid Forum Generalized view of resources and their management Oasis Web services management W3C Web services management architecture Java JCP Process JMX Interface JMX – CIM model mapping Etc. TMF QOS Modeling The Standards Players Today

17. And yet today we really cannot effectively manage applications, much less services or business in an open interoperable manner.

18. Management Lifecycle multiplicity 1:n 1:n 1:n app status deployable installable executable running initial life cycle sub-model transport setup installation runtime (structure)

19. A Runtime Model app status executable running initial life cycle installation sub-model workflows runtime model function configuration indications history systems workflow = default+ rollback+exception structure best practices (tasks): routine (daily/weekly/...) configuration analysis data external systems methods

20. Application Architecture: Views and Elements Scenario External System System OS OS/ Host Resource Processing Elements Logical Software Service Structure Code Component Lifecycle Data Flow Time: shipping -> running Action Data Application View Application Element

21. Models and Instrumentation • Measuring Unit of Work Performance • ARM • Unit of Work Metrics • Interfacing General Instrumentation models to CIM • AIC – Application Instrumentation and Control • JMX • Characteristics of the models • Dynamic management objects • Application defined management objects (defined by the business) • Requirements • Strong on semantics • Dynamic creation of “definitions” • Metrics and operations.

22. Key Interoperability Interfaces Management System Enterprise Management Console • Manageability to Manager • Multiple management systems • Common open manageability CIM Object Manager • Object Manager / Providers • Multiple Providers • Encourage common providers CIM Providers • Provider / Resource Interface • Protect Applications • Make application management easy Application Application Application Application

23. Some of the Issues • No clear understanding of the importance of models to management • Instrumentation and models are not connected • ARM and Unit of work metrics are different • App management is two different worlds • Technical management • Management of the services delivered • Application management has to be built on lower layers

24. There are REAL Opportunities here • APIs • Service Level / QOS • TOG is unique in having a real user input • Requirements Generation • Integrating other Standards • Defining application management End-End with specific goals • Ex. Perforamance, availabiliy, etc.

25. NOTE: • However we will only draw interest if we: • Do something • Do something that is of interest to some of the supplier community • Do something so that there are results in a short measureable time • Work with the other standards groups in this area, not by ourselves.