今天是个很有意义的一天，从正式毕业到现在工作正好一年了！ 很感激自己一年来的努力，并通过一个熬夜来总结一年来的收获与下一年的展望。
因此今天就对这一年的总结：
1. 从技术角度剖析：
a) C－ 很高兴当时选择了C语言作为自己的入门语言；而且自己很快的能在这方面展现，变量、指针、基本数据结构、信号量、共享内存、消息队伍、Socket等等都实现的差不多了，仅仅差别就是在于自己学习的过程没有很好的写出文档，后续学习时就相当再次学习这一过程，而不是自己写了一个例子，以后的开发仅仅是建立在这个例子之上的过程；
b) 数据库－ Informix、Oracle 很开心的是掌握了两个数据库的安装、配置、应用程序开发等等，特别是对Informix有一个很深的感触，基本实现了两数据库的在自己虚拟机上的实现，当然如果有时间还可以学习一下DB2、Sybase的安装、配置与应用程序开发，哈哈！
c) 中间件－ Tuxedo 毕业时间对中间件Tuxedo没有什么认识，经过一个项目的开发，才发现可以用简单来形容，当然只是简单的C/S通信，并没有涉及深层次的开发，当然对于基本的Program已经够用了
d) 操作系统－ 很早以前就对Linux感兴趣。因此，在进入公司后环境应该一直不是问题，上手快感觉就是不一样；一些基本的Shell命令，Vi操作等等以前都是课本的知识，现在都只是手指头的细胞了
e) 公司产品软件 SCR, Sysmng, PB2.0等也让我认识到软件产品
f) 其它－ Vmware、Win32等等只是皮毛的学了点东西，当然虚拟机的配置让我很轻松的做到C/S的配置，很感激自己当初做出的努力
2. 从业务角度剖析：
a) 基本的会计知识：借贷、中间业务、银行核心业务、广东金融服务平台的业务等等，因为没有综合的、有步骤的学习，因为这方面知识不全面，但是第二年就是自己的业务目标， 会计资格证书等等
b) 卡系统，广东金融服务平台两个主要项目充实了第一年的业务知识内容
3. 从架构角度剖析：
a) Client Client ATM ATM 中间件 TUXEDO OS Database 第三方通信 Client
b) Client Client Socket Client Client AIX Oracle 第3方
c) 对架构的认识，在全国大集中的情况下，数据都集中在一个点，因此对于服务端数据来说就可以多个服务来响应各个Client的连接，Client的实现，中间件的均衡负载、服务端的处理及第三方通信构成当前金融的基本布局
4. 当初计划
a) Unix Shell通读
b) C 各方面编程
c) Informix精通
d) Tuxedo精通
e) 业务在虚拟机上跑动
f) 英语的阅读与听力
g) 健康的身体
总结：很大一部分都做到比较满意，美中不足的就是对业务的不精通，但是通过今后的努力，应该可以弥补这方面的不足吧！
5. 下一年期望
a) 业务－会计证书，提高自己的业务的能力，核心业务、中间业务的精通；
b) 技术－架构师更深层次理解、B/S架构理解、Oracle认证、更多的中间利弊、服务端的实现、分析一个工具的利弊、.NET等面向对象开发
c) 健康－长跑的习惯、坚强的意志
d) 英语－再次提到这个话题，真的很想提高自己这方面的能力，苦于自己缺少一种很坚强的意志
e) MBA－相关课程学习(1)宏观经济学；(2)会计学；(3)财务管理；(4)营销管理；(5)生产管理；(6)系统工程；(7)企业战略；(8)经济法；(9)计算机辅助管理；(10)财政与金融；(11)国际贸易与国际金融； (12)应用经济学；(13)人力资源的开发与管理
一种很想成为一个架构师，却一直不知道架构师具体做些什么事？
今天就上网很狠的查了一下更高手写的参考文档，基本可以理解为
1． 技术能力－ 对更方面（C、Java、XML）的开发、应用程序都有一定程度上的了解
2． 设计能力－ 能总结出一套业务人员提出业务需求之后，实现设计的过程
3．
1. 开发程序时 注意性能与扩展性－－网络、硬件知识、软件知识；
2. 架构师步骤：
a) java、c、c++、uml、RUP、XML、socket
b) 分布式系统原理、ejb、corba、com/com+、webservice
c) 设计模式(c++版本、java版本)、ejb设计模式、J2EE架构、UDDI、软件设计模式
3. EITA：—是能够理解业务问题复杂性以及可以连接到解决问题的潜在技术复杂性的有技能的人。
4. EITA：首先，需要想象力，或者完全理解一个业务需求的能力，然后与可利用的工具和技术相匹配来创建一个长期有效的解决方案。
附件1：
在世界各地的信息技术（IT）厂商的出售中出现了一个新的角色。这就是IT 构架师—这个人能够将业务需求转换到具体的 IT 实现中。随着快速增长的新兴技术以及精心构架的组织越来越依赖于 Web 服务和开放标准来为全球业务需求提供最新的 IT 解决方案，IT 不得不对拥有创造力的单个新职位进行回应：企业 IT 构架师（EITA）。毕竟，它不是解决业务问题的技术，而是人—是能够理解业务问题复杂性以及可以连接到解决问题的潜在技术复杂性的有技能的人。
IT 构架师或者 EITA 已经不是新概念了。事实上，在每一个 IT 项目中，最重要也是最首要的问题是要有一个构架师。与构建一座大楼相比：如果您起初还没有计划，这个房子将永远不会建造好。但是如果已经建造了，那么最终产品不会是您想象的那样，也可能在功能上并不十分理想。对于 IT 项目也是类似的道理。一个 IT 项目在开始时如果没有一个合适的构架师也注定会失败。正如您想要构建一个您想要的房子，IT 构架师帮助您为系统设计，安全，以及保护制定计划－－帮助您搭建构架，能经得起时间考验的稳固构造。
既然如此，那么一个 EITA 需要什么样的特质呢？首先，需要想象力，或者完全理解一个业务需求的能力，然后与可利用的工具和技术相匹配来创建一个长期有效的解决方案。这种技术在企业 IT 构架过程中或者对一个特殊业务问题设计企业解决方案的过程是十分有效的。如下所示：
- 有些人会迭代产生业务需求。（这个需求可能与在多个销售商中进行自动化控制供应链一样复杂，或者与为自动化采购过程创建一个集成的工作流程一样复杂。）
- 这种业务需求传递给 EITA。（“用这个来处理事情，并且昨天就应该处理好”是这个请求任务的通常的形式。然后就该由 EITA 来开始明确地描述解决方案了。）
- EITA 为这个项目确定主要的项目参与人。（这个步骤需要对业务本身有良好的理解。）
- 这个 EITA 必须会见这些主要的项目参与人来确定那些能够帮助解决这些请求的业务组成。（这个步骤不仅仅包括所需要的过程，还包括相关的扮演者以及他们在这个过程中的角色。）
- EITA 最后确定业务过程的定义。（这些项目参与者对它进行评审并确保每一项都在相同的页面。）
- 当这个业务过程被接受，这个 EITA 就能够为这个项目创建最初的预算。（这个预算要像设计解决方案一样精确。）
- 这时 EITA 开始着眼于潜在的解决方案。（首先，EITA 必须浏览当前内部有哪些是可利用的。理想情况下，整个内部 IT 构架将会被完全定义并且为EITA 的利用做好充分的准备。）
- 接下来，这个 EITA 必须确定这个组织是否能够利用现存的能力支持这个解决方案的实施，或者是否需要新的能力。
- 确定需要的技术可以让 EITA 更精确地确定预算需求。
- 有了精确地预算之后，EITA 就能够根据解决方案的提议提供主要的项目参与者。（这个提议是以会议的形式产生的，会议上 EITA 给他们提供关于这个解决方案的文献。这个会议的结果是，这个项目"进行" 或者"不进行" 。）
这个过程在图 1中有插图说明。尽管此时 EITA 的工作远不止这些，但是这种类型解决方案的详尽结果是一个EITA 所掌控的首要任务之一。
的确。作为一个 EITA，您经常会发现在您自己所处的位置中，您要提出一个别人都没有想到的解决方案。这就是企业 IT 构架过程派得上用处的地方。但是，要实现这个过程，您需要特殊的技能—首先，如先前所提到的，是实现业务过程和潜在 IT 解决方案的能力。除了这些核心技能之外，您还需要以下这些技能：
- 变更管理技能。第二重要的技能是听从的能力。EITA 必须是良好的倾听者，因为没有人喜欢变化。有些情况下，这意味着别人不打算接受您提出的解决方案。因此，要花费一些时间来聆听他们的需求—专业的以及个人的—以及对您的解决方案能够纳入考虑之列的建议改善。
- 领导能力。EITA 们还需要领导才能，或者在讨论和使用可靠的采访能力询问合适问题过程中提供正确方向的能力—这些问题能够直接深入问题的核心，帮助其他人很好地想象和理解问题。
- 沟通能力。另一个重要的技能是在谈判中能够传达复杂的需求使每一位项目参与者都能够理解。使技术概念在口头上和编写中都能够“通俗化”的能力很可能能够成功或者毁灭任何被提议的解决方案。通常情况下，这种技能转变成以一种清晰明了的方式阐述关键概念和工作流程的能力。
- 技 术专业知识。当然，其它技能不能够弥补综合专业知识的技能。没有这些必要的技能，就不会是一个称职的构架师，也不可能提出任何类型的解决方案。最好的能使 构架师处于这样水平的技能是来自 IT 组