Task 

Adoption

Options

 

Outline

  1. Task Importer
     
  2. Task Service via Direct Http
     
  3. Task Service via Task Client (formerly Proxy)

Task importer

What is it

Simple web app that allows non-developers to do the following:

  1. Create tasks via excel spreadsheets
     
  2. View newly created tasks immediately
     
  3. Delete any existing tasks 

User

Task Database

Web App

how to implement

Create Simple Asp.Net MVC Web App that does the following:
 

  1. Takes tasks created in excel spreadsheet (.csv) and imports them into the existing task db
     
  2. Displays a list of tasks pulled from db that can each be deleted with a click
     
  3. Deploy Web App to Internal Network

pros

  1. Product PO's, Product BA's, SME's, Focus Groups members,  can create create and delete manual tasks directly
     
  2. Provides easy to use tool for Task type design
     
  3. Speeds up user adoption of the Task framework
     
  4. Can continue to be used for the lifetime of the task queue
     
  5. Fastest feedback loop of the 3 options
     
  6. Can be used as an additional training aid for users

Cons

  • Requires additional creation of a plain web app (Asp.net MVC)
     
  • Requires web app be deployed

questions

Task Service

via http

What is it

Requestor ​connects directly to 

the Task Service Via Http.

This will be leveraged both for creating Task and receiving the results of completed tasks.

Requestor

Task Service

HTTP

how to implement

  1. Ops Provides Documentation\Examples for accessing tasks
     
  2. Ops provides Commonly shared models for generating tasks or, Json for Raw Json based Requests
     
  3. Developers from other teams will write API calls using http requests
     
  4. Developers from other teams will provide Web API Endpoint for handling Results.

pros

  • Very little new Ops Management Development
     
  • HTTP is well known and supported

Cons

  • Ops Team will have to provide increased support with documentation, examples and training (the most of any option)
     
  • Developers are a critical path to experimentation, design and overall adoption
     
  • Requires additional development effort from each of the Product teams
     
  • Code created in support of this interim solution is "throwaway" because of eventual migration to Task Client

questions

Task Service

via Task client

What is it

Requestor ​connects to the Task Service Via Task Client for handling the creation of new Task requests and their completion responses.
 

The Task client encapsulates the communication protocols (Http,MsgQueue or Database) and provides a strongly-typed way to instantiate and respond to Task requests and responses.
 

Task Service

Requestor

Task Client

Http

MSG Queue
Database

how to implement

  1. Ops Provides Documentation\Examples for accessing tasks
     
  2. Ops provides Commonly shared models for generating task requests
     
  3. Developers from other teams will generate tasks using Task Client
     
  4. Developers from other teams will leverage Task Client for handling submitted Task results.

pros

  • Developers can use simplified tooling for Task creation and result handling
     
  • Standardized interaction with the manual task framework that will be used long term
     
  • Abstraction layer provides additional flexibility for long term options
     
  • Because it is being developed by Product Framework team it requires less effort of Ops Development Team

     

Cons

  • Ops Team will have to provide increased support with documentation, examples and training (Less than with the Http option)
     
  • Developers are a critical path to experimentation, design and overall adoption
     
  • Requires additional development effort from each of the Product teams
     
  • Not yet available as it is still actively being worked on

questions