级别： 初级 S. E Slack (sally@sslack.com), 技术文档撰稿人兼业务转换沟通咨询师, 自由撰稿人
2008 年 3 月 28 日 作为架构师，您不参与日常的项目管理，但是通过分析和交流有关风险因素、复杂性、预算和期限的知识，您可以大幅度改进项目。
如果您是经验非常丰富的架构师，您应该已经看到了自己的设计在获得批准后所发生的情况。部署团队拿到您的设计并继续使该设计变成现实。这对任何架构师来说可能都是件高兴的事——谁不希望看到自己的设计变成现实呢？——但也可能是充满障碍和意外挫折的崎岖之路。即使在某个设计好像非常完美的时候，也无法保证其部署将会非常完美。通过在进行部署之前考虑预算和计划问题，您可以帮助管理设计的日常实现工作的人员。最大限度减少过分复杂的设计功能并注意可能阻止设计进度的风险因素，这是在创建设计时务必要记住的其他关键因素。本文将研究这其中每个注意事项，并提供一些帮助部署团队实现设计的技巧。
预算和计划问题
信息技术 (IT) 部门、部署经理和架构师很少听到“不要担心预算”的说法。我从来没听到过对某个项目有此说法！相反，大多数体系结构设计都交给部署团队，部署团队迅速深入分析该设计以确定哪些方面在经济上可行，以及哪些方面必须等待以后某个日期才能实现。
部署经理对设计进行深入分析不是因为他们希望这样做；他们是出于必要才这样做的。该经理的任务是按时和按预算部署项目，这两项都是由主管规定的，主管拥有有限的预算，并且希望指明要在特定日期前实现某些里程碑。当主管表示有 X 美元可供使用，并且项目需要在 X 日期之前完成时，这就是他们的希望。没有任何主管希望听到某个部署错过了期限或者由于预算额度而无法实现。这两种情况都会使主管在同事和老板面前丢脸，这绝不是好事情。
这种情况使部署经理面临非常有限的选择。他们要么可以到主管那里，尝试解释为什么项目没有按时部署或者为什么需要更多的资金，要么 他们可以部署项目的部分内容，以取悦主管并保持项目继续向前推进。预先建立有限的范围可以帮助部署经理让主管保持现实的态度，以便让主管清楚什么目标能够或不能够在某些日期之前实现，并允许部署随着时间推移而继续展开。
但是对于正在接受有关该设计有效性评判的架构师来说，此类方法并非始终是好兆头。如果部署经理选择部署该设计的一部分，而此部分要在部署该设计的另一部分之后才能使用，那么您的卓越的设计突然间好像不是那么有效了。可以做什么工作来帮助解决预算和计划问题呢？以下几个部分将列出一些想法。
建立递增的范围
您已经知道部署经理将必须这样做，那么为什么不替他们做呢？那样，就可以按照您认为最适合于达到总体有效性的方式实现该设计。您是最了解该设计的人；您知道该设计的哪些部分最关键，哪些部分可以等待到第三、第四或第五个部署阶段再进行部署。
分成若干部分而不是作为完整的产品来考虑您的设计，这样可以让您在进行部署时掌控一切——您可以向主管和部署经理提出建议，而不是与他们独自做出的可能不准确的决策作斗争。这个思考过程还可以帮助您优先确定需求，并帮助推动开发周期——这两者对部署经理来说都是非常有帮助的。
作为附加的好处，您可以使用递增的范围来创建您与主管和部署经理的共同远景；在你们三者中，您可以为您的设计创建正确的行动计划。这不仅将您重新带到主管面前并向他们表明您如何致力于确保该设计很适合于组织，而且还将您确立为部署经理的重要合作伙伴。
确定所需的技能
当然，部署经理负责让部署团队的成员齐心协力地工作。但是除了您之外，谁知道哪些技能和技能级别对您设计的部署最有利呢？确定部署的各个方面所需要的特定技能或技能级别，这样可以帮助部署经理更准确地规划资源，从而可以在部署过程中节省大量的时间。
可以这样考虑：如果您知道需要两个高级系统工程师和一个初级工程师来构建和管理您的设计所需要的存储区域网络 (SAN)，那么为什么不和部署经理交流该信息呢？如果您不和他们交流该信息，他们就无法认识到全部的时间影响和项目的特定部分所需要的技能级别——从而可能导致部署进展缓慢。如果您知道某些技能和经验级别将帮助更有效地部署某个设计，一定不要隐瞒该信息。
现实地面对测试
测试阶段会在项目过程中消耗掉大量的时间。如果测试人员遇到问题，项目可能会延缓数周甚至数月。预先考虑实现您的设计所需要的特定测试，并准备好与部署经理交流该信息，以便能够做出恰当的规划以包括必需的时间。例如，如果您知道三个系统之间的集成将对该设计的成功非常关键，那么应该执行什么类型的测试呢？是否应该使用场景？如果是，谁将构建测试场景，他们将需要多少时间？或者，是否应该在开始任何其他部署活动之前使用沙箱来测试设计的某些元素？是否在任何点需要用户测试？与部署经理交流此类信息可以帮助他们预先做出有关计划问题的决策；这样，当部署经理在以后某个日期意识到可能需要开发测试场景却没有为此而准备时间时，他们就不会放松警惕。
使用从您设计的其他部署中学习到的教训
回顾一下您设计的以前部署。您是否满意某些方面的处理方式？您是否对其他方面很失望？您从每个设计和部署中学习到的教训可以——并且应该——在每次处理新的设计和部署时加以利用。例如，某个部署是否由于您的设计需要过多的测试而延迟？如果是，请确保当前的设计已考虑到了早期设计中确定的任何问题。
还要花时间研究最近在组织中部署的其他设计，无论那些部署成功与否。它们在哪些方面是正确或错误的？您是否能从那些设计的创建方式中发现任何教训？尽管您很难拒绝这样的诱惑，即认为自己的设计是处理某些事情的最佳方式，但是最好对其他架构师为您提供的想法保持开放态度。
文档、文档、还是文档！
很少有人认识到团队成员要在部署期间花多少时间尝试了解设计的各个方面。作为设计的创建者，您显然知道所有的细节以及各个细节是如何组合在一起的。但是刚加入项目的人员要花相当多的时间去了解所涉及到的应用程序以及那些应用程序预期要做什么。
例如，我曾作为全球交流负责人参与过一个项目。项目中的人员预期我应该知道应用程序如何影响用户的每个细节，以便我能将那些技术细节转换为针对最终用户的基本交流内容。当我问到某个特定的应用程序时，明显看出项目中几乎没有人了解该应用程序或该应用程序在部署后应该完成什么工作。他们仅知道需要部署该应用程序，并假设我能够弄清该应用程序是什么以及为什么需要它。我花了数周的时间去打电话、会见和祈求，最后才获得了所需的信息。这个故事的寓意是什么呢？决不要假设除您之外的所有人都了解为什么某些事情必须在部署中发生。在文档中写下该信息，并保留在项目中的每个人都容易访问的地方。
分析复杂性和风险因素
在当今的世界，企业和应用程序体系结构设计方面的复杂性级别不可低估。尽管大多数较大型的公司都已丢弃遗留系统，转而支持更容易部署和操作的分布式应用程序，但是诸如数据库和服务器等大量的基础部分（称为构件）会给设计带来恶梦。
您能在设计中加入的公共策略和 IT 语言越多，部署团队实现该设计就越容易。不是火箭学家也认识到复杂设计的操作成本更高，部署之前、期间和之后的管理更难，并且以后在必须做出更改时将不可预测。
还要考虑肯定会随时间推移而做出的操作变更（修复、安全修补程序、硬件更新等等），并花时间仔细分析您的设计所针对的环境。例如，您是否在为销售部门做设计，变更历史记录是什么？该部门是否有接受 IT 变更的倾向，或者他们是否经常抗拒例行的更新？
设计中的风险因素各有轻重缓急，但最重要的是将阻止设计成为预期的有效解决方案的那些风险因素。尽管不同的组织有不同的风险，但是使用结构化的框架和流程管理系统可以避免许多风险。例如，IBM® WebSphere® 产品系列包括多个不同的产品，可帮助您设计规则并将规则集成到业务流程中 (WebSphere Integration Developer)，或者从预先构建的框架开始以加速业务服务的交付和组合 (WebSphere Business Services Fabric)。
预先了解什么情况会让部署面临风险，这对任何部署经理来说都将是有帮助的。例如，设想一下当我参与过的一个项目的架构师发现亚洲的宽带系统无法支持正在部署的主要应用程序时的那种惊讶情况。我们花了数周的时间去准备解决办法，从而让项目在那段时间嘎然而止。
分析复杂性和风险因素不只是对您有好处，对整个部署团队也有好处。如果您知道销售团队有推诿每个变更的倾向，应该提出一个可帮助部署经理在必须迎击的战斗中获胜的计划。帮助部署经理了解“优良”而不是“必备”的设计部分，以便他们能够在需要时做出一定的让步并继续推进部署。如果部署经理从未与销售团队合作过，但是您曾经和销售团队合作过，您可能是一项极具潜力的资产，可以通过避免陷入不必要的纷争来节省大量宝贵时间。
总结
您也许不负责项目的日常管理，但是您要 负责所部署的最终设计的有效性。有见地的架构师清楚了解与项目的预算和计划相关的问题和要求，并且他们会主动与部署经理合作以帮助项目更顺利地进行。您不会作为幕后项目经理而获得任何荣誉，但是您确信自己已经竭尽所能使最初的远景以尽可能最好的形式和在尽可能最快的时间期限内得以实现。
参考资料 学习
获得产品和技术
讨论
关于作者  | 
| | S. E. Slack 是 Studio B 的一名作家和作者，在业务写作方面具有超过 16 年的经验。她还担任过 IBM、联想国际和 State Farm Insurance Companies 的主管和业务转换沟通咨询师。她目前正在编写 CNET Do-It-Yourself Digital Home Office Projects:24 Cool Things You Didn't Know You Could Do (McGraw-Hill)，并且是 其他五本图书的作者。 |
对本文的评价
| 
