By Mario Cardinal

March 2008

Table of Contents

The three types of architect
Three characteristics differentiate a team from a group of individuals
Roles and responsibilities of the team
The hidden roles of the software architect
Conclusion
About the Author

Summary: This paper presents the full spectrum of roles that software architects must fulfill when building enterprise applications.

An enterprise application is a software application intended for use inside an organization; the application must work within an existing architecture and be capable of being deployed and supported by an internal IT staff. Enterprise applications exist only to support the organization and its activities, or to help change the way business is performed. Developing for the enterprise is a very different challenge than building standalone applications. We start down the enterprise path as soon as we have to share resources, such as a relational database, among a large number of users, typically over a computer network.

To identify the various roles that a software architect must perform daily, I will make use of my personal experience. I have designed large-scale information systems for almost 20 years. As a software architect, I am responsible for conceiving a technical solution to support, automate, or even totally change the business processes of my clients. At present, I am an independent senior consultant working for the largest institutional funds manager in Canada and also for one of Canada’s leading financial institutions.

The three types of architect

This paper targets software architects, who perform different duties than enterprise or infrastructure architects.

Enterprise architects ensure convergence between business needs and technologies by establishing architectural guidelines such as enterprise conceptual data models or, in service-oriented environments, business service interfaces. For each project, they must validate that the technical solution design by the software architect complies with the corporation’s network policies and capabilities. It is interesting to note that the job of the enterprise architect is not terribly technical: It requires technical understanding, but to an equal degree it requires understanding business issues and business needs.

Infrastructure architects, on the other hand, are highly technical. They ensure the safe and productive deployment and operation of enterprise applications. This involves managing hardware, network and operating systems, as well as the so-called infrastructure services, including security, logging, and error management.

Software architects design the technical solution of the entire application. The logical and physical structure that they conceive must simplify the technical work and be within the technical capabilities of the development team.

Software architects must work hand-in-hand with enterprise and infrastructure architects.

Three characteristics differentiate a team from a group of individuals

Software architects are a vital part of the team responsible for building an enterprise application. The people involve with software architecture must not only possess technical leadership but also strong capabilities to work with a team of peers.

A group of individuals is not a team. Activities such as communication, sharing, mutual support, respect and appreciation of others can turn a group of individuals into a team. However, for a team to function there must be an additional element, an element of cohesion, what I call a collective intelligence. This collective intelligence indicates the cognitive capacities of the group and results from many interactions among its members.

A team is a community of interests characterized by qualified individuals with credible roles, a common goal and a shared leadership. Here are three characteristics of teams in greater detail:

Credible membership

There is only one selection criteria within a team: competency. The team is defined by a restricted set of roles. A role represents a type of expertise necessary to complete the project. An individual will be recognized as member of the team only if he or she offers competencies to achieve one or more roles.

In the achievement of a role, each individual stands in relation to one or more other individuals in the group. The individuals will collaborate with each other if they perceive that they can achieve their roles more effectively through collaboration. Team members who lack credibility will cause the team to collaborate poorly, and therefore the team will display a weaker collective intelligence.

Objectives recognized by all members

Each individual is an expert in his or her field, but possesses only a local and limited vision of the work of other team members. The only point anchoring the entire team, which is shared by all its members, is the common vision. In a community of interests, we share this common vision and we ask team members one simple question: “Does the work that I am doing help the team to achieve the common goal?”

Leadership shared by all members

One finds a collective intelligence within a team if the members agree to assume leadership roles. A leader is not a top-down manager who makes all decisions. This type of autocratic leadership does not lead to the creation of a team. In a team, there are various leadership roles that may change according to the situation. The most typical leadership roles are facilitator, public character, gatekeeper, matron, wise fool and mythical figure.

Here are the details of the leadership roles on a team:

• The facilitator: Animates, regularizes and facilitates the workflow among team members, while protecting and even reinforcing the trust relationships among members.
• The public character: This is the information specialist who likes to share knowledge. The public character is effective in identifying the information necessary for the good of the project.
• The gatekeeper: Protects team members from external interruptions that would distract the team and bring little value to the project.
• The matron: Organizes the social and interpersonal activities necessary to weld the team together and build its spirit.
• The wise fool: Defuses conflict situations using humor, and may say with impunity things that nobody else on the team dares say.
• The mythical figure: Recognized for past successes, vast experience and practical expertise.

These leadership roles support the emergence of a community of interests that has the following attributes:

• Free membership: Membership in the group is founded on a common vision and a mutual confidence among members.
• Horizontal structure: The rules, both tacit and explicit, are the same for all team members.
• Dynamic organization: The distribution of roles is wholly voluntary and is based on the members’ competencies.
• Collective management: Members are autonomous and responsible for their own actions. Strategic decisions are based on consensus decision-making.

