Architecture: What Does it Mean to be a Software Architect? - Part III

Some people equate software architecture with the detailed design of things like services, classes, database tables, and so forth. In practice, software architecture actually encompasses much more, and the role of the architect oftentimes involves aspects of other competencies.

Unfortunately, for organizations that are unfamiliar with the function of architecture, problems can arise when the architect’s daily work leads them to become involved in functions that are traditionally performed by project managers, business analysts, and developers. This article takes an in depth look at some of the things architects do, where problems can arise between architects and other groups within an organization, and ways that the architect can become effective in their role.

What Does an Architect Do?

In my article What Does it Mean to be a Software Architect – Part I, I offered a very simple starting definition for an architect:

"1. A person who designs software systems and advises in the design of such systems. 2. A person who designs and guides a plan or undertaking related to software systems design."

I must emphasize that this was only a starting point. The follow-up question to this definition might be, “What do we mean by design, guide, and plan?” In response to this question, here are a few things that the architect might provide guidance and plans for:

• The Creation, Capture, and Management of Business Requirements
• Project Management Plans
• Architecture Plans

The Creation, Capture, and Management of Business Requirements

Software architects oftentimes play an integral role in the elicitation and organization of business requirements. The premise here is that the purpose of architecture is to ensure that the business needs are fulfilled, and the resulting architecture must be directly influenced by the business requirements. Architects should, at the very least, be well-informed concerning the scope of business requirements to be addressed, must understand how product features map back to business requirements and their associated benefits, and must also be kept up-to-date concerning the evolution of the functional specifications for the proposed software product.

In many cases, the architect may perceive a need to provide consultation concerning the most effective ways to capture and manage these requirements. The reason that the architect may want to step in to provide such consultation is because they usually have gained significant experience as business analysts and have learned the right types of questions to ask that would in turn reveal the most beneficial architectural approaches.

Furthermore, effective architects know specifically what information software developers require in order to do their jobs and can help guide the capture of these specifications in such a way that the specs both confirm what the business users want, and also serve as practical tools that developers can refer to when moving forward with their design and development efforts.

Architects may also need to work with the analysts to manage the expectations of project stakeholders. While the analysts work closely with the business to define the product scope and requirements, oftentimes it is the architect that helps all parties understand the feasibility of achieving certain project goals given an understanding of the staffing, scheduling, funding, and technology constraints.

The architect can help the team understand what the selected technologies are capable of, how they might need to be extended or customized, and the related work effort that is implied by the functional specifications.

I would suggest that the best software architects are good businessmen (or women) and also happen to be excellent technologists.

Project Management Plans

Software architects typically have a unique perspective on the factors that impact the project’s schedule, budget, risks, and required resources. These factors include aspects of the solution design (discussed in the following section), the true nature of the business requirements, and the most effective means to staff development efforts to build what is described in the solution architecture.

Given this unique insight, I feel that software architects have an unwritten duty to provide consultation on how project plans, budgets, and staffing plans might be structured to achieve the goals of the architecture. The problem is that this consultation may be unsolicted and unwelcome, so be very careful in the way you present your suggestions.

Architecture Plans

This is the key concern of the architect. Here are some components of a typical architecture plan:

1. Non-functional or "Technical Requirements. These are sometime referred to as the system's "Quality of Service Attributes". A description of typical non-functional requirements can be found here under the heading of "Shared Goals".
2. A definition of the principles, standards, and guidelines that will guide the architecture. These items provide a compass or vision for the creation of everything that follows. 
3. The creation of a solution design intended to achieve the desired business requirements. The architect may be responsible or accountable for any of these, or might simply provide oversight on ...
   • The creation of Logical Models
   • The software design (i.e. logical and physical designs of services, classes, interfaces, database tables; the use of layers and patterns; the use of centralized vs. distributed logic; etc.)
   • The evaluation and selection of various technologies used to achieve certain functional or technical requirements
   • Trade-off decisions (re: Architectural Decisions and Their Consequences) that affect software design or the selection of various technologies
   • Application integration strategies
   • Physical deployment strategies (i.e. the design of the "Execution Architecture" upon which the components of the solution will run) 
   • "Buy, Borrow, or Build" decisions
