Watson Ecosystem Architecture

Background:

The Watson Ecosystem is at the forefront of cognitive computing, allowing businesses to embed transformative question/answering capabilities within their applications. The Watson Ecosystem is growing fast and as the number of partners and the variety of domains grows, the Ecosystem needs scalable ways to manage these partners. One of the ways the Ecosystem plans on managing the partners it works with is through a Dashboard that allows the user to aggregate information about Ecosystem partners in a customizable way.

Objective:

The purpose of this competition is to provide the Architecture for the Web Application for the Ecosystem Dashboard. In particular, the Ecosystem envisions the default view to be a Visualization, such as a heat map, where each UI element in the Visualization represents a different partner and a visual cue to distinguish between different partners is based on a customizable statistic/metric. The application should provide filters that change the perspective of the Visualization and provide a mechanism to customize the view for a given user (i.e. user profile or save function). Other than that, the target audience for this application will be Watson Ecosystem engineers and managers looking to make decisions based on aggregate trends. To that effect, the UI/UX should be simple, intuitive but should also provide powerful functionality for uncovering trends.

More details about the required application can be found in the provided Conceptualization Questionnaire and in the click thru Wireframes (they have a Wireframe Notes section in the right side with detailed explanations for the application).

Requirements:

The Architecture will settle (by getting confirmations in the forums from the client, if different) on the technologies for:

1. the frontend:
   1. jQuery + Bootstrap + Angular are considered good by the client;
   2. the chart technology
2. the backend
   1. Node.js or JAX-RS Java based are accepted by the client
   2. expose the data to the frontend as JSON, by defining the REST API
3. the persistence (database server)
   1. Mongo, Couch or Cloudant
   2. Important thing is it should be loosely coupled to the implementation.

Also, the Architecture has these responsibilities:

1. will define the backend application
   1. define the interaction with the Watson Eco API
   2. define how to persist the data
2. will define the model needed by each page / widget and the filter conditions,
3. will determine how the news and notifications are handled,
4. will determine how to implement the layout algorithm for the boxes in the Web Application dashboard.

Additional Details:

1. Cache Watson Eco data
   1. We have potential for a performance impact with refreshing data. Currently, the Query Execution time is approximately between 2-5 seconds.
   2. So, we need to use the database for all real-time queries. This means that the application should query ALL the needed data Watson Eco API, then cache the data in a local database.
   3. Run a job to maintain some current/cached data every X minutes (configurable interval; express it in seconds, to be testable during development, but set it to a default of 5 minutes).
   4. Data can be refreshed on user request. Trigger the Job mentioned above from the Web application, from the Dashboard.
   5. Display how current the data is (date / time of last refresh or query execution). Dsiplay this information in the Web application, in the Dashboard.
2. The application should have the ability to create a snapshot (persist) of some summary data & the user + login information on-demand.
   1. Determine how best to get that information from back-end
3. The Client would like a phased approach to deployment.
4. A change from the current Wireframes: every partner can have multiple projects. At present a partner has only one, but moving forward we want to capture ability to have multi-projects selection per partner and per project there will be multiple services being leveraged. The client wants to add a project applications page as a gateway to the partner summary screen. It will represent partners with multiple projects. This aspect should be covered by the Architecture.

Future / Forward Looking Enhancements to be aware of: 

1. The application should be easy to enhance or extend due to changes or improvements to backend API. 
2. The Client is moving to a pull model than push model
3. System enhancements and upgrades should be releasable in phases. 
4. Client will be asking for more KPIs / Metrics / Notifications in Future Phase

Supporting Documents and Resources:

• Conceptualization Questionnaire (business_requirements_vin.docx)
• Click thru wireframes (Wireframe.zip).
• Web Design based on the Wireframes may be provided.
  • Whenever the frontend technology is determined, the Web UI Design should be converted into HTML using a Prototype challenge. The competitors should take into accoun the fact that the HTML pages will be available for the Assemblies produced by the Architecture, when determining the scope of the Assemblies.
• Access to the Watson Eco API's, or mocks, or sample data for community will be provided in the forums.
  If mock data is provided, it might help to expose the data through a server, in order to simulate the RESTful Watson Eco API's (we use only GET, as we do queries), so this aspect should be considered as part of the Architecture, in order to be able to develop the application.

 

Final Submission Guidelines

Using the provided documentation, competitors will complete the architecture deliverables (https://apps.topcoder.com/wiki/display/tc/Module+Architecture+Tutorial+-+Deliverables).

1. Sequence Diagrams
2. Interface Diagrams with detailed implementation notes
3. Assembly Specifications
4. ERD for the database