| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:RoleDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="_Y6tLEKbXEdm9d-ircVOUCA" |
| name="architect,_0X9iEMlgEdmt3adZL5Dmdw" guid="_Y6tLEKbXEdm9d-ircVOUCA" changeDate="2008-10-14T14:08:08.003-0700" |
| version="1.0.0"> |
| <mainDescription><p>
 |
| The person in this role leads or coordinates the technical design of the system and has overall responsibility for
 |
| facilitating the major technical decisions expressed as software architecture. This typically includes identifying and
 |
| documenting the architecturally significant aspects of the system as views that describe requirements, design,
 |
| implementation, and deployment.
 |
| </p>
 |
| <p>
 |
| This role is also responsible for providing the rationale for these decisions, balancing the concerns of the various
 |
| stakeholders, reducing technical risks, and ensuring that decisions are effectively communicated, validated, and
 |
| followed.
 |
| </p>
 |
| <p>
 |
| This role works closely with&nbsp;project managers&nbsp;in staffing and planning the project, because it is recommended
 |
| that the team be organized around the architecture.
 |
| </p>
 |
| <p>
 |
| This role also works closely with&nbsp;analysts and developers&nbsp;to make sure that the architecturally significant
 |
| requirements are assigned to the proper components of the system.&nbsp;
 |
| </p></mainDescription> |
| <skills><p>
 |
| Architects must be well-rounded people with maturity, vision, and a depth of experience that allows for grasping issues
 |
| quickly and making educated, critical judgments in the absence of complete information. Specifically, the person must
 |
| possess this combination of qualifications:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <b>Experience</b> <strong>in both problem and software engineering domains</strong>, with evidence of a thorough
 |
| understanding of the requirements to solve the problem and active participation in software development. If there
 |
| is a team, this experience can be represented by different team members, but at least one person must be able to
 |
| describe the overall vision for the project.
 |
| </li>
 |
| <li>
 |
| <b>Leadership ability</b> to motivate and maintain momentum for the technical effort across the various teams and
 |
| to make critical decisions under pressure, plus make those decisions stick. To be effective, this role must have
 |
| the authority to make technical decisions. This role cannot lead by decree, but only by the consent of the rest of
 |
| the project team. To be effective, this&nbsp;person must earn the respect of the team members, project managers,
 |
| the customer, and the user community, as well as the management team.
 |
| </li>
 |
| <li>
 |
| <b>Excellent communication</b> <strong>skills</strong> to earn trust, persuade, motivate, and mentor. The person in
 |
| this role must have good communication skills, both verbally and in writing.
 |
| </li>
 |
| <li>
 |
| <b>Critical review skills</b> to make sure that the requirements to be built are clear and consistent and to make
 |
| sure that the developed system adheres to the architecture.&nbsp;
 |
| </li>
 |
| <li>
 |
| <b>Goal-oriented and proactive</b> <strong>orientation</strong> <b>with a relentless focus on
 |
| results.&nbsp;</b>This person is the technical driving force behind the project, not a visionary or dreamer. The
 |
| career of a successful architect is a long series of sub-optimal decisions made in uncertainty and under pressure.
 |
| Only those who can focus on doing what needs to be done will be successful.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| From an expertise standpoint, the Architect also needs to show both design and implementation abilities. However, from
 |
| the design perspective, the effective Architect typically exhibits these traits:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Tends to be a generalist, rather than a specialist, who knows many technologies at a high level rather than a few
 |
| technologies at the detailed level
 |
| </li>
 |
| <li>
 |
| Makes the broader technical decisions, thereby demonstrating broad knowledge and experience, as well as
 |
| communication and leadership skills
 |
| </li>
 |
| </ul></skills> |
| <assignmentApproaches><p>
 |
| The person in this role should be engaged in the project from start to finish.
 |
| </p>
 |
| <p>
 |
| For smaller projects, a single person can act as both Architect and project manager. However, it is better to have
 |
| these roles performed by different people to ensure that the pressures of one role does not cause neglect of the other
 |
| role.&nbsp;The Architect and Project Manager&nbsp;must work together closely.
 |
| </p>
 |
| <p>
 |
| For systems of scale, it is a common best practice to have an architecture board that is populated by the architects of
 |
| each system, plus one or two chief architects.&nbsp; In such cases, the members of the architecture board collectively
 |
| play the role of the Architect.
 |
| </p></assignmentApproaches> |
| </org.eclipse.epf.uma:RoleDescription> |
