如果你是因为"架构师"这个词汇进来的，那么本篇的取名策略还算是成功的(嘿嘿)
名字起的有点大，幸而"人人都是",也就不至于自我孤立了。
"架构师"作为在公司的抬头而言，可大可小，大如***公司，小若俺们这儿。
记得pycon2011上有位兄弟这么描述"架构师"抬头获得的方式：
引用
当公司/部门 玩你这个语言/项目的人(资历比你高的)都离开(甭管去哪儿)，那么，你就是架构师！
别笑！这可是句大实话，国内的基本行情真是如此(至于你信不信，反正我就是这么得到的~)。
说到这儿，估计一些纯洁如小白花的coder要不乐意了，如此神圣、带有光环的、纯粹黑客精神的职位怎么变得比资历这么庸俗？如果说是cto,总监(管他监什么)多少带有管理性质的话，架构师 这个物种怎么地也算是纯技术geek的终极进化目标了，怎么可以一棍子戳破走技术路线的程序猿的梦想？
其实这个真没有，本文标题是"人人都是"啊～
为了说明问题，让我们先实例化个程序员~
虽说程序员也分好多种，不过基本属性只有一个--写代码。那么，为了增强这个基本属性，我们也只有一种方法--学习(至于要学什么，估计大伙会比较关心，不过这个东西要真写，估计目录都可以写上几本，简而化之：用到什么学什么，需要什么学什么。有先后次序哦~)。
基本的学习完成之后，那么基本上已经算是一个合格的程序员了。如果你不是混外包的话，那么基本上，你也算是架构师了：得到需求，将需求映射成代码(为了保证/达到 某些目标)，优化代码，整理结构(这些基本就和架构师干的活没什么区别了)
将这个概念泛化一下，人们大多会有起码一个从业/生存 技能。在学习的帮助下不断强化技能，并能在使用技能时，恰当调整相应流程以便达到某种目标。
再宽泛至每个个体的人生：在学习中成长，调整...如此而已
我说本文到此结束，会不会有人揍我？
鉴于能看到本文的(愿意看本文的)大多是it从业人员(还多是对职业未来比较迷惘的那种)，那么且勉强(汗颜啊)在这里谈谈 软件/互联网 行业的架构师的相关信息吧。
架构师的定义
<走出软件作坊>中把 架构师 称为 “走钢丝的人”,深以为然啊。需求过来了，如何最终呈现(或者配合产品)，一个拿捏不准，既被需求方骂，又被实现(程序员)骂。所以，就我看来，架构师的工作目标只有两个：1.不被需求骂；2.不被实现骂。
想要做到第一点，那就得懂产品。
想要做到第二点，那就得更懂产品。
诸位暂且不要跳脚，记得cpug中好像有过类似的争论，不过争论的主题大概是"程序员要不要深入产品"。我个人的观点是：‘要’。不过咱今个儿不争这个，咱说的是架构师，如果这个你还要和我争，好吧，我在这里先认输了(你赢了，劳烦您看到了这里~)
国内目前的行情是：产品(需求)和程序员(实现)是敌人。作为架构师，从情感上自然是和程序员一条裤子(说句程序员爱听的)，那么为了打赢敌人，自然得要做到“知己知彼”。当然啦，结果通常是皆大欢喜(理解万岁～)
懂产品，才能恰如其分的设计对应的实现方案(不会有不懂技术的架构师吧？咱说的是技术架构啊！)，需求方就不骂你了。比需求更懂产品，才能在更广的层面泛化结构，提升代码复用，不至于实现起来，处处是孤岛，那么实现也不会骂你了。
所以，如果想做到/升到(而又不想被人在背后说是混资历)架构师，去学习使用你的产品吧，去理解，去懂她（不是面向对象编程么，把她当对象啊~）
（好吧，其实我是想说：即使你是程序员，懂产品总没错的）有个故事怎么说来着：
引用
三个砖瓦匠
a.我就是在砌墙
b.我在建造一座花园
c.我在建造最美的城市
你觉着谁会更出息呢？
后记：
本篇取名源于<人人都是产品经理>一书。此书之后，似乎<人人都是***>这样的取名变得很是流行(也可能是我的幻觉~)，的确是通俗易懂，朗朗上口，关键是贴近大众啊--"人人都是"啊。
本想取个"程序员",不过似乎不够装来着(哈哈)，如果因为"架构师"而进来又木有能够满足某些方面的情感，实在抱歉~