企业架构师：功能及流程设计的监督

    功能与流程设计是企业架构(EA)方法论的一部分，与实际IT元素相适应的东西被创建，或者不创建的关键底层所在。企业架构师面临的最大挑战是，EA模型中的关键元素在项目初期往往是记录下来而非设计出来的。发生这样的事情是因为大多数企业架构首先被应用到IT和业务关系早已被确立的组织当中。

为成功搭设舞台

    许多企业架构师发现，技术或业务变革需要对功能及流程设计范围进行修订，他们没有必要的组织或技术支持来做出最适宜的业务——IT协调。为了阻止这一点，他们必须为范围变更的项目奠定基础，确保它们拥有最佳的建模工具，并在适当时候建立有效的项目控制移交给系统架构师。

    企业架构师要想成功推动功能及流程设计范围的改变，确保当前的EA模型准确表示了业务及技术的映射关系至关重要。大多数情况下，实现这一点最快捷的方式是从架构的业务流程层开始，验证此处发现的全体业务工作流。这充当了功能设计的输入，因此业务流程层的错误将会击倒未来的协调。业务流程还框定了业务流程执行语言开发与测试，这是技术及业务流程需要一致的第一个层次。

固化企业架构师的设计影响

    与此同时审核也在进行，聪明的企业架构师会就每一个有可能受项目影响的业务流程与业务线管理进行协调。由于架构师往往没有对上面直线部门或者下面IT部门的监督权力，他们需要与这两个相关部门的领导建立良好的个人关系。从业务流程侧开始，因为业务目标是协调活动的基线。

    固化企业架构师对功能及流程设计影响的第2点是对所有活动以可双向沟通的方式建模。IT专业人士广泛使用的统一建模语言往往由于其可读性不够而不为业务规划者与经理所喜欢。

    业务流程建模标记(BPMN)可能是建模可简单到业务管理层足以理解，也可复杂到传达业务流程和功能细节的好例子。IDEF(集成化定义)工具是由美国国防部开发的，现在已经开源。这些为各种层次的建模提供了适当的工具。支持和文档也许略微单薄，因此要对学习(及教学)曲线做好准备。

选择最好的方法

    企业架构师会争论什么才是功能和流程设计的最好办法，尤其是当改变的刺激源自技术侧时。这个领域历来都是架构师工作最困难的领域。EA方法论本来就是业务驱动的，因此往往要让技术选择去适应业务实践。

    每当革命性技术(或甚至只是得到显著改善的技术)出现，这些方法论往往就不适合于创建最合适的连接了。企业架构师不得不进行逆向工程或反向跟踪EA模型，从底层的流程设计开始追溯到功能及业务流程层。

    流程建模可以进行修改以便体现对新技术最合适的使用，这可通过功能层最小化的目标来完成。如果完成了这个，技术改变很少会上升到对业务流程产生显著影响的水平，对运营的影响也因而会减少。但往往真正显著的技术转变会迫使更高层次的地方适应这种技术以便确保利益的最大化。此时，另一种方法也许可以摆出来。

    这种方法是修订目标来支持技术实践。这往往被认为是一种违背了在业务流程层推断技术目标的EA实践的做法，但经验表明，吸收革命性的变化也许牵涉到实践的重铸来获得技术产出。要想做这个：

    ●从业务流程层开始，假定业务目标是用新技术来运作实现的。

    ●设计业务流程并用一般的办法对其进行剖析，做出功能与流程设计。

    既然新技术是高级目标，就得与流程设计输出相适应。

    这种方法的一个主要的好处是确保业务与新技术以正常的方式协调好，意味着将项目控制从EA转化为服务保证的常规化。企业架构师通过确保业务协调可保证做出一个对投资来说最合适的业务案例。

    然而这样仍然存在风险，技术转变要么会失去与作为实现过程的关键业务实践的联系，要么那种实现会证明适应的需要。除非在协调中有严重错误的迹象出现，此处最好的方法还是遵循逆向工程的路径。通过在流程设计中做出变化来适应实施需求，然后跟踪对业务流程影响，以便将实施中的变化与业务案例中可能的变化对应起来可以做到这一点。

    云计算、移动员工赋权等技术进展可以令技术资源方面产生深远的变化。企业架构师应该记住，高级业务流程设计未被固化的情况少之又少，至少在当前的技术选择下一定程度上是如此的。承认这种关系并非坏事，明确地对它进行治理可确保新技术选项能得到业务案例的良好支持。如此架构师就可以在投资指导中履行其监管角色。