转贴: The role of a hands-on software architect

昨天看到一篇关于“软件架构师职责”的文章，个人觉得讲得蛮好的。作者将架构师的工作职责分为两个大部分：“架构的定义”以及“确保架构的正确实现”。毋庸置疑，架构设计是重要的，但确保好的架构设计被正确地实现和维护，对整个软件项目来说，也是有着举足轻重的地位。而这个第二部分，正是目前看过的关于软件架构师的书籍中很少涉及的部分。

原文出自http://www.codingthearchitecture.com/pages/book/role.html

The role of a hands-on software architect

What should a hands-on software architect do?

Becoming a software architect isn't something that simply happens overnight or with a promotion. It's a role, not a rank. It's an evolutionary process where you'll gradually gain the experience and confidence that you need to undertake the role. While the term "software developer" is fairly well understood, "software architect" isn't. This essay looks at the role I believe a good hands-on software architect should play on any software project.

Definition vs delivery

Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it's delivered. For the purposes of this essay, I'm going to assume that the software architect will be involved in both of these phases and present a summary of the important role that they should play. The following diagram summarises this.

 

Management of non-functional requirements

The first part of the role is about managing the non-functional requirements. Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or system qualities) that they need. Sometimes the stakeholders will tell us that "the system must be fast", but that's far too subjective. Non-functional requirements need to be specific, measurable, achievable and testable if we are going to satisfy them, plus we need to make sure that all of the important non-functional requirements are taken into account. This includes the common runtime characteristics such performance, scalability, availability and security through to the non-runtime characteristics such as audit, extensibility, internationalisation and localisation. Somebody needs to help the stakeholders refine the non-functional requirements, define them and challenge them when appropriate. After all, how many systems have you seen that genuinely need to be operational 24x7? Since most of the non-functional requirements are technical in nature, they often have a huge influence on the software architecture and the resulting solution needs to take them into account. For this reason alone, it makes sense that the software architect takes this on as a part of their role. Ultimately, the software architect needs to understand what it is they are building.

Architecture definition

With a full set of non-functional requirements defined, the next step is to start thinking about how you're going to solve the problems set out by the stakeholders and define the architecture. It's fair to say that every software system has an architecture, but not every software system has a defined architecture. And that's really the point here. The architecture definition process lets you think about how you're going to take the requirements plus any constraints imposed upon you and figure out how you're going to solve the problem. Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project. You need time to explicitly think about how your architecture is going to solve the problems set out by the stakeholders and unfortunately your architecture isn't going to evolve on its own. Somebody needs to take ownership of the architecture definition process and this falls squarely within the remit of the software architect. Defining architecture is an architect's job!

Technology selection

Technology selection is typically a fun exercise but it does have its fair set of challenges. For example, some organisations have a list of approved technologies that you are forced to choose from, while others have rules in place that don't allow open source technology with a specific licence to be used. Plus, then you have all of the other factors such as cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments and so on. The sum of these factors can often make a simple decision of choosing something like a rich client technology into a complete nightmare. And then there's the question of whether the technologies actually work. Many projects choose to use commercial and open source products because they believe the hype, but many projects have been burnt by this too. Few people seem to ask whether the technology actually works the way it is supposed to, and fewer prove that this is the case. Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. All technology decisions need to be made by taking all factors into account, and all technology decisions need to be reviewed and evaluated. This includes all of the major building blocks for a software project right down to the libraries and frameworks being introduced during the development. Somebody needs to take ownership of the technology selection process and again it should be the architect. If you're defining an architecture, you also need to be confident that the technology choices being made are the right ones. The architect should own the technical risk and the technology selection.

Architecture evaluation

What we've looked at so far will help you focus on building a good solution, but it doesn't guarantee success. Simply throwing together the best designs and the best technologies doesn't necessary mean that the overall architecture will be successful. The question that you need to ask yourself is this, does your architecture work? For me, an architecture works if it satisfies the non-functional requirements, provides the necessary foundation for the rest of the code and works as the platform for solving the underlying business problem. One of the biggest problems with software is that it's complex and abstract. The result of this is that it's hard to visualise the runtime characteristics of a piece of software from UML diagrams or even the code itself. Furthermore, I don't always trust myself to get it right first time. Throughout the software development lifecycle we undertake a number of different types of testing in order to give us confidence that the system we are delivering will work when rolled out. So why don't we do the same for our architectures? If I can test my architecture, then I can prove that it works. And if I can do this as early as possible, I can reduce the overall risk of project failure. Somebody needs to take ownership of the architecture evaluation and take responsibility for de-risking the architecture. Since the architect has defined the architecture, it makes sense for them to also make sure that it will work. Like a good chef, the architect should taste what they are producing.

