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

[[93820]]

Simon Brown

Simon Brown居住在澤西島（海峽群島），他是一名獨(dú)立的顧問，且是編碼架構(gòu)（Coding the Architecture）網(wǎng)站的創(chuàng)始人，自稱是寫代碼的軟件架構(gòu)師和明白架構(gòu)的軟件開發(fā)者。Simon有多次在微軟.NET和Java平臺上開發(fā)大型項(xiàng)目并取得成功的經(jīng)驗(yàn)?，F(xiàn)在，他也經(jīng)常出席歐洲有關(guān)軟件體系結(jié)構(gòu)及其在現(xiàn)代軟件開發(fā)團(tuán)隊(duì)中作用的論壇、演講等。他同時(shí)是《面向開發(fā)者軟件架構(gòu)》一書的作者，該書目前正在Leanpub出版發(fā)售中。他目前也仍在編寫代碼。

以下是采訪實(shí)錄。

51CTO：Simon 你好，感謝接受51CTO的采訪！

之前看到您分享的話題，提到團(tuán)隊(duì)實(shí)施敏捷的時(shí)候一定要確保團(tuán)隊(duì)里有足夠的優(yōu)秀工程師。你經(jīng)常遇到那種團(tuán)隊(duì)還不成熟的時(shí)候就盲目實(shí)施敏捷的團(tuán)隊(duì)嗎？

Simon：哦是的，這基本上是常態(tài)——不幸的常態(tài)。你看，敏捷宣言在去年已經(jīng)十周年了，就理念而言它已經(jīng)存在的足夠久。大公司們想要實(shí)施敏捷，因?yàn)樗该鳎山桓?，成本可控，進(jìn)展速度快，并有持續(xù)的反饋。聽起來十分美好。然而很多實(shí)施敏捷的團(tuán)隊(duì)會遇到一個(gè)問題，也是我經(jīng)常被咨詢的問題，就是他們對項(xiàng)目和文檔的管理失去了把控。你看看Scrum，它提供了很多角色（profile），但對于如何運(yùn)作項(xiàng)目的具體實(shí)踐卻沒提到多少。敏捷過程還有其他的很多問題，人們在其中并不清楚自己應(yīng)該專注于什么；他們過多的關(guān)注技巧，但是卻忘記了很多基本的東西：安全，可擴(kuò)展性……他們開始不做決策就悶頭做事。我最近就遇到這樣一個(gè)團(tuán)隊(duì)，他們跑過來跟我說，好吧，我們4個(gè)月前開始實(shí)施敏捷，做了不少輪的沖刺，然后就是，我們現(xiàn)在堆積了一堆技術(shù)負(fù)債，現(xiàn)在我們需要對所有的東西進(jìn)行重構(gòu)。要我說的話，如果他們在一開始多想想，那么現(xiàn)在也不會需要面對這樣的一個(gè)問題了。

不過，這樣的情況實(shí)在太多了。

51CTO：那么，你如何確保將一個(gè)可以看清全貌的人，比如一個(gè)架構(gòu)師，放到這個(gè)團(tuán)隊(duì)里面來，就可以避免這種情況呢？

Simon：比如你有一個(gè)6人的團(tuán)隊(duì)。我們應(yīng)該有安全需求，性能需求，可擴(kuò)展性需求，或者其他復(fù)雜的功能需求，但是有時(shí)候我們會忘記這些需求。所以，需要有一個(gè)人在團(tuán)隊(duì)中，確保所有的人都按照上述這些需求來執(zhí)行。這是單點(diǎn)的技術(shù)領(lǐng)袖。當(dāng)然，你可以讓多個(gè)人共同承擔(dān)這個(gè)職責(zé)，不過大多數(shù)團(tuán)隊(duì)不是這樣運(yùn)作的?？傊?，有這樣一個(gè)人的存在，就是為了確保團(tuán)隊(duì)成員們在需求的范圍內(nèi)行動(dòng)。

51CTO：順便提一句，英國的團(tuán)隊(duì)會有很多都處于這樣一種混亂的狀態(tài)嗎？

Simon：哦是的，大部分團(tuán)隊(duì)都是。事實(shí)上，全世界都是一樣的。

51CTO：之前看過您的博客，說不同的團(tuán)隊(duì)和工程師對架構(gòu)師的定義都不一樣。不過總的來說，架構(gòu)師總該有一些共同的特性吧？比如職責(zé)，能力方面。您認(rèn)為“架構(gòu)師”應(yīng)該知道些什么，應(yīng)該做些什么？

Simon：怎么說呢，“架構(gòu)師”這一詞語本身對不同的人就有不同的意義。如果你去查找“架構(gòu)師”的定義，更是會發(fā)現(xiàn)很多不同的定義。有一個(gè)組織叫做IASA，International Association of IT Architecture，他們以前叫做International Association of Software Architecture，不過后來更改了名稱，希望將整個(gè)IT領(lǐng)域的架構(gòu)定義整理到一起。定義一件東西總是充滿爭議，不過我倒是覺得大家不必對一個(gè)詞語如此糾結(jié)。IASA的伙計(jì)們曾經(jīng)定義了一個(gè)Business Tech Strategist（商業(yè)技術(shù)策略是）的職位——有這樣一個(gè)職位又能意味著什么？

我當(dāng)然也想創(chuàng)造出一些廣為人接受的定義，不過我認(rèn)為更重要的是，在一個(gè)團(tuán)隊(duì)當(dāng)中，組織的定義是優(yōu)先的。我們先定義我們需要做什么，有哪些責(zé)任，之后再將每一個(gè)責(zé)任分配給指定的一個(gè)人。這完全根據(jù)團(tuán)隊(duì)需求而定義的。