4. Recommendations on product release strategies and versioning approaches. This may involve roadmaps that show how older versions of products evolve into or run in parallel with new versions of products.
5. The design of logical environments (e.g. design, integration, test/QA, staging, production), and the processes that govern the flow of software deliverables from one environment to the next. This also typically includes capacity planning requirements (i.e. recommendations concerning the sizing and deployment of hardware resources so that they will properly handle the projected user loads and disk requirements), and recommendations for the specific software and hardware to be used along with associated configurations for each logical environment.
6. Strategies to ensure proper governance of IT assets (re: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results).
7. The definition of principles, standards, and guidelines for design, coding, unit-testing, and build processes for the project or the organization.
8. The evaluation and selection of development related tools and technologies (i.e. integrated development environments like Visual Studio Team System, source-code management, productivity tools, 3rd party components and libraries, etc.), and the definition of related processes (e.g. merge/branch processes for source-code management).
9. Data conversion requirements. This is an oftentimes forgotten necessity when migrating from older versions of products to newer ones. Architects must determine if data must be converted, and how that conversion will take place.

Depending upon what type of architect you are, you may or may not be involved in the coding and unit-testing of some of the more complex areas of the system. These areas are typically foundational in nature (e.g. base class libraries, frameworks, cross-cutting concerns like authentication and authorization, encryption, localization, diagnostics and logging, exception management, interprocess communications, etc.).

Whose Job is it Anyway?

It’s not unusual for architects to encounter resistance or incur a fair amount of angst in organizations that have either launched an independent architecture team or are unfamiliar with the function of architecture. Given that the architect’s unique perspective and experience can not only help analysts capture more useful business requirements but can also be leveraged to develop effective project plans, the architect, in the course of doing what they think ought to be done, may unwittingly wander into territories where they are not welcome.

The chilly reception these architects might encounter is oftentimes attributable to the fact that the role of the architect may not be fully understood by project managers or analysts. These individuals might feel a bit territorial over their turf, and may assume that the architect is trying to exert control in areas which are not within the domain of their primary responsibilities. 

At other times the architect may be overzealous in his or her efforts to help. These architects may, through their bold or outspoken suggestions, lead some to think that the architect perceives them as being less than capable. In all of these scenarios, the architect must keep their social antennae well tuned, and adapt their approach given the unique personalities on the team.

There’s also a grey area surrounding who owns various aspects of the solution design. Traditionally, this has been the province of the development teams, but in many organizations separate architecture teams are created in order to ensure that the design of software products really does contribute to the attainment of the business objectives outlined in the organization’s strategy and tactics. Independent architecture teams might also be formed to enforce governance around common mission-critical software functions.

The purpose of this governance is to ensure that key components of the software systems are properly managed so that they will continue to work properly and serve the business need over time even when change is introduced. The challenge to the architect is to show the development teams that they’re really there to help, not to put a damper on things.

When architects come onto the scene, development teams are oftentimes concerned that they may lose control or be slowed down by bureaucratic processes. It is true that the development groups might need to cede some control or at the very least collaborate in a few areas (e.g. the solution design) where they had sole discretion in the past. 

There is also a danger that governance processes, like design and code reviews, if done improperly, can put the brakes on the speed of development. However, if done correctly, governance processes can actually improve the speed of development by catching design mistakes earlier in the project, thus preventing costly downstream corrections.

Once again, the architect must gain the trust of the developers, and this can take some time. I’ve found that the best thing to do is to become a real member of the development team and be more collaborative in your approach. Dictatorial and “I know better than you” approaches never work very well if you want to gain trust.

Developers may feel that their importance in the organization diminishes when architects become involved. Nothing could be further from the truth. Even with architects in the picture, developers have a ton of work to do including coding the applications, conducting code reviews, creating and executing unit tests, documenting the software, and so on.

Developers still have a huge opportunity to be creative with their code, and I would also suggest that developers be given responsibility for the detailed design of classes and such, with a bit of coaching from time to time from the architect. In the end, the development organizations are responsible for delivering the software product, so it is usually wise to let the developer teams create their own software development plans and execute upon them.

