以往在企业架构和治理中，我们常常大体上将用户划分为企业高管、技术团队和最终用户，由于一般我们把架构和治理定义为面向企业过程和系统化管理的内容，因此最终用户常常被边缘化到这两个领域之外，但没有最终用户参与的 IT 建设又如何串起业务处理和 IT 间逻辑关系呢？
最近一期的《架构与治理》（Architecture Governance）杂志上 Alex Pavlak抛出了上面的问题，虽然在一般概念中架构师和系统分析员是有效衔接业务和 IT 的桥梁，但更多还是偏重技术层面，无论是项目目标、运行特性、实施计划、风险还是应用的各个里程碑都是由他们转达给 IT 团队的，但从业务逻辑角度看他们是否达意恐怕还需要最终用户来判断。
传统架构方法学对三个角色有明确的分工，三种角色同等重要，忽略任何一方都将导致企业组织内部运作不良：
- 企业高管负责项目整体运作；
- 技术团队负责设计、实施和运维；
- 用户决定产品价值取向；
但事实上我们往往忽略最终用户的意志，以 NASA 为例之前在设计太空梭的时候更多考虑到高管意志，弱化最终用户的决策权并把工程师推倒一边，这种情况导致挑战者号和哥伦比亚号失败的恶果。此后 NASA 作了调整，创立了“技术专局”（Technical Authority），专门解决高管与技术团队间的争执，决策何种程度的项目风险是可以接受的，但这并不够。
因为，最终用户的角色主要定位在价值决策上，他们需要参与项目目标、内容范围和应用边界确定等问题，同时高管和技术团队间经常出现的争执还需要最终用户来解决，毕竟无论是高管的决策还是技术团队的决策最终还是服务于业务处理的。从整个生命期看，最终用户的作用如下：
- 前期：项目前期是个螺旋上升的过程，用户作为一个积极因素参与和架构师、开发工程师的交互过程，他们表达使用喜好、决定具体应用功能、阐明对下一步系统发展的想法（Vision），相对架构师总结的预期内容，在各种限制因素下最终用户的想法经常会不切实可行，这时候需要高管和技术团队对用户众多想法决策取舍；
- 实施过程：到了这个过程用户的角色与技术团队的联系就弱化了，在系统功能被相对完整定义后，这个阶段项目关注的重点就成了如何有效降低成本，如何规避各种风险对项目进度的影响，而用户更多出现在很多不可避免的争论中，负责对一些问题进行决策；
但是，无论是产品型软件还是项目型软件都面临着业务快速变化的问题，无论是高管还是技术团队需要更多关注用户的反馈，如何保证软件成果具有更好的延展性、更具业务逻辑性越来越多需要依靠最终用户的决策。以后，用户的职责也需要调整：
- 用户决定未来的技术架构；
- 用户提出并确立 IT 目标；
- 用户提出更为坚实的资本计划和 IT 过渡计划；
注册/登录 InfoQ 发表评论