Architecture of the OSLC services for estimation and project management

The OSLC workgroup on Estimation and Measurement in the context of Project Management made some initial decisions about the scope of the initial version of the OSLC interface we are defining. These decisions need some explanation. There is also a key related issue about the "shape" of the resources that should be defined in the early versions of this interface (and this link is also at the end of this article).

The OSLC effort in general is guided by some principles that may be stated better elsewhere, but have this effect:

a) The architecture is resource oriented: "What resources are needed and how do you create, read, update them?" are the primary questions, not "what functions do you need?" (Note 1: "Resource" in this context means "a type of information" not "a person who works on a project"---interestingly and maximally confusingly, resource/a person who works on a project is one of the key resources/type of information involved in the discussion in this particular topic, so ALWAYS be careful that you understand which meaning is intended!) (Note 2: Distributed architectures based primarily on cohesive, loosely coupled resource groupings has been a major interest of mine for many years, but I will attempt, perhaps not always sucessfully, not to let this particular discussion get distracted by the facsinating abstract issues involved.)

b) The interfaces will be "scoped small" so that we do not take "20 years" (as Steve Abrams often says) in an attempt to define everything at once, but rather define pieces at a time quickly.

c) Besides quickly getting to the specification of the interfaces, we want to have the specification quickly tested in practice by having a real implementation in an available tool by a provider of the service that is also consumed in an available tool.

These three principles went into the decision about the current scope for the estimation workgroup. The answer to "why is it the way it is" is a practical decision to get quickly to a definition that will be tested through implementation.

This group is looking at the interaction between two classes of software development tools: project/portfolio management tools and estimation suites. So the key question about the architecture is "one service or two?", or in light of principle (a), "One primary resource or two?" You could argue either way:

Service Architecture 1) Estimates are just part of the primary resource "Project": An estimate is done in context of a project: "How long do we expect this project to take? How many resources of various types do I need for this project? Is the project on track?"

Service Architecture 2) "Project" and "Estimate" should be separate services, with relationships to one another (in fact, probably tight relationships--oops, I'm dangerously close to veering off into general distributed architecture issues). The two types of tools are separate in the industry. The project management tools don't have the sophisticated calculations and displays of estimates, and the estimation suites don't attempt project management functions like resource leveling (in the "person who works on a project" sence) or sophisticated task dependency management. Each type of tool manages the creation, manipulation and display of a set of data ("resource" in the type of information sense) and should provide a service to allow other tools (in particular, each other!) access to those resources. Each also interacts with other types of tools that could use those services.

This workgroup actually has not made a firm decision about this! But we have decided to first focus on a Project Management service for a practical reason: The workgroup contains a Project Management tool vendor that is committed to implementing an OSLC-based project managment service, and multiple Estimation vendors that are committed to consuming said project management services when they are available. So this scope meets the principles of "start small and implement quickly".

We do not yet have commitment from the estimation vendors to produce an OSLC Estimation service. That's not to say this won't be done in the future, nor is it to say whether or not it is a good idea, thus taking a stand on Service Architecture 1 vs. Service Architecture 2. It's only a "point-in-time" decision about what will pay off quickly both for the architecture and the business interests of the vendors involved.

While we have discussed this much as a workgroup (though perhaps not in this detail), we have not really discussed the issue of what the scope of data should be included in this version of the OSLC specification. Some thoughts on this and how it relates to the work done so far in the workgroup can be found here.