In the SOA Development methodology, it defines three analyst roles:

Business Analyst

"This role has an extensive knowledge of the business domain as well as a technical background that includes business process modeling."

This is an important role - someone that works with the stakeholder/business user to understand their requirements and encode them in a machine readable form.

So in terms of the Testable Architecture tooling, this would mainly resolve around defining example messages and scenarios (sequence diagrams referencing the example messages). For now we will leave business rules for a separate discussion.

In terms of capabilities, the business analyst obviously needs access to a message and scenario editor. As they will be collaborating with the business user/stakeholder, they also need to be able to document decisions, alternatives considered, open questions, etc that arose through the analysis process.

In some cases the analyst and user may be geographically distributed, and therefore the tooling needs to work well in a distributed environment, enabling sharing of information as it is being defined, and even realtime editing by multiple users.

Considering this is the first stage of the development lifecycle, documenting the business user's requirements in a well defined manner, it may also be appropriate to have some official mechanism for recording the user's sign-off.

Service Analyst

"This role requires proficiency in all aspects of service-oriented analysis. This proficiency includes the identification of service candidates, service capability candidates, and service composition candidates."

In the simpliest case there should be no need for a service analyst, as the set of potential services should directly map to the set of participants in the choreography description.

However in more complex situations, where the responsibilities of a single participant are considered too overloaded, or inappropriately decomposed, or where refactoring the choreography could lead to better reuse of existing services, then the service analyst role may be relevant. In this capacity, a user would need to negotiate with the Enterprise Architect (responsible for the choreography model) to highlight the potential changes and their benefits.

The most productive way would be for:

(1) the Service and Enterprise Analyst to collaboratively make changes to the choreography model to achieve the desired result, or

(2) for the Service Analyst to provide the Enterprise Analyst with a proposed choreography model, and for the Enterprise Analyst to simply review the differences and understand the impact on the requirements and any other services.

So the capabilities required here are:

- collaboration support, including documenting decisions

- comparison tools for understanding how two versions of the model differ

- validation tools against other models (e.g. scenarios for requirements, service contracts, etc) to understand impact of changes

- ability to test models without having to commit or accept changes

System Analyst

"The role of the System Analyst is to work with the Business Analyst, the Service Architect, and the Enterprise Architect to determine which legacy assets should become services and determines the impact of new services on legacy systems."

Unclear whether this role is going to be relevant in a Testable Architecture.

More than before, it should be possible to determine whether legacy services are suitable for reuse based on a more detailed understanding of their stateful behaviour.

So if required, this role will need either a static or dynamic validation capability. Static validation can be used where the potential reusable services have an associated behavioural description, comparing against the required behaviour as defined in the choreography (architecture). Dynamic validatoin can be performed in situations where static validation is not possible, or in addition to static validation, by using the information defined in the scenarios (i.e. interactions against the required service participant, including the example messages to use/compare with).