Another concern from developers is that they may see architects as ivory tower academics with no practical real-world experience who attempt to foist their ideas upon the developer teams. This can be because architects tend to talk about very abstract things like patterns, draw a lot of pictures, and may not code as much as the developers do. It is true that some architects haven’t come up through the coding ranks. I would agree that the best architects do have real world experience and should have cranked out a lot of code in their time. Here again, the architect needs to build trust, and this takes time, patience, and a commitment to working as a collaborative team member.

Architects might feel that they have to do all of the work involved in producing Architecture plans, but the best results are usually achieved when the work is shared and the Architect serves as a guide, overseer, and mentor. For example, while the architect might provide an outline for the logical layers and high-level designs, it’s usually best if detailed design (including physical design) is left to the developers. 

The architect can, in this scenario, provide advice concerning design approaches that will be beneficial or problematic in the long run, and can also give ideas about the trade-offs that might go along with such decisions. The goal of the architect should be to help all developers become more adept at software design, and to learn the techniques used to develop the artifacts in the Architecture plan.

Here’s an acronym you can use to help you determine "whose job it is" ... RACI:

• Responsible: The person(s) who performs a given task

• Accountable: The person(s) who must answer for the results of given tasks. This person usually signs off on the work performed by those who are responsible for certain tasks

• Consulted: The person(s) whose input should or must be solicited

• Informed: The person(s) who should be provided status on the task, but may not need to be consulted

When there are questions about your role as an architect, it’s definitely a good thing to talk openly about who is responsible, accountable, consulted, and informed. All too often, architects, project managers, analysts, and development leads make innocent assumptions on these things, and problems in team relationships inevitably follow.

Lessons for the Architect from the School of Life

Life provides the best lessons. I’ve made a lot of mistakes over the years, and admittedly still do. Here are a few pearls of wisdom I’ve picked up along the way; sometimes I even remember to live by these ideas:  

• The Hard Skills are the Soft Skills. Technology is the easy part; working well with people is the real challenge and reward.

• Architects achieve better results when they think of themselves as servants whose mission it is to help others to be successful.

• Know who your constituents are, and learn to become more aware of when you might be stepping into their territory. Recognize that it can be natural for people to be somewhat territorial over things; consider how you might feel if an architect came on the scene providing direction to you on things you’ve been responsible for.

• Regardless what people say (about teamwork), few people want to have dependencies on others, and in some organizations collaboration only occurs when the individuals are coerced from above. If groups or individuals are resistant to you, it might be because they perceive that you might be an obstacle for them, even if you don't intend any such thing.

• Architects need to be extremely careful when offering criticism, but must be prepared to receive endless criticism. If you don’t like being questioned, then architecture might not be for you.

• Don’t be attached to showing people the right way to do things.

• You don’t always have to be right. Know when to let things go; not everything is of equal importance.

• Architects tend to have a much harder time achieving success when they seek glory. Things tend to work out much better if you let others have the credit. People will know, in the end, that you an integral force that facilitated successful efforts.

• Know the boundaries of your authority. If your role is to consult, then all you can do is suggest certain approaches. In such a scenario you would be wise to not insist that things be done a certain way.

• Just as parents sometimes need to let children go their own way and learn through their mistakes, architects need to become comfortable with letting their constituents make mistakes, unless of course a catastrophe seems to be in the making. If your constituents want to do their own thing against your best advice, you would be wise to be supportive of them.

• When making recommendations, architects should provide real evidence and data to back up their suggestions. Don’t offer unfounded claims or simply make emotional appeals.

• Avoid using email or Instant Messaging to discuss potentially contentious or sensitive issues. It's all too easy to be misunderstood when using the written word.

• Architects must be keenly aware of the politics of the organization, but should not get involved. Be loyal to all your constituents, don’t play sides, and never ever gossip.

• Architects are oftentimes so eager to help or share their ideas that they forget to shut up. Architects must practice how to listen more than they talk.

• Architects must develop high degrees of patience. Not everyone has similar backgrounds or experience, and it can take a long time to impart new ways of looking at things.