Successfully reported this slideshow.

Usability

326 views

Published on

  • Be the first to comment

  • Be the first to like this

Usability

  1. 1. Break Out 1: Architecture Reqts <ul><li>What infrastructure services should architecture provide? </li></ul><ul><li>What SOA features should be available in SORASCS? [See list of possible features] </li></ul><ul><li>What is the relative importance of the following concerns: </li></ul><ul><ul><li>Security, reliable messaging, transactions, SLAs and policies </li></ul></ul><ul><li>What other concerns are required for this domain </li></ul><ul><ul><li>Tracability/provenance </li></ul></ul><ul><li>What other architectures should we interoperate with? </li></ul>
  2. 2. Breakout 1: Components and Data Reqts <ul><li>What other components are needed? </li></ul><ul><li>What current interoperability is there between components? </li></ul><ul><li>What format data is being used? </li></ul><ul><li>What transformations between data are possible currently? </li></ul><ul><li>What are the SOA integration issues with components? (e.g., decoupling UI, remote execution, control assumptions) </li></ul>
  3. 3. Breakout 1: Usability (1 of 3) <ul><li>Who are the people that will use SORASCS and integrated tools? </li></ul><ul><ul><li>Operational Users </li></ul></ul><ul><ul><ul><li>Naïve tool users attempting to solve specific problems – SORASCS should be invisible to this user </li></ul></ul></ul><ul><ul><ul><li>“ Power Users” Configuring analysis environments </li></ul></ul></ul><ul><ul><li>Scientists offering new analysis methods and tools *** Immediate requirements </li></ul></ul><ul><ul><li>Technical *** Immediate Requirements </li></ul></ul><ul><ul><ul><li>Engineers (etc.) Designing and developing SORASCS </li></ul></ul></ul><ul><ul><ul><li>Engineers (etc.) Implementing Components </li></ul></ul></ul><ul><ul><ul><li>Administering the environment for users </li></ul></ul></ul><ul><ul><ul><ul><li>Ongoing maintenance of components </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Standards – Operational -- Developmental </li></ul></ul></ul></ul><ul><li>What is their technical ability? </li></ul><ul><ul><li>Highly variable depending on experience and role </li></ul></ul><ul><ul><li>People with current SORASCS requirements are technically savvy – operationally naïve – </li></ul></ul>
  4. 4. Breakout 1: Usability (2 of 3) <ul><li>What are the usability issues in this domain? </li></ul><ul><ul><li>Current operational model is tool centric rather than task / mission centric </li></ul></ul><ul><ul><li>Lead times for tool configuration exceed allowed time or normal span of attention of current population of analysts. </li></ul></ul><ul><ul><li>There is an intermediate level of tool developers that do not have a consistent underlying data set or business model to build upon </li></ul></ul><ul><ul><li>A significant disconnect exists between the people with operational requirements and tool developers </li></ul></ul><ul><li>What is it that users would like to do that can’t currently be done? </li></ul><ul><ul><li>Analysts -- Help features for understanding how they can tailor tools to meet the needs of specific tasks </li></ul></ul><ul><ul><li>One possible role of the SORASCS environment is to be a clearinghouse for tools </li></ul></ul><ul><ul><li>Provide advice about relative strengths & weaknesses of tools and methods for specific analysis tasks </li></ul></ul><ul><ul><li>Recommendations of alternative models and workflows based on data that SORASCS sees in the system. </li></ul></ul>
  5. 5. Breakout 1: Usability (3 of 3) <ul><li>What are the barriers in the domain that inhibit automation? </li></ul><ul><ul><li>Lack of Consistent Underlying data and models </li></ul></ul><ul><ul><li>Lack of Developer understanding of the “real” domain needs </li></ul></ul><ul><ul><li>Lack of Decisionmaker confidence in the analytic products network tools generate </li></ul></ul><ul><li>What is the right user model for workflows (e.g., flexibility vs. usability) </li></ul><ul><ul><li>There is no “right” model for workflow – There are good ones and bad one though </li></ul></ul><ul><ul><li>Ideally it needs to be adaptable depending on the type of user, task, and data available </li></ul></ul><ul><ul><li>Because it will be limited it should publish the types of workflows it supports and make sense given the available models and data </li></ul></ul><ul><ul><li>Another possibility would be reachback support for adaptation of workflow </li></ul></ul><ul><li>What form should user interaction take? </li></ul><ul><ul><li>This depends on the sophistication of the user. </li></ul></ul><ul><ul><li>One possibility is portal access for: </li></ul></ul><ul><ul><ul><li>Data definitions </li></ul></ul></ul><ul><ul><ul><li>Guides for data collectors – often people </li></ul></ul></ul><ul><ul><ul><li>Guides for modelers </li></ul></ul></ul><ul><ul><li>Observe and remember vs. construct? </li></ul></ul><ul><ul><ul><li>Examples of successful applications or possible applications of operational relevance </li></ul></ul></ul><ul><ul><li>Vary degree of user interaction (e.g., edit delete list sometimes, not others) </li></ul></ul><ul><ul><ul><li>Some coaching based on what the SORASCS “sees” would be valuable </li></ul></ul></ul>
  6. 6. Breakout 2: Architecture and Component Next Steps <ul><li>What are the coarse-grained component types? </li></ul><ul><li>What component interaction modes should SORASCS support (call-return, asynch, pubsub) </li></ul><ul><li>What APIs are required? </li></ul><ul><li>What “ontologies” for service registries? </li></ul>
  7. 7. Breakout 2: Evaluation <ul><li>How should components be assessed relative to architecture? </li></ul><ul><li>How should SORASCS be assessed? </li></ul><ul><li>What challenges are there in assessment? </li></ul>
  8. 8. Supplemental
  9. 9. SOA Features List <ul><li>List of features that can be included in a SOA </li></ul><ul><ul><li>Varying degree of support between technologies </li></ul></ul><ul><ul><li>Varying degrees of standardization </li></ul></ul><ul><li>Issues </li></ul><ul><ul><li>How important to our domain? </li></ul></ul><ul><ul><li>How difficult to achieve? </li></ul></ul><ul><ul><li>Level of support and standardization </li></ul></ul>
  10. 10. SOA Features <ul><li>Service Implementation </li></ul><ul><li>Service Composition </li></ul><ul><li>Enterprise Service Bus </li></ul><ul><li>Governance </li></ul><ul><li>Business Process Management </li></ul><ul><li>Cross-cutting attributes </li></ul>
  11. 11. Service Implementation <ul><li>How to publish components as services </li></ul><ul><ul><li>Legacy systems </li></ul></ul><ul><ul><li>New systems </li></ul></ul><ul><li>Service categorization </li></ul><ul><ul><li>Data, Application, Business, Information </li></ul></ul><ul><li>Chosen Apache CXF </li></ul><ul><ul><li>Good support for legacy systems </li></ul></ul><ul><ul><li>Flexible wrt to transport mechanisms </li></ul></ul><ul><ul><li>Supports multiple standards </li></ul></ul>
  12. 12. Service Composition <ul><li>How to compose services to create other services </li></ul><ul><ul><li>Supports workflows </li></ul></ul><ul><li>Chosen Apache Orchestration Description Engine (ODE) </li></ul><ul><ul><li>Supports BPEL standard </li></ul></ul><ul><ul><li>Flexible programming constructs (loops, choice, invocation models) </li></ul></ul><ul><li>Issues </li></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>People in-the-loop </li></ul></ul>
  13. 13. Service Registration <ul><li>Provide Service Discovery </li></ul><ul><li>Issues/Capabilities: </li></ul><ul><ul><li>Data definition sophistication (H/H) </li></ul></ul><ul><ul><ul><li>Consensus-based ontologies </li></ul></ul></ul><ul><ul><ul><li>Degree of meta-data/typing </li></ul></ul></ul><ul><ul><li>Service Discovery (H/M) </li></ul></ul><ul><ul><ul><li>Service Querying </li></ul></ul></ul><ul><ul><ul><li>Degree of dynamism </li></ul></ul></ul><ul><ul><li>Service Selection (M/H) </li></ul></ul><ul><ul><ul><li>Degree of automation </li></ul></ul></ul>
  14. 14. Enterprise Service Bus <ul><li>Middleware layer that provides messaging services </li></ul><ul><li>Issues/Capabilities: </li></ul><ul><ul><li>Dynamic discovery and connectivity (H/) </li></ul></ul><ul><ul><li>Reliable messaging (H/) </li></ul></ul><ul><ul><li>Topic- and content-based routing (M/H) </li></ul></ul><ul><ul><li>Transformation capabilities (H/H) </li></ul></ul><ul><ul><li>Support for long-running processes and transactions </li></ul></ul><ul><ul><li>Security (H/H) </li></ul></ul><ul><ul><li>Management and monitoring (H/H) </li></ul></ul><ul><ul><li>Scalability (H/M) </li></ul></ul>
  15. 15. Governance <ul><li>Exercising control over services </li></ul><ul><li>Issues/Capabilities: </li></ul><ul><ul><li>Service versioning (M/?)             </li></ul></ul><ul><ul><li>Service index listing (H/L)             </li></ul></ul><ul><ul><li>Service publishing </li></ul></ul><ul><ul><li>Service monitoring (M/technology dependent)   </li></ul></ul><ul><ul><li>Service retiring (L/) </li></ul></ul><ul><ul><li>Logging and Tracking (H)           </li></ul></ul><ul><ul><li>Control/Ownership (M/?)             </li></ul></ul>
  16. 16. Business Process Management <ul><li>Managing processes/workflows vs. individual services </li></ul><ul><li>Capabilities/Issues </li></ul><ul><ul><li>Process versioning (M/H)  </li></ul></ul><ul><ul><li>Distributed service invocation (H/L)             </li></ul></ul><ul><ul><li>Long-lasting processes (H/M)             </li></ul></ul><ul><ul><li>Transaction management (L/ )                    </li></ul></ul><ul><ul><li>Business Activity Monitoring (M/technology dependent) </li></ul></ul><ul><ul><li>User permissions for processes (H/H)           </li></ul></ul><ul><ul><li>Process deployment, removal, modification (H/?)           </li></ul></ul><ul><ul><li>Support for human activities (H/H)           </li></ul></ul>

×