本系列的 第 4 部分讨论了如何规划应用程序体系结构的增长，向您展示了如何使用可伸缩和自适应思想来集中于以客户为中心的业务策略。在第 5 部分中，您将了解如何在体系结构设计中内置流程管理遵从性，以确保在整个组织中一致地使用该设计。这是前一篇文章中讨论的可伸缩和自适应思想概念的自然发展，因此要确保将本文与其一起阅读，以便完全掌握这两个概念性的思想，并且能够将它们应用于下面列出的流程管理技术。
流程管理 是指准备正确的过程以确保团队执行所需的关键活动，从而提高工作效率和保证某个级别的控制，以最好地管理组织。流程管理在应用程序体系结构设计中非常关键。如果没有它，您的设计将任由部门政策所支配，并且您将发现自己倒退回制图板时代，并再次试图取悦于各方势力。更糟的是，如果只是讨论而未遵循流程管理技术，您的设计可能不会得到正确实现和使用。
然而，强有力的流程管理遵从性带来了某种级别的控制，能够在争论出现之前实质性地停止争论。例如，部门不能脱离遵循自己的设计这个圈子。体系结构设计因其为组织带来的工作效率和能力而受到重视。无论您是否为组织流程管理系统开发中的关键角色（大多数应用程序架构师都不是），都必须完全了解组织使用的流程管理技术，并且必须考虑如何充分利用这些技术。
要有效地在体系结构设计中内置流程管理遵从性，需要有一定的技能和能力。在阅读每一项技能的过程中，尽量集中于将您的远景变为现实所涉及到的流程和人员。
在帮助实现自己的设计时，在组织中推进该设计的过程中，请不要惊讶于发现自己在使用两种基本的人事类型的技能：指导 和 仲裁。在某些方面，流程管理是遵循流程的平等部门之间的协商和坚持。人类的天性决定了人们不喜欢别人告诉他们要遵循规则。而且，如果流程要有效地工作，就必须真正地遵循规则。这样，诀窍就在于指导人们使用您的设计所需的流程，即使是在您整理不同意见并尝试使您的设计对用户更有吸引力的时候。
在您说“这不是我的工作！”之前，请考虑一下您的工作是什么：创建组织将一致和有效地使用的设计。如果没有以这种方式使用，您的设计就没有得到很好地规划和执行，对吧？在创建设计并准予实现之后，应用程序体系结构并没有停止。实际上，只要还涉及到用户，它就永远不会结束。如果用户需要某些推动才会使用该设计，则架构师需要投入进来并尽可能地进行推动。
体系结构指导员的作用是创建正确的学习条件，以及找到推动用户接受新设计的方法。要创造正确的条件，您必须与教育团队合作，以确保为用户创建正确的培训。此外，您应该联系交流团队，为将要推出的有关新设计及其实现的各种交流提供关于该设计的专门经验。不要等待任一个团队联系您：他们甚至可能不知道您的存在！在他们尝试了解该设计最终如何影响用户时，很可能他们是在一无所知的情况下工作。尽早作为主题专家提供您的服务；这样将为您提供机会，以便以多种方式指导其他人了解您的设计。
这就是仲裁，也称为中介 或问题“调解”。通过倾听可以改进设计的领域，以使用户更容易使用流程，您可以在流程管理讨论期间发挥巨大的作用。这项特定的技能涉及到大量的倾听，并且可以直接影响到设计的可用性。如果您听到其他人抱怨设计中内置的某个特定流程难于管理或遵循，应考虑如何处理该设计以使所有各方都满意。也许您可以更改设计以使某个特定流程更容易，或者甚至排除某个让所有人都疯狂的流程。观察、分析，然后提供有关您的设计如何能够改进流程以简化工作的反馈。您将发现自己调整设计以帮助解决流程管理问题的意愿，对于长期获得用户认可来说将会大有帮助。
确保设计的流程遵从性所需要的另一项技能是管理。我讨论的不是管理您的时间或其他人员；我讨论的是管理其他人的预期。我的意思是：任何新的应用程序体系结构设计都可能涉及到组织中人们使用的应用程序方面的某种更改。也许是要升级应用程序；也许是完全更改它们。最终，用户预期更改会产生更好的结果——更简单的界面、更简化的流程等等。
无论是管理自己的第一个还是第五个设计项目，您都拥有对组织产生很大影响力的权威。但是，如果那些受您的设计影响的人不理解该设计应具有的功能，则这种权威就没有多大用处。因此要花些时间预先设定预期，并不断向该设计的批准和实现过程中涉及到的每个人传达这些预期。
让信息得到清楚和明确的了解完全是另一件事情。您如何与业务环境中的其他人交流，对于获得所需的认可以实现流程更改来说，会产生举足轻重的影响。在我的文章“Obtain approval for your process change recommendations”中，您可以了解用于与管理层有效交流的特定技术。在您致力于获得设计所需流程的遵从性时，可以对用户和中级管理人员使用这些相同的技术。
在推出新的应用程序时，人们可能觉得自己像是要发挥很重要的作用：学习新事物总是令人兴奋，但同时也有点让人招架不住。提炼您的交流技能，以帮助教育和交流团队利用人们的这种兴奋，并促进您的设计在整个组织中的采用。
现在，当我们介绍可用于构建流程管理遵从性的工具和技术时，请考虑可以使您的设计尽可能简单的方法。设计的使用越简单，其使用范围就会越广。
在设计中内置流程管理遵从性最容易的方法之一是创建尽可能使用自动化的设计。例如，销售代表是否需要记住要移动到哪些屏幕，或者您的设计是否基于收到的特定问题的答案，自动将它们在屏幕之间移动？如果您的设计依赖人类记住流程，实现遵从性就会极其困难。人们注意力分散，他们运气不好，或者有时只是因为某个流程片段非常耗时或困难而决定跳过它。
但是，自动化可以强制流程遵从性。例如，如果销售部门需要基于从客户接收到的特定响应的后续信息，要确保您的设计会立即将销售代表带到可在其中输入该信息的屏幕或应用程序。这种方法有助于您的组织实现创新并更快恢复绩效，从而产生满足不断发展的业务需要的能力。
完整的应用程序体系结构设计应该是组织中所有透视图的统一。当您用这些术语考虑设计时，组织的流程也应该在您的设计中统一才有意义，对吧？有时，这意味着组合或消除流程；有时，这意味着创建更容易使用的新流程。
假设组织有各种各样使用各自的身份验证应用程序的业务流程。应用程序承载在不同硬件上的不同位置，并使用不同的操作系统和服务器。要有效地支持流程管理目标，您的设计应该将这些多样的身份验证应用程序统一为单个应用程序，并且需要身份验证的每个业务流程都可以容易地访问该应用程序。着眼于需要身份验证过程的最复杂方面的流程，并从那里开始构建自己的统一身份验证流程。为不需要过多身份验证的业务单位内置一些灵活性，现在您就通过使用所有透视图拥有了各个流程的统一设计。
如果您不清楚到何处查找有关组织中各个流程的信息，并不是只有你一个人遇到此问题。许多组织将流程管理视为麻烦事，并且很少有组织花时间对整个组织中的流程编制文档。如果您的组织确实有具备文档记录的流程，应获得这些文档并确保了解您的设计将影响哪些流程，以及谁将处理特定的角色和职责。
如果组织没有为其流程编制文档，您将处于不利地位，但是通过直接访问业务单位，与他们合作为其流程编制文档，并发现角色和职责背后的人员，您就可以克服这种不利情况。（请参见参考资料，以获得指向有关如何这样做的信息的链接。）在设计的开始阶段，由您做的工作会很多，但是最终，您获得的直接输入对您设计的接受将会大有帮助。
这是因为，无论您必须使用何种方法来映射和了解组织的流程，您还会发现每个业务单位用于确定成功与否的关键业务控制点和指标。在考虑不同的设计方法时，务必记住这些控制点和指标，当业务单位看到看它们（或了解到它们在幕后是内置的）时，他们就不大可能因为他们自主开发的解决方案而避开您的设计。
现在您已经考虑了涉及到的人员和使设计尽可能有吸引力的方法，接下来必须满足一些里程碑。在您查看下列建议时，应从广泛的角度进行考虑：您的设计将如何适应组织中的总体方案？
在设计中内置流程遵从性之前，您必须了解哪些业务领域中使用了哪些应用程序。幸运的话，组织已经拥有应用程序的编目。但在实际中，大多数架构师没有那么幸运。如果是这种情况，您必须联系设计将影响到的每个业务单位，并获得所使用的应用程序的详尽列表，然后逐个业务单位地比较这些应用程序。
应用程序编目帮助您了解组织中的何处存在差距和重叠。例如，也许销售和潜在客户开发 (lead-generation) 团队使用同一个客户关系管理 (CRM) 应用程序。但营销团队使用一个完全不同的 CRM 应用程序，此应用程序根本无法与第一个 CRM 应用程序集成（尽管它可以与供应链使用的第三个 CRM 应用程序完美地集成）。但是，除非您已创建了组织中所有应用程序的编目，否则您不会认识到这些深远的影响。
在创建自己的设计时，对将要更改的流程以及更改这些流程的方式 编制文档。无论组织是否具备有效的流程文档编制过程，您自己的文档将在阐明新的设计时对您有所帮助。您能够指示人们参考该文档，以便他们可以确切看到您的设计对他们意味着什么，并且您决不会在某人挑战您的设计决策时失去警惕。
使用诸如开放源代码的 Eclipse Process Framework（请参见参考资料）等企业流程框架可以帮助您处理这个里程碑。流程框架可帮助您利用整个组织中的现有最佳实践，以及提供某种级别的一致性。
当您完成组织流程的所有研究和文档并将该信息整合进设计中时，就到了提出建议的时候了。管理层希望了解预算限制和竞争问题，以及有关您的具体设计的详细信息。在向上级管理层提出建议时，要确保处理这些问题，以避免您重新解决它们。最好以书面形式提出建议并附带任何口头上的陈述——人们以不同的方式了解信息，并且有些人需要可视表示形式才能清楚了解您的建议。
本文讨论的所有部分都是用于确保在体系结构设计中内置流程管理遵从性的方法，以确保您的设计在整个组织中得到一致的使用。虽然在创建自己的设计时彻底改造流程可能很有诱惑力，但那是一种危险的方法。如果没有业务单位的认可和更改流程的合理理由，您的设计就有误用风险。人们会避开他们不理解或不支持的流程；相反，应该确保您的设计具有遵从流程的充分理由。
学习
- 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
- 阅读Application architecture essentials 系列 中其他文章。
- 阅读“Create a process documentation guide”（S.E. Slack，developerWorks，2007 年 3 月），以了解有关编制业务流程文档的信息。
- 阅读“Eclipse Process Framework 项目”（Per Kroll，developerWorks，2005 年 11 月），以了解有关 IBM 向 Eclipse Foundation 提议的项目的信息。
- 阅读“Exploring Business Process Management Systems and the impact of BPM on developers”（Sukriti Goel，developerWorks，2006 年 8 月），以了解 BPM 系统正在如何改变开发过程和架构师及开发人员的角色。
- developerWorks Architecture 架构专区：获取提升您在体系结构方面的技能所需的参考资料。
- 浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。
111
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
