标签：
草率提交任务是不负责任的行为
以维护流程通畅为重，以浪费他人时间为耻。要做到这一点，务必在系统内晚上的自动测试功能，纠正开发人员的行为。
沉下心来改善系统的生产效率，缩短流程，避免各行其是，才能缩短开发时间。采取一切可行的措施，例如运用模拟方法、降低依赖性、细致划分系统模块，等等。总之要杜绝一切草率提交任务的年头。
业务目标至上
在商业化的背景下开发企业应用，架构师必须成为业务部门和技术部门之间沟通的桥梁，周旋调解，兼顾双方的利益，同时用业务目标来驱动项目开发。业务目标和实际的开发条件应该成为架构师主持制定决策的参照系统。
按照通常的业务惯例，在启动一个软件项目之前，应当制定计划，明确对投资回报率的预期。架构师必须把握这个预期，并估计该项目的商业价值，避免作出错误的技术决策，造成经费超支。每当要权衡取舍时，无论是与业务部门讨论是否应该实现某项功能，还是与开发团队讨论技术上的设计与实现，都应该把高投资回报率当作目标。举例来说，架构师必须谨慎地站在业务团队一边，拒绝开发团队选用价格不菲的软件和售后服务成本过高的技术。
用业务目标驱动项目开发，才能包装软件开发团队的长远利益。
先确保解决方案简单可用，再考虑通用性和复用性
普遍存在一个问题，它们的设计一味强调通用性而不考虑具体应用，导致出现许多令人困惑的可选项和不确定因素，这些功能常常不是被闲置，就是被误用，甚至毫无价值。多数开发者开发的是专用系统，无限制的通用性对™的帮助不大。通过经验提炼的简单方案，远胜过不切实际的通用性。
如果存在多个可实施方案难以取舍，“先简单后通用”原则可以成为最终的评判标准。挑选基于具体需求的简单方案，放弃鼓吹通用性的复杂方案。
提炼通用性可以使我们更加接近问题的本质，通过分析已有案例可以获得清晰、简洁、有依据的规律和方法。
虽然很多架构师重视通用性，但这样做是有前提条件的。并非所有人都需要通用性，愿意为它掏钱，具体情况要具体分析，有针对性的解决方案才有价值。
架构师应该亲力亲为
称职的架构师应该通过示范领导团队。他能胜任团队的所有工作，从网络布线到配置构建流程，从编写单元测试到担任测试工作。对技术缺乏全面理解的架构师，充其量只是一个项目经理。团队成员通常具备深厚的专业知识，很难想像不懂技术的架构师如何赢得大家的信任。众所周知，架构师是业务团队与技术团队直接的接口人，他必须理解各种技术问题，无锡频繁求助他人，才能代表技术团队发言。同样，架构师还要懂得业务知识才能督促技术团队满足业务需求。
架构师就像航班的主驾驶员，看起来不是很忙碌，但他经验丰富，持续地见识着情况，一旦发现异常随时采取行动。项目经理（副驾驶员）负责日常的管理工作，将架构师从烦琐的杂务和人事管理中解脱出来。架构师对项目的交付和质量负有最终责任，没有威信很难展开工作，威信与项目的成败密切相关。
称职的架构师应该至少熟练掌握一种专业工具（例如一种IDE），它们应该身先士卒。按道理说，软件架构师应该会用IED，数据库架构师应该会用ER工具，信息架构师应该会用XML建模工具。而一位技术/企业架构师，起码应该熟练运用哥哥层次的工具，从使用wireshark检测网络流量，到利用XML Spy给复杂的财务信息建模--无论简单还是复杂的都该掌握。
标签：
原文地址：http://www.cnblogs.com/duanxz/p/4316921.html
