架构师的工作

   从事软件开发混饭吃以来一直是做最底层的工作,跟客户讨论需求,然后编码,用户说你小子这儿怎么弄错了,于是我上去改改,修修补补,磕磕碰碰的过活。
   慢慢的知道项目中有个架构师的角色,于是一直处于仰望的状态,架构师,听着就叫人羡慕,高高在上,指指点点,潇洒自在。
   最近有幸参加了一个架构师的培训,才发现这个工作也不是那么好做,要做好架构师首先要跟客户深入接触,搜集各方面的需求,有些客户可能不太善于表达,架构师还要引导,让他们说出所有的需求,包括能说清楚的不能说清楚的,类似陪聊了,弄清楚了这些才能进行后续工作。
   陪客户聊完天后对他们的需要有了大概轮廓,这时候就需要输出一些图表来落实:
   1>System Context Diagram
   系统的上下文
   2>Architecture overview
   系统大概的功能点

   拿着这些概括性的东西再去跟客户讨论,再修修改改,然后完成更细一级的落实:
   1>Use Case图,主要用来描述需求
   2>Logical level of the operational model(LOM)
   逻辑层面的系统部署图,Client从什么地方访问,入口在什么地方,请求什么数据,核心系统在什么地方,他们之间的通信如何等等。
   3>Physical level of the operational model
   把Logical Level的节点落实成具体的东西,服务器用什么型号,内存多大,防火墙用什么以及等等细节。
  
   在生产物理层面的东西的时候,就反应出架构师真正的能力,对自己所从事的整个产品线的熟悉程度,什么地方用什么产品,达到多少人的负载,成本如何等等。

   真是很难啊!!!

猜你喜欢

转载自luzl.iteye.com/blog/1134391