Architecture collaboration

It's unusual for any software architecture to reside in isolation and there are a number of people that need to understand it. This ranges from the immediate development team who need to understand and buy in to the architecture, right through to the extended team of those people who will have an interest in the architecture from a security, database, operations, maintenance or support point of view. Somebody needs to take ownership of collaborating with these stakeholders and sharing the architectural vision to ensure that the architecture will successfully integrate with its environment. Again, this falls squarely within the role of the architect. As an architect, you need to make sure that the architecture you have defined is understood by everybody involved with making it a reality.

Ownership of the bigger picture

The things we've covered already fall into the "architecture definition" category but it's important that the architecture is carried through to a successful conclusion. In other words, somebody needs to own the bigger picture and sell the vision throughout the entirety of the software development lifecycle. More often than not, an architecture is defined and then passed over to a development team, effectively treating software development as a relay sport. This is counterproductive because a software architecture needs to be taken care of. Somebody needs to look after it, evolving it throughout the project if necessary. Somebody needs to take ownership of that bigger picture throughout the project and they also need to take responsibility for ensuring that it's delivered successfully. If the architect has defined an architecture, why shouldn't they own that architecture throughout the rest of the project?

Leadership

Owning the bigger picture is one aspect of technical leadership, but there are other things that need to be done during the delivery phase of a project. These include taking responsibility, providing technical guidance, making technical decisions and having the authority to make those decisions. Somebody needs to undertake the technical leadership to ensure everything is taken care of and that the team is being steered in the right direction on a continuous basis. The software architect position is inherently about leadership and while this sounds obvious, many project teams don't get the technical leadership that they need. This is a natural part of the architect's role, but just mind that gap.

Coaching and mentoring

Coaching and mentoring is an overlooked activity on most software development projects, with many team members not getting the support that they need. While technical leadership is about steering the project as a whole, there are times when individuals need assistance. In addition to this, coaching and mentoring provides a way to enhance people's skills and to help them improve their own careers. Sometimes this assistance is of a technical nature, and sometimes it's more about the softer skills. Certainly from a technical perspective though, why shouldn't the architect help out with the coaching and mentoring? Most architects that I know have got to where they are because they have a great deal of experience in one or more technical areas. If this is the case, why shouldn't those architects share some of their vast experience and help others out.

Quality assurance

Even with the best architecture and leadership in the world, poor delivery can cause an otherwise successful project to fail. Quality assurance is a large part of an architect's role, but it's more than just doing code reviews. For example, you need a baseline to assure against, and this means the introduction of standards and working practices. From a software development perspective, these could include coding standards, design principles and source code analysis tools through to the use of continuous integration, automated unit testing and code coverage tools. It's safe to say that most projects don't do enough quality assurance, and therefore you need to figure out what's important and make sure that it's sufficiently assured. For me, the important parts of a project are anything that is architecturally significant, business critical, complex or highly visible. You just need to be pragmatic and realise that you can't necessarily assure everything.

Design, development and testing

The last thing that falls squarely within the role of a hands-on software architect is design, development and testing. Being a hands-on architect doesn't necessarily mean that you have to get involved in the day-to-day coding tasks, but it does mean that you're continuously engaged in the project, actively helping to shape and deliver it. Having said that, why shouldn't the day-to-day coding activities be a part of an architect's role? Most architects are experienced coders, so it makes sense to keep those skills up-to-date. In addition, the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective. Many companies have policies that prevent software architects from engaging in these coding activities because their architects are "too valuable to undertake that commodity work". Clearly this is the wrong attitude ... why let your architects put all that effort into defining the architecture if you're not going to let them contribute to its successful delivery? Of course, there are situations where it's not practical to get involved at the code level. For example, a large project generally means a bigger "bigger" picture to take care of and there may be times when you just don't have the time. But generally speaking, an architect that codes is a more effective and happier architect. You shouldn't necessarily rule out coding just because "you're an architect".

Summary

The things covered in this essay are what I consider to be the core parts of being a hands-on software architect. Although architecture definition and technology selection are seen as being the fun parts, a successful architecture is about much more. Quite simply, the architect has the skills and experience required to pick up the other things that contribute to the success of the architecture, and a successful architecture contributes to a successful project.