Savara 2: Architect roles
Currently there are six roles defined in the Architect category of the SAVARA SOA Development methodology. As mentioned in the other related thread, it is possible for a user to perform one or more roles, so this does not imply there are actually going to be six different people. However as part of this exercise, we will also examine whether all six roles make sense.
As mention in the Analyst roles thread, we will not currently consider business rules - so the Rule Architect will not be discussed here either. Also the role of the Process Engineer relates to defining the development process/methodology, which is being provided by Savara - so this role may either be redundant, or potentially still required to 'tweak' the methodology (which should also be supported by the tools). So these two roles won't be discussed further for now.
On reviewing the list of Architect roles, we are therefore left with Service-Oriented, Service, Software and Enterprise.
Service Oriented Architect
"This role is responsible for ensuring that the business processes are transformed technically to meet the needs of the business unit."
In the current methodology, the list of tasks that the Service Oriented Architect can perform is quite wide and varied, and also touches on what the Business Analyst and Enterprise Architect is likely to do. For example, it currently lists creating message examples and scenarios, which are really Business Analyst tasks, and define choreography model, which is the Enterprise Architects responsibility.
So I think this role should be removed. Therefore it won't be discussed further in this thread, unless there are any objections?
Enterprise Architect
"This role is performed by a technical architect who is familiar with the enterprise design standards and ensures that the principles of service-oriented architecture are applied to meet the enterprise's needs and assesses the middleware and technology platform needs of the enterprise." and also "The enterprise architect may also be responsible for the service inventory of the enterprise. This role can be expanded in larger organizations to domain-specific enterprise architects. Each would be responsible for a specific business area and the service inventory of that business area."
The methodology does not currently make it explicit in the description of the role, but the Enterprise Architect is responsible for defining the Choreography (dynamic behaviour) and Information (static data) models based on the information defined by the Business Analyst (e.g. message examples, scenarios, etc).
So therefore they will need to collaborate with one or more business analysts to identify issues in defining a global choreography model that meets the requirements defined in a range of scenarios used to describe the use cases for the system. If multiple business analysts dealing with different business units are involved, then it is possible that some refinement will be required of the example messages and scenarios, to identify common aspects for reuse, and therefore require those business analysts to make (or agree to) changes to their requirements artifacts. In some cases this will also need to be approved by the stakeholder(s).
The end result of the process is to have choreography and information models that can be successfully validated against all requirement's artifacts. This validation should be performed by both Business Analysts and Enterprise Architects, and the results (or current status of a particular stakeholder's requirements in terms of being satisfied) should be available to the relevant stakeholder(s). The stakeholder may or may not be interested in examining the choreography/information models.
Service Architect
"The Service Architect is responsible for the technical service contract and the logic design of the services." and also "This role is associated with service-oriented design, the physical design of services."
Although the Service Architect is "responsible" for the technical service contract, the "Testable Architecture" approach means that the definition of the service contract must be compatible with the behaviour as defined in the choreography and information models defined by the Enterprise Architect. Therefore this is a negotiation between the two roles, and the initial service contract would (most likely) be generated from the choreography model.
Therefore the main purpose of this role is the design of the services. This will involve collaboration with the Enterprise Architect on any aspects that impact the choreography model (which may also indirectly affect other services and therefore other Service Architects), and once the design has been completed, will involve collaboration with the Service Developers. In both these cases, the tools should support interactive review and editing, and record notes with the service design artifacts to record any decisions that would be made.
As with other architects, an approval process may be required involving the relevant parties that are impacted by the service design. Part of that approval process would potentially rely on the fact that it verified successfully against any preceding artifacts upon which it was dependent.
Software Architect
"This role has overall responsibility for coordinating the technical decisions which are expressed as the software architecture." and also "The Software Architect's responsibilities include identifying and documenting the architectural aspects of the business solution, including requirements, design, implementation, and deployment "views" of the system. This role balances the concerns of the business unit and the technology group."
Based on this description it is unclear whether this role is required, as the Testable Architecture approach is all about documenting artifacts through out the software development lifecycle. Again, if anyone believes there are any specific responsibilities associated with this role that are required, then please feel free to respond. Otherwise we can ignore this role for now.
