办公环境和员工地理位置分布化的同时，网络又在虚拟地联系着越来越大规模的企业，这都给企业管理者提出了很多新的问题，集中化与去集中化之间该怎么选择呢？架构师又该做些什么呢？ S. E Slack 在 IBM developerWorks 的撰文似乎对我们很有启示。
很大程度上互联网、电子邮件的出现快速催生出一个非常庞大的分布式工作环境，不仅是 SOHU 这个词也已经不陌生了，在很多企业不同部门分布在各处，在不同业务区域、甚至全球都有业务机构，员工的工作位置更是 Anytime、Anywhere 了，分布和分权化似乎来势汹汹；同时，单个部门、单个机构内部考虑问题很容易“自扫面前雪”，毕竟对于经理们而言，能否照顾好自己的部门事关饭碗，而企业高层又往往希望通过在某个单元优化自己内部机制的时候不要对其他单元造成影响，或者说从总体考虑，业务优化最终落实在整个企业范围，这样开看来集中规划、集中调控又是必不可少。
这种情况下，架构师是否可以提供“在充分发挥各部门分布式优势的同时又可以进行有效的协调和集中调控呢”的技术方案呢？有的，不过前提很多，首要的企业高层管理者是否真正在关注总体的业务优化，是否愿意启动这个工作。如果获得这个机会，下一步要看架构师是否可以为高层提供企业总体业务过程的架构，并在明确部门间信息需求的前提下，概括出业务决策所需要的高层过程视图和业务信息交互。这样做，一方面可以很容易地发现冗余甚至互相抵触的部分，为进一步改进作准备；另一方面在项目外包或内部自建的时候，可以从明确他们的定位，并对是否影响其他业务过程有直观的了解。这时候企业有望进入到一个“双收”的局面：有了纵观的整体视图后，各个部门可以根据业务需要、客户要求更分布的组织自己的业务过程，同时企业可以有效的了解、并调控各业务部门的运转状况。
可以说高层业务过程架构是设计未来用的，IT 部门充当的也不是被动接受指示的角色。在可预见的未来，分布和分权化将始终存在，但现实中获取各个部门现有 IT 情况本已经不容易，提出改进意见建议其他部门根据一个“视图”优化他们的业务流程相信会阻力重重。文中最后给我们支了两个招：
- 用高层和各个业务部门的语言与他们交流，用别人可以理解的语言描绘这个企业业务流程架构；
- 用人际工程的方法，真正去了解相关部门主管（或者关键人员）为什么会不合作，了解他们真正关注的问题。
“万事开头难”，相信随着架构师与相关部门交流的不断深入，协作并获得其它部门支持的需要也会促使业务部门与企业业务过程架构融合。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论