[stp-pmc] Roadmap time - and user/role focus

[Oisin Hurley <ohurley@xxxxxxxx>]

Hi guys,
We need to plan our M1, now that we have automated build capability
in place. Because we have (potentially) a very large scope of project
capability, we need to focus on some very real targets, things that
make sense to fill in expectations of the project. I'm making a proposal
now that we do this by generating use-cases from a set of roles and
then use the milestones approach to deliver on these use-cases in
a 'horizontal' fashion - i.e. fill our use-cases for all roles rather
than favoring any particular role.

I would like your opinion on this divide-and-conquer strategy. Please
note that I don't think that this should be a construct-all-of-the-use-
cases-up-front-before-writing-a-line-of-code approach. Flexibility is
key here.

Here are the roles that I've been thinking about. They are drawn from
my customer experience, some enterprise tools and from standards work
(with a particular bent towards the roles that have been presented
as part of the SCA policies development). With the proviso that this
general approach is considered valid, then I'd like us to flesh these
out more on the wiki. In the meantime, let the list know what you think.
[names are provisional]

-> SO Application Architect

This role is responsible for designing the assemblies, and adjudging
the requirements for service interaction and applying pre-defined
policy sets for the architecture. In a top-down approach to developing
the application, this role will also be responsible for interface-first
design. In a bottom-up approach, this role will be responsible for
extracting the interface information from existing artifacts. The
SOAA should be able to apply policies developed by a Policy Architect.

-> Application Developer

This is the pure developer role, which is responsible for the creation
of the implementation artifacts needed to develop the solution. In real
life, this role could very well be performed by someone who is also
the SO Application Architect. It should however, be separable,
so that many Application Developers could be brought together to provide
support for a single SO Application Architect.

-> Domain Expert / Policy Architect

This role is responsible for the development of policies with respect
to a particular domain. So, for example, this role would define when
services should be transactional, and what the authentication policies
are for an application. This role is separate from the previous two by
the fact that it is a horizontal responsibility within the IT  
origanization,
all applications that are to be deployed will be affected by decisions
made by the DE/PA.

-> Deployer

This role is all about binding the logical description of a business
application (and that means all the statements about implementation,
policy, binding etc) to a real-world information infrastructure wherein
it can run. This means making the decisions about what containers an
assembly may be deployed to, making sure that the required resources
are available and being responsible for making sure that run  
capabilities
are in place to meet SLAs etc.

-> IT officer

This role shares some responsibilities with the DE/PA role above. In an
IT workplace it is common for infrastructural elements to be defined at
an IT policy level - so a shop may decide that all applications to be
deployed should use message queueing, or should always use HTTPS to
communicate. This constrains the choices of the developers/architects
and of course the deployers too.

-> Ops/Sysadmin

This role is responsible for the ongoing maintenance of the business
application. This is an interesting one as there are many different
'types' of sysadmin, some with a strong dependence on tooling, such
as EMS, some with less of a dependence. In any case, we need to see
what tools this project should provide for these guys.

-> Auditor

This role has the interesting task of finding out what is going on in a
SOA deployment :) So, given a deployment that has been processed through
the STP tools, how can we validate it to be made aware of changes.