【51CTO专访】一位从业16年的软件架构师，对这个行业的发展有什么看法？在8月的ArchSummit大会上，笔者跟大会的讲师之一，来自英国的 Simon Brown 简短的沟通了一下，了解到他眼中的敏捷，架构师，以及软件行业的发展。
Simon Brown
Simon Brown居住在泽西岛（海峡群岛），他是一名独立的顾问，且是编码架构（Coding the Architecture）网站的创始人，自称是写代码的软件架构师和明白架构的软件开发者。Simon有多次在微软.NET和Java平台上开发大型项目并取得成功的经验。现在，他也经常出席欧洲有关软件体系结构及其在现代软件开发团队中作用的论坛、演讲等。他同时是《面向开发者软件架构》一书的作者，该书目前正在Leanpub出版发售中。他目前也仍在编写代码。
以下是采访实录。
51CTO：Simon 你好，感谢接受51CTO的采访！
之前看到您分享的话题，提到团队实施敏捷的时候一定要确保团队里有足够的优秀工程师。你经常遇到那种团队还不成熟的时候就盲目实施敏捷的团队吗？
Simon：哦是的，这基本上是常态——不幸的常态。你看，敏捷宣言在去年已经十周年了，就理念而言它已经存在的足够久。大公司们想要实施敏捷，因为它透明，可交付，成本可控，进展速度快，并有持续的反馈。听起来十分美好。然而很多实施敏捷的团队会遇到一个问题，也是我经常被咨询的问题，就是他们对项目和文档的管理失去了把控。你看看Scrum，它提供了很多角色（profile），但对于如何运作项目的具体实践却没提到多少。敏捷过程还有其他的很多问题，人们在其中并不清楚自己应该专注于什么；他们过多的关注技巧，但是却忘记了很多基本的东西：安全，可扩展性……他们开始不做决策就闷头做事。我最近就遇到这样一个团队，他们跑过来跟我说，好吧，我们4个月前开始实施敏捷，做了不少轮的冲刺，然后就是，我们现在堆积了一堆技术负债，现在我们需要对所有的东西进行重构。要我说的话，如果他们在一开始多想想，那么现在也不会需要面对这样的一个问题了。
不过，这样的情况实在太多了。
51CTO：那么，你如何确保将一个可以看清全貌的人，比如一个架构师，放到这个团队里面来，就可以避免这种情况呢？
Simon：比如你有一个6人的团队。我们应该有安全需求，性能需求，可扩展性需求，或者其他复杂的功能需求，但是有时候我们会忘记这些需求。所以，需要有一个人在团队中，确保所有的人都按照上述这些需求来执行。这是单点的技术领袖。当然，你可以让多个人共同承担这个职责，不过大多数团队不是这样运作的。总之，有这样一个人的存在，就是为了确保团队成员们在需求的范围内行动。
51CTO：顺便提一句，英国的团队会有很多都处于这样一种混乱的状态吗？
Simon：哦是的，大部分团队都是。事实上，全世界都是一样的。
51CTO：之前看过您的博客，说不同的团队和工程师对架构师的定义都不一样。不过总的来说，架构师总该有一些共同的特性吧？比如职责，能力方面。您认为“架构师”应该知道些什么，应该做些什么？
Simon：怎么说呢，“架构师”这一词语本身对不同的人就有不同的意义。如果你去查找“架构师”的定义，更是会发现很多不同的定义。有一个组织叫做IASA，International Association of IT Architecture，他们以前叫做International Association of Software Architecture，不过后来更改了名称，希望将整个IT领域的架构定义整理到一起。定义一件东西总是充满争议，不过我倒是觉得大家不必对一个词语如此纠结。IASA的伙计们曾经定义了一个Business Tech Strategist（商业技术策略是）的职位——有这样一个职位又能意味着什么？
我当然也想创造出一些广为人接受的定义，不过我认为更重要的是，在一个团队当中，组织的定义是优先的。我们先定义我们需要做什么，有哪些责任，之后再将每一个责任分配给指定的一个人。这完全根据团队需求而定义的。
51CTO：您觉得像您这样独立工作的架构师，和那些专属在某个产品团队中的架构师有何不同？
Simon：我虽然是独立架构师，但是我工作的时候是跟团队一起的。如果要说区别的话，其实是面向客户的团队和做产品的团队之间的区别。职责相同，但优先度不同。如果你为客户构建系统，那么需求是相对固定的。然而如果你自己做产品，那就不一样了，你在前线，做出针对产品应该怎样做的各种决策；你需要考虑可扩展性，以及当你构建的时候可能会面临的变化。
51CTO：那么，您从1996年开始从事这个领域，到现在已经是16年。您有没有觉得哪段时间您的成长特别快的？
Simon：哦，我经历过负成长特别快的时段（笑）。当我刚刚被冠上架构师这个职位的时候，当时的我很迷茫，不知道应该做什么。那时候我每天画UML图，一边画一边想，好吧，我从一个码农转型成一个画图的了。这感觉不太对。它们之间究竟有什么联系？当时我觉得自己处于后退一步的状态。不过之后我发现，你要想看到更大的世界，是有必要往后退一步的。
这些年我接了不少项目，有模块设计，组件设计，服务设计等等。到头来，决定你成功还是失败的，都是这些小细节。如果你构建了一个系统，它的性能不怎么好，你需要一个有经验的人来帮你分析当中可能出现的问题。总之，有很多前进和倒退，我觉得这整个职业就是一个革命性的职业。我现在仍然在学习，比如安全机制是如何运作的，系统的交互机制，还有很多新鲜玩意儿，云计算，新的Web元素和服务……有如此多需要学习的新东西。身处软件行业的大潮中不是一件容易的事。学无止境。
51CTO：那么，您觉得软件领域这两三年的变化很快么？
Simon：当然，非常快。
51CTO：相比10年前呢？
Simon：我觉得10年前的这个行业就很快了。当时有互联网泡沫，我那时候在做Java，也遇到很多新的热词：Web，企业级Java，JavaBeans，Servlets，JSP，应用服务器，集群……当时的Java领域也是变化极快的。后来Java逐渐慢下来了，.NET又起来了；现在的云计算其实也是一样的，亚马逊有弹性云，VMware有Cloud Foundry，还有很多新平台出来……其实每个时代都很快。
51CTO：好的，那么最后一个问题。您本身了解很多方面的知识，您也提到架构师应该是T型人才（注：即在某方面技术专精，各方面技术精通）。那么，所有的开发者都应该朝这个方向发展么？
Simon：理想状态下，应该是的。
51CTO：那对于那些只会写代码的专才而言，以后还有什么发展空间么？
Simon：哦，当然有了！我们在敏捷理念中谈论啥都懂的专业人才，在理想世界中，每个人都是平等的，每个人都知道如何决策，如何照看各种构建的环境，以及如何做出东西来。然而，我们在现实世界。上面提到的东西很难实现。现实是你很难找到啥都懂的专业人才，能找到代码写得好的专才已经很难得了。你有什么样的人，什么样的团队，决定了你能做什么，该怎么做。如果你的人只是想专心写代码，他们不在乎要不要提高一个层次去看更加宏观的世界，这也没什么，挺好的。不要逼他们做他们不想做的事情，不要逼他们做决策。最可能的结果是，即使你去逼他们，他们也做不好。所以，还是让每个人发挥自己的特长就好。
Simon 在大会上的分享 PPT 可在线观看：
- How to design a secure architecture
下面是英文采访实录。
#p#
51CTO: A short question on your session this morning. so what I interpret is that teams should not go agile blindly when you don't have enough good people in the team. Do you always see this situation?
Simon: Yes, all the time, unfortunately. The Agile Manifesto was celebrating their 10th anniversary last year, so you know agile was established for a long time. Big companies want to adopt agile, because its transparency, deliverables, budget, moving fast, and getting feedbacks. And all that sounds pretty. People are struggling with the guidance when going agile, so one of the questions I had quite often is that, ok we are adopting agile, but we are struggling with project management and document assessment. And if you look at frameworks such as scrum, they give you profiles and lots of things, but less practices on how to run projects. There are other aspects of agile processes, people don't quite understand what they engage on, they put all the focus on the techniques, but they forget about the basics: they forget about security, scalability, they stop making decisions...they just rush into things. I ran into these teams recently, so one of the teams come and say, we adopted agile 4 months ago, we kept doing sprints, but now we have so many technical debt, and we need to re-architect everything. If they've come thinking up front, maybe they won't end up in that situation in the first place. It's very very common.
51CTO: So how can you make sure that when some one who can see from top to bottoms comes in, these things won't happen?
Simon: Imagine you have a team of 6. If we've got security requirements, performance requirements, scalability, or any other complex functional requirements, sometimes we all forget about them. There needs to be a role to make sure people follow these requirements. It's a single point of tech leadership. Of course you can share that role, but most teams don't work like that. So it's about having someone in the team to step back a bit to make sure things move under the requirements.
51CTO: Just a short question, do most teams in the UK have this chaotic behaviour?
Simon: Yes, most teams. It's the same worldwide, to be honest.
51CTO: You have mentioned in your many posts, that different teams and engineers have different definitions to the term "architect". But still, under any kind of classification, any defined "architect" should have something common, either their responsibilities, or their abilities. Can you briefly describe some generalized architects, in terms of what they need to know and what they need to do?
Simon: That's an interesting question. Just the word architect means different things to different people. In fact, if you go and look after what architect means, again there are so many definitions. There is a body called the IASA, which is the International Association of IT Architecture. They used to be called the International Association of Software Architecture, but they changed that, because they want to come up with a definition for all IT Architecture. It is sort of controversal to try to come up with a definition, but my view is that people don't need to bother with the buzz words. The IASA guys, they used to have a Business Tech Strategist term, which doesn't really make sense. I'm definitely willing to create some well known definition, but I think more importantly, and in agile teams, the definition of the organization comes in first. We have to define the role, list up responsibilities, and make sure at least one person is doing it. It really should be a team by team kind of role. Each team should have an architect.
51CTO: Do you think that architect working independently like you, and those architects working in a specific product team, are there differences?
Simon: Ok, I'm independent, but I tend to work as a team. The roles are the same, but the priority is slightly different. If you are building things for the customers, the requirements might not change that much. While on the product teams, it's a different role, because you are right on the front line, you are making decisions on how you make things, you have to look into scalability, how things might change along the way.
51CTO: So you started your career in IT since 1996. That has been 16 years. Have you experienced periods when you feel you have a large leap forward?
Simon: I definitely have experienced periods when there is a vast jump backwards. When I first came into the role of an architect, I wasn't sure what I need to do. I was drawing UML diagrams, and I thought, ok, I have jumped from coding to drawing pictures, this isn't right. How these things linked together? I think I was taking a step back, but then I realized you have to step back to see the bigger picture. I was taking different projects throughout the year, so module designs, component designs, service designs and so on. Actually, it's all the tiny things that help you succeed or fail. When you build something and things don't perform well, you need some one with experience to look back at what might happened. It's a lot of backwards and forwards, I'd say it's a revolutionary career. And I'm still learning. How the security mechanisms work, use transactional arc systems, and there are so many technologies up there, clouds, all the web stuff, services...there are so much stuff to learn. It's a tough role in the software trend. Lots to learn. Never stop learning.
51CTO: So do you think things are changing faster in those 2-3 years?
Simon: Definitely fast.
51CTO: As compared to 10 years ago?
Simon: Well, I think it was already moving fast ten years ago. It was the Internet bubbles, that time I was doing Java, all kinds of buzz words came: web, enterprise Java, JavaBeans, servlets, JSPs, application servers, clustering...that was a very fast time in the Java industry. Java slows down now, .NET picked up, and if you look at things like cloud, that has gone rapidly fast as well. Amazon's got elastic clouds, VMware's got Cloud Foundry, platforms are coming up...it's always moving fast.
51CTO: Ok, so you know many things, and you mentioned about the T-shaped architects. Do all developers need to work to that direction?
Simon: Ideally all developers.
51CTO: So those specialists who can only code, is there any room left for them?
Simon: Yes. Although in agile we talk about generalized specialists, in an ideal world, everybody is equal, they make decisions, look after the build environment, and build things together. In the real world, it's hard. It's really hard to find people who are generalized specialists. So in the real world, you will always need those specialists who can only code. It's up to the team and people you've got. If your people just want to code, they don't care about the bigger picture, that's fine. Don't force them to do things they don't want, like making decisions. They'll do a bad job anyway. Just leave them there and use their expertise.
