【51CTO專訪】一位從業16年的軟件架構師，對這個行業的發展有什么看法？在8月的ArchSummit大會上，筆者跟大會的講師之一，來自英國的 Simon Brown 簡短的溝通了一下，了解到他眼中的敏捷，架構師，以及軟件行業的發展。

[[93820]]

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 可在線觀看：

 - The frustrated architect

 - 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.