Savara 1 is essentially a small set of Eclipse based tools looking to provide some support for the Testable Architecture methodology. It is a bit more than that, as it also includes runtime validation of Web Services/BPEL and ESB services - but Testable Architecture is mainly about evolving the way we build systems at the design-time phase of the software development lifecycle.

The goal of Savara 2 is to break free from purely Eclipse based tooling, to better support the range of users that are the target audience for Testable Architecture. Eclipse will still be important, but we need to move away from the IDE (developer) style tooling, and support improved collaboration between users.

The exact technology that will be used is still up for debate. However we first need to understand who the target users will be, and what features they require from the tooling.

The SAVARA SOA Development methodology provides a set of roles in the "Basic SOA Roles" section. These are a good starting point, however we need to determine whether some of these roles are actually required.

In terms of the general mechanism, we should allow roles to be created and removed as required, so that an organisation can determine how it wishes to use/adapt the methodology. A role can have associated capabilities, and users can be associated with one or more roles. So this is not about defining a fixed set of roles that cannot be changed, but (a) getting an idea of what roles should be provided "out of the box", and (b) what capabilities are likely to be required by each of the roles.

Rather than discuss all of the roles in a single thread, I will create individual threads (either based on category or individual roles) to make it easier to discuss each role in insolation.