Data Included In Version 1 of the Estimation/Project Management OSLC Spec

Should the OSLC spec for estimation and project management resources include both project management information and estimation information? Eventually, of course, the answer is "of course"...but what should we attempt early? Here are some thoughts; please add your comments.

Based primarily on the practicality of what we can expect will be implemented in the next year, I believe that the focus should be on two key questions: "What data derived from or included in an estimate is of specific interest to the project manager plus what will the project manager DO with that data?" and "What data about the project is needed to produce an estimate?" rather than a complete description within the OSLC specification of all estimation data and project data. This means the spec won't be complete--that's inherent in the OSLC methods of "scope small and implement quickly".

This does not mean we can do this without exploring beyond these boundaries. The data model that we have started reviewing (but that review and revision is nowhere near complete) is needed, as are the use case specifications(which are also incomplete). We need to understand the process and data used by estimators and project managers in some detail to narrow down on the desired scope. This exploration will inevitably include data we will conclude belongs "just to the project management tool" and data we will conclude belongs "just to the estimation tool" that we find out we don't need in the spec, but we cannot discover and narrow down on what we do need without that. But while doing that wider exploration, we should ask the two key questions and to help understand what we've learned about the data and process.

It does mean that the "project" resource definition will need to be expanded later. Since the estimate is in context of a project, the full project resource definition should eventually provide access to the related estimation data. This can take several forms (direct embedding or URLs to related resources) and can be implemented in several ways (provided by a separate service implemented by estimation tools or combined into the service implemented by project management tools--see the architecture discussion). We do not have to settle this yet; there are advantages to remaining flexible on these architecture questions.

Users of the project management and estimation tools will not be "left hanging" by the partial implementation. The estimation suites already provide not only the sophisticated computation engine that's needed, but they also provide user interfaces for displaying (and entering) the data that have been "customer tested" for many years. While the eventual promise of full OSLC implementations may permit "surfing" among tools at the click of a REST based URL, users who have both project management tools and estimation tools can navigate in more "old fashioned" ways (or more politely, perhaps, more "traditional" ways) among the tools to get the information they need.

Question: Should we duplicate data among the tools? One answer to the "architecture" question may be that estimation data and project management data are either co-located in a single database managed by one of the tools, or distributed to federated databases but accessible and visible from either tool. But with the current architecture and capabilities of the available tools, this is not the case. So for each tool to use information from the other, there may need to be some duplication of data. I believe we should scope the version 1 spec to minimize this need for duplication but not be afraid of it when needed.

Note that the two key questions in bold above don't automatically imply duplicated data. In some cases, the estimation tool may derive data of interest to the project management tool that is pushed to the project management system and managed there, and not stored directly by the estimation tool itself. An example might be some details of a work breakdown structure that are derived from an estimate and pushed to the project management system. The estimation system may need to maintain a "local copy" (i.e. in it's own database) for technical reasons, or it may just be able to re-read it from the project management system if needed. Another example may be that the estimation system provides an "alert" of some sort to the project management system, based on some policy about when the project manager should be alerted that a project is moving "out of control," but it may not need to store the alert itself. Likewise, the estimation tool may be able to pull some data from the project managment tool, say about size or quality of a project that are derived from information the project management system either owns or has access from other tools. The estimation systems stores and acts on the derived information, but the dervied information may not be stored directly by the project management system.

However, it's also possible that there is some duplicated data. For example, the probability distribution of likely completion dates computed by the estimation tool may be of direct interest to the portfolio manager making a decision about whether a proposal should be chartered as a project. This may also include some information about the assumptions ("inputs") that went into this estimate. The current architecture of the tools involved may require that this is duplicated in the portfolio management system, and even that a display is provided in that tool as well as the estimation tool: having this particular data "directly accessible" may be important enough to justify the duplication.

So the two key questions result in identifying data that should be exchanged through the OSLC interface between the classes of tools, and (short term at least!) will include both derived data that is unique to each type of tool, as well as data that must currently be duplicated in both tools.

We should do our best to define the spec to finess the issue of where the data stored: Having data in the resource representation used in the OSLC spec does NOT imply which database stores the data--the resource representation passed in the REST calls does not have to be the data structure stored by the tool. So if we're "clever" (or "smart" if that seems like relying on luck), we will define the interface to allow the both current architectures that can be implemented now and future architectures that may be more elegant.

It will certainly help with this goal to keep the spec smaller rather than more comprehensive at first to avoid incompatible changes in the future. In particular, we should avoid data that will need to be duplicated to be implemented in current tool architectures except where duplicating it really adds power to the tool users as opposed to just using both tools. Understanding the data model and use cases, and then NARROWING DOWN on the two key questions will help us build something useful now that can be enhanced later.