51CTO：您覺得像您這樣獨(dú)立工作的架構(gòu)師，和那些專屬在某個(gè)產(chǎn)品團(tuán)隊(duì)中的架構(gòu)師有何不同？

Simon：我雖然是獨(dú)立架構(gòu)師，但是我工作的時(shí)候是跟團(tuán)隊(duì)一起的。如果要說區(qū)別的話，其實(shí)是面向客戶的團(tuán)隊(duì)和做產(chǎn)品的團(tuán)隊(duì)之間的區(qū)別。職責(zé)相同，但優(yōu)先度不同。如果你為客戶構(gòu)建系統(tǒng)，那么需求是相對固定的。然而如果你自己做產(chǎn)品，那就不一樣了，你在前線，做出針對產(chǎn)品應(yīng)該怎樣做的各種決策；你需要考慮可擴(kuò)展性，以及當(dāng)你構(gòu)建的時(shí)候可能會面臨的變化。

51CTO：那么，您從1996年開始從事這個(gè)領(lǐng)域，到現(xiàn)在已經(jīng)是16年。您有沒有覺得哪段時(shí)間您的成長特別快的？

Simon：哦，我經(jīng)歷過負(fù)成長特別快的時(shí)段（笑）。當(dāng)我剛剛被冠上架構(gòu)師這個(gè)職位的時(shí)候，當(dāng)時(shí)的我很迷茫，不知道應(yīng)該做什么。那時(shí)候我每天畫UML圖，一邊畫一邊想，好吧，我從一個(gè)碼農(nóng)轉(zhuǎn)型成一個(gè)畫圖的了。這感覺不太對。它們之間究竟有什么聯(lián)系？當(dāng)時(shí)我覺得自己處于后退一步的狀態(tài)。不過之后我發(fā)現(xiàn)，你要想看到更大的世界，是有必要往后退一步的。

這些年我接了不少項(xiàng)目，有模塊設(shè)計(jì)，組件設(shè)計(jì)，服務(wù)設(shè)計(jì)等等。到頭來，決定你成功還是失敗的，都是這些小細(xì)節(jié)。如果你構(gòu)建了一個(gè)系統(tǒng)，它的性能不怎么好，你需要一個(gè)有經(jīng)驗(yàn)的人來幫你分析當(dāng)中可能出現(xiàn)的問題?？傊泻芏嗲斑M(jìn)和倒退，我覺得這整個(gè)職業(yè)就是一個(gè)革命性的職業(yè)。我現(xiàn)在仍然在學(xué)習(xí)，比如安全機(jī)制是如何運(yùn)作的，系統(tǒng)的交互機(jī)制，還有很多新鮮玩意兒，云計(jì)算，新的Web元素和服務(wù)……有如此多需要學(xué)習(xí)的新東西。身處軟件行業(yè)的大潮中不是一件容易的事。學(xué)無止境。

51CTO：那么，您覺得軟件領(lǐng)域這兩三年的變化很快么？

Simon：當(dāng)然，非?？?。

51CTO：相比10年前呢？

Simon：我覺得10年前的這個(gè)行業(yè)就很快了。當(dāng)時(shí)有互聯(lián)網(wǎng)泡沫，我那時(shí)候在做Java，也遇到很多新的熱詞：Web，企業(yè)級Java，JavaBeans，Servlets，JSP，應(yīng)用服務(wù)器，集群……當(dāng)時(shí)的Java領(lǐng)域也是變化極快的。后來Java逐漸慢下來了，.NET又起來了；現(xiàn)在的云計(jì)算其實(shí)也是一樣的，亞馬遜有彈性云，VMware有Cloud Foundry，還有很多新平臺出來……其實(shí)每個(gè)時(shí)代都很快。

51CTO：好的，那么最后一個(gè)問題。您本身了解很多方面的知識，您也提到架構(gòu)師應(yīng)該是T型人才（注：即在某方面技術(shù)專精，各方面技術(shù)精通）。那么，所有的開發(fā)者都應(yīng)該朝這個(gè)方向發(fā)展么？

Simon：理想狀態(tài)下，應(yīng)該是的。

51CTO：那對于那些只會寫代碼的專才而言，以后還有什么發(fā)展空間么？

Simon：哦，當(dāng)然有了！我們在敏捷理念中談?wù)撋抖级膶I(yè)人才，在理想世界中，每個(gè)人都是平等的，每個(gè)人都知道如何決策，如何照看各種構(gòu)建的環(huán)境，以及如何做出東西來。然而，我們在現(xiàn)實(shí)世界。上面提到的東西很難實(shí)現(xiàn)。現(xiàn)實(shí)是你很難找到啥都懂的專業(yè)人才，能找到代碼寫得好的專才已經(jīng)很難得了。你有什么樣的人，什么樣的團(tuán)隊(duì)，決定了你能做什么，該怎么做。如果你的人只是想專心寫代碼，他們不在乎要不要提高一個(gè)層次去看更加宏觀的世界，這也沒什么，挺好的。不要逼他們做他們不想做的事情，不要逼他們做決策。最可能的結(jié)果是，即使你去逼他們，他們也做不好。所以，還是讓每個(gè)人發(fā)揮自己的特長就好。

Simon 在大會上的分享 PPT 可在線觀看：

 - The frustrated architect

 - How to design a secure architecture

下面是英文采訪實(shí)錄。

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