1. EGR-RG　Session
GGF12
22nd Sep 2004

2. Agenda Note taker assignment Status of the Group
Definition of Enterprise Grid
Summary of the Workshop
Discussion about the document

3. Status of where we are RG approved on 5th Aug.
Some comments on the definition of the Enterprise Grid.
Workshop yesterday quite successful and interesting
We need input from all of you on definition of enterprise grid as well as the survey documents..

4. Input into def. of Enterprise Grid (1/3)
Expand EGA’s "The support of Enterprise computing via grid technologies, architectures and ideas"
Virtualization, where the physical resource characteristics are hidden from the view, exposing just the logical view of the "resource fabric" is one essential technology which makes the enterprise grids feasible.
High degree of automation in resource (re-)provisioning, managing, and monitoring, be it hardware, software, data, is another essential technology.
couple these technologies with the common Grid services like scheduling, accounting, logging, reservations and/or agreements, the resulting EG requirements has all of the characteristics of a EG model infrastructure that will enable organizations to adapt to new business conditions quickly, efficiently, and cost-effectively.

5. Input into def. of Enterprise Grid
If the Enterprise grid research group is to exist it needs a clear definition that separates it from existing groups .
The jobs submitted to an enterprise grid  may form part of a business process workflow which may include transactions. scheduling mechanisms are required for these types of application and  to cope with large numbers of relatively small calculations.
The management requirements of an enterprise grid are very different than those of scientific/research grids, ideally much of the management and configuration should be automatic and require almost no manual intervention.
It is essential to accommodate the logging and traceability requirements imposed on business transactions in many commercial areas. This should at the very least generate requirements documents for the grid monitoring and management research groups.
Enterprise grids must be reliable, and offer predictable performance and  quality of service, An idea of the normally expected levels of uptime and methods used to provide resilience in key enterprise applications would again be key information in the design of the fundamental grid services.

6. Input into def. of Enterprise Grid
My interest in "enterprise grids" is from a campus/academic/research perspective
I believe that some of the institutions participating in the NMI (NSF Middleware Initiative) Testbed program would have examples and insights to contribute.
Several of the NMI Testbed sites have campus grids in place and are making significant headway in understanding the needs/potential of such a resource.
Is the EGR-RG going for a broad definition of "enterprise" or will this work be primarily focused on corporate requirements? If the latter (I thinks she had meant to say the former), we'd sure like to contribute

7. Definition of Enterprise Grid
1)Distributed Environment for Transaction based CPU intensive computing.
2)Distributed Environment for Computing intensive computing ( such as simulation )
3)Distributed Environment for Business processes.
Do we try to resolve which of the above we should focus on or should we try to include all of the above as basis for a wide definition of Enterprise Grid?
(comment1) 2) is really what the grid as we have seen it so far is all about. This should be more than adequately covered by the work currently underway. 1 )may be seen as a specialisation of the more general 3).This then collapses back to an overall support for business processes case. Addition would accommodate the support for transactions, additional logging, monitoring, management, security etc that all enterprise grids would require over and above the current grid activities.
(my 1cent) From the various keynote speaks in GGF12, not allowing for Distributed Environment for Computing intensive computing ( such as simulation ) would not meet people’s expectation…

8. United Devices Requirements
Ease of Application Integrity
Enterprise Scalability
Security (Protecting Data using Encryption: Tamper Monitoring.)
Flexible policies for resource management
Data Management
Meta Data Management
Integration withIT infrastructure,standards

9. For the documents
Collect the documents from yesterday’s talk. (Nearly done)=>How to turn them into usecases format.
Collect other Speeches given in various speeches made in the Crowne Plaza. (When can we do this?)
Any other contributions>all??
451 paper distributed to GGF12 participants gives quite a bit of insights but we cannot quote it in a public document. Ask 451 people

10. Try to setup the requirements for EG.
Define from the environment p.o.v.
Some of the req. might overlap with other req.
Requirements Analysis should be done quickly.
Distinctiveness clarification should be done quickly.
Start with a broader scope. No group in GGF focused on requirements of the entire spectrum.
At some point decide on what to focus. We need to collect usecases. Look for patterns in the usecases.
Use OGSA usecases also. Ravi to upload the current usecases
Bring in the requirements sets from OGSA and develop further.
What granularity of requirements should we go to?
Then Gap Analysis

11. Check with S. Crumb on the visitors of GGF12
Go crazy to Collect the use cases Solicit requirements from every people involved. Upto next GGF13. March ’05.->Do also first level Pattern analysis as the usecases come in. We should be armed for GGF13.
Define a time line for the broadcast.
Define a specific format
Look through the OGSA format and see if it is sufficient
Define the usecase collection process. (Receive/review/accept/catalog)
Decide on the telecons.
Cover letter (Call for usecases) to ask for. Also to the presenters.
Would you want to be covered as a source? Anonymous posting is also acceptable.
Check with S. Crumb on the visitors of GGF12
Post to the
Build a catalog
Pattern Requirements Analysis:
Def. of Pattern is consistency in usecases. Common requirement features. Something like in WS-I.
Begin to recognize patterns (eg Grocery, Business Person, Parent collecting kids from School ->pattern for transport usage)
Present defining what different kind of EG is through usecases analysis.

12. Telecons: Bi weekly? Which day?
Define the Timeframe for the Security Aspects are in Place.
Please Join Us!!
list:
Web page:

13. Categorize Which is relevant for standardization
Which is relevant for implementation
Which is relevant for deployment