Roles and responsibilities of the team

The team is defined by a restricted set of roles. A role represents a type of expertise necessary to complete the project. There are three main roles, each of which has several sub-roles:

1.      Customer roles, responsible for expressing the requirements of the solution.

2.      Technical roles, responsible for developing the solution.

3.      Support roles, responsible for facilitating the work of the members of the team.

Here are the details of each category:

Customer roles

These are roles of the customer:

• Purchaser: Pays for the project and seeks to obtain the maximum value for end users.
• End users: Use the application in their day-to-day jobs.
• Pilot: Responsible for final acceptance testing of the application before its deployment in production.

There are also some roles that have direct links to the customer, but are supported by the IT staff:

• Business analyst: Creates use case scenarios, documents business processes and designs the data model.
• UI designer: Conceives the user interface.
• Trainer: Teaches end users how to use the application.
• Technical writer: Writes user, installation and operating guides.
• Customer support: Helps end users to use the application more efficiently.

Technical roles

Persons with technical roles focus on conceiving a solution that meets the customer’s requirements. Five technical roles are necessary for carrying out a project efficiently:

• Software architect: Conceives a solution that the technical team can create.
• .NET developer: Designs and builds components and unit tests them; also corrects bugs assigned by testers.
• Database developer: Conceives the database schema, and designs, builds and unit tests stored procedures; also corrects bugs associated with the database.
• Tester: Tests use case scenarios worked out by the business analyst; for each failure, the tester opens a bug, assigns it to a developer, and closes it when it is resolved.
• Deployment specialist: Builds and deploys the application using source control management and build tools. Also automates build and deployment tasks by using scripts.

Support roles

These two support roles facilitate the work of team members:

• Project manager: In addition to stating the vision of the project and selecting the members of the team, the project manager plans and guides the various iterations.
• Administrative assistant: Provides administrative support to the project.

The hidden roles of the software architect

Now that we have explained the roles and responsibilities of the team and have differentiated a team from a group of individuals, it is now time to discuss the hidden roles that the software architect must carry out in order to lead a team efficiently. These hidden roles are three leadership roles:

• Technical facilitator: Once a technical solution is identified, the software architect facilitates the technical work among the team’s members, while simultaneously protecting and even reinforcing the trust relationships in the team. With this intention, the architect must set up the development infrastructure; lay down coding rules, nomenclatures and design principles; and provide architectural guidance. More often than not, since the role of deployment specialist is not an official role within the development team, the software architect also builds and deploys the application. This may explain why so many software architects in the .NET community also are experts with Microsoft® Visual Studio® Team Foundation Server and Visual Studio Team Build.
• Public character: The software architect must be an information specialist who enjoys sharing knowledge, and is recognized for vast experience and expertise. The software architect must know how to find the information necessary for keeping the project moving ahead, identify a technical solution for a specific problem, and validate the technical feasibility of the solution. This is the main reason why software architects may still write code in a project: they need to build a prototype or build a proof of concept in order to efficiently transfer technical knowledge to the team. The software architect fulfills this role by being a technical mentor who raises team members’ competencies and uses his expertise to guide and assist the team in realizing the project.
• Gatekeeper: The software architect protects team members from external forces that could distract them and would bring little value to the project. For example, the software architect manages all interactions with the internal IT staff. Whether the issue relates to the deployment and operation of the application, or to the development infrastructure, the software architect takes responsibility and leaves the other team members free to do their jobs.

Conclusion

The roles that software architects must fill when building enterprise applications are not only technical, but strongly associated with leadership. An efficient software architect not only designs a technical solution, he or she is a technical facilitator, a public character, and a gatekeeper for the team.

About the Author

Mario Cardinal is an independent senior consultant specializing in software architecture with agile processes and Microsoft Team System. He has almost 20 years of experience in designing large-scale information systems. For the third year in a row, he has received Microsoft’s Most Valuable Professional (MVP) award in the competency of Solutions Architect. He is a member of the Microsoft VSTS Customer Advisory Council. He leads the architecture interest group of the Montreal Visual Studio User Group and is the architecture track tech chair for the DevTeach Conference. Since 2004, he has hosted the Visual Studio Talk Show, a podcast about software development.

Mario holds Bachelor of Computer Engineering and Master of Technology Management degrees from the Ecole Polytechnique in Montreal, Canada. He also holds the titles of Certified ScrumMaster (CSM), Microsoft Certified Technology Specialist (Team Foundation Server), and Microsoft Certified Solution Developer. (www.mariocardinal.com).