| UML软件工程组织 | |||
| |
|||
|
|||
企业架构观点：什么最适合您的组织？
2007-12-13 作者：S. E Slack 出处：IBM
每个组织都具有独特的业务需求，因此在为公司规划企业架构方法时，考虑到多种因素是非常重要的。本文将研究在规划新的或修改后的企业架构时应该考虑的事项。 本系列将探索创建成功的企业架构所涉及到的若干事项。您将了解的内容包括如何：
本文为您提供在处理企业架构设计和实现时要考虑的新观点，从而开始本系列。您将探索将业务与技术战略保持一致的重要性、为什么交流技能对于您的成功至关重要，以及如何在组织中将自己定位为受信任的顾问。您还将研究一些可在该过程中使用的有用工具和技术，以及该过程中的一些应该了解的里程碑。 技能和能力在企业架构设计的规划阶段，对具体设计技能的强调比较少，更多的重点放在使用战略性业务技能上。正如您将在本部分中看到的，要将企业架构恰当地与业务保持一致，所涉及的不仅是确保流程得到足够的处理。 当您查看企业架构的定义时，可以看到它基本上就是将特定的方法应用于组织当前或将来的结构和行为。它明确地处理流程和信息系统，虽然也可以包括其他事情。创建强大的企业架构的关键是要认识到：无论您做什么，体系结构设计都必须与组织的战略方向和主要目标保持一致。关于企业架构的有趣之处在于，虽然它显然一定与组织中的信息系统相关，但重点实际上更紧密地与业务优化技术相连。 这些技术通常涉及到将企业架构信息技术 (IT) 设计视为重叠在业务战略之上的技术战略。例如，如果组织有一个涉及到缩短上市时间的业务战略，则体系结构必须通过旨在简化设计、制造和生产流程的技术战略来支持该业务战略。而且，由于组织中决不是仅存在单个 迫切的业务战略，您必须概念化并创建开发和操作模型，这些模型不仅能够响应业务需求，而且能够预先为业务需求做好计划。您的设计必须是能够指导业务开发和决策制定的蓝图，并且要足够敏捷以快速改变方向。 正如在“Let's talk:Build your enterprise architecture using communication and the right framework”中所提到的，正确的框架对于促进企业架构的实现大有帮助，这样的框架描述一个结构，复杂的对象关系可通过该结构相互作用，从而将人员、流程和技术联系起来。Open Group 体系结构框架（Open Group Architecture Framework，TOGAF）或 Zachman Institute for Framework Advancement (ZIFA) 支持的 Zachman 企业架构框架 (Zachman Enterprise Architecture Framework) 都提供了一个矩阵，使您可以安排帮助将业务需求与 IT 服务保持一致的组件的相互关系。 这其中的所有技能当然在于您能够从足够广的角度去思考，以包含组织的所有可能性。如果对此技能没有信心，应与您的主管商量以观察员身份出席更多的业务会议，以尽可能多地倾听和观察。如果无法实现这点，应该要求主管定期为您提供有关更高层正在讨论的事情的信息，以便您能开始自己弥补此空白。如果您是主管，应该让员工尽可能多地了解潜在的公司方向。您不必泄露机密细节，但至少要提供有关您的未来展望的一般信息。 由于您参与查看组织的总体流程和系统以确保一切都顺利，您还将发现做出一个决策会导致需要做出更多决策。例如，如果更改影响到多个部门，则更改一个简单代码段的后果会扩大。这就是您需要加强交流技能的时候，以根据需要扮演中间人，甚至在许多情况下故意唱反调。 保持头脑冷静并使人信服的诀窍是尽可能清楚地解释您的业务 论证。在对非技术受众讲话时跳过高度技术性的解释——技术细节只会使人们混淆和晕头转向。相反，应坚持使用业务语言，这样您会发现自己的想法和顾虑更容易得到接受。 例如，如果您知道某个来自市场部门的软件变更请求会使销售部门使用的某部分软件过时，您需要以简单的术语解释这种情况。不要尝试描述该软件变更会明确地做什么，只需使用类似如下的说明：“更改此软件将导致销售开支上升。但是，如果我们不更改它，市场部门将继续遇到工作效率问题，从而最终导致的成本超过销售部门所增加成本的两倍。” 用简单但直接的术语进行交流有两个好处：
向所有人说明涉及到的细节可能非常有诱惑力。但是如果您用技术性的解释使受众迷惑，则您永远得不到希望达到的目的：完成设计的解决办法。 谈到交流，您通常是应邀解决问题，对吧？当然，您越能以他们的业务语言而不是 IT 行话与其他人交流，他们就越有可能让您参与规划阶段的讨论。这使您成为一个受信任的顾问，能够在业务战略和决策出现时对其进行观察和分析。此观察和分析阶段对于帮助简化您的工作非常关键。 这是因为，在通常了解某个提议的更改的几个月之前，您可能就已经确切了解企业正在考虑什么。您将能更清楚地了解整个组织中的资源问题、任何更改将具有的影响，甚至是应该在部署之前运行什么类型的测试用例。您将了解所有一切，因为您是决策者之一！ 如果未邀请您加入规划讨论，应该接触当前决策者并询问其领域中正在发生的事情。提议出席他们的下一次会议，然后在您出席会议时只需观察即可。在未经要求的情况下，开始分析人们在周围闲聊的一些概念。要求出席另一次会议，然后在任何适当的场合顺理成章地将您的分析插入当前计划。正如前面提到过的，其基本思想是成为同盟者或受信任的顾问。当人们开始认识到您正在尽力帮助而不是妨碍他们的计划时，他们将更乐意接受您的思想和建议。 工具和技术当您尝试用体系结构来为将来做规划时，有时您所能拥有的最关键工具是对过去的充分了解。了解组织在繁荣和萧条时期的思考、行动和反应方式可帮助您确定如何完成您的设计。 有一项技术是任何企业架构师都应该攻克的，该技术听起来非常简单，但实际上相当复杂：了解组织。这并不意味着了解公司所在的行业或充分了解组织是如何运作的。其含义远不止如此。 了解组织意味着了解其文化、价值、规范和原则。例如，您的组织是否每年都要庆祝创办者纪念日 (Founder's Day)？如果是，则执行相关研究，以了解是谁创办了公司、他或她的理想和目标是什么，以及那些理想和目标是如何一年又一年地坚持下来的。也许您的公司最近被来自另一个国家的公司收购了。您是否了解该国家的商业习惯？例如，中国与美国的商业习惯差别非常大；在中国文化中，不同意见通常以非口头语言来表达，而在美国，不同意见则是以口头语言的方式表达的。 这些类型的文化问题为您提供了微妙——有时不是那么微妙——的线索，让您了解组织最看重的价值（诚实？利润？荣誉？）以及那些价值如何影响业务环境。了解该信息可以让您在创建或更新企业架构时掌握主导地位。您可以更好地了解哪些更改会很快得到接受，以及哪些更改需要努力争取。 您还能更好地了解参与者的关注事项。例如，如果您知道企业架构中的参与者最关心维持传统业务方法而不是尝试新方法，您就不会浪费时间去提出最终可能改变传统业务方法的创新方法。 如果您还没有对这种事情赋予多少注意力，快速赶上去也不是那么困难。尝试联系组织的交流或公关部门，并请求有关公司历史记录的文档。或者在下一次办公桌上收到公司新闻稿时阅读该新闻稿。虽然某些信息可能让您产生平淡无奇甚至无聊的感觉，但那些出版物始终包括相关事件和传统。向长期员工询问他们多年所见的更改或缺乏的更改情况。在会议期间聚精会神。主管们是否公开互相反对，或者争论是否不太明显？您的公司在使用什么类型的管理风格？开放策略体现了集思广益的意愿。缺乏此类政策表明公司领导更喜欢坚持采用层次结构方法来完成工作。 在思考和规划是以自顶向下的方法来实施的项目中，您参与了多少个项目？在此类方法中，最高管理层决定需要做出某个更改，较低管理层表示同意，然后组织中较低地位的人员根据需要参与进来实施更改。这就是大多数更改的实施方式。但有时可能恰好相反：组织中某个较低地位的人请求某个更改，在发生任何事情之前，该请求通过各级管理层一路上报到最高管理层。这两种场景中通常缺失的是水平方法。 水平地思考意味着组织的不同级别可以合作决定需要做出什么更改。更改的广度及其对组织的影响得到最优先的考虑，而更改的深度则通常集中于垂直的自顶向下或自底向上的方法。还记得前面对有关了解组织的评论吗？如果您已经完成了准备工作，则会了解公司是否偏向于使用一种方法而不使用另一种方法。 大多数情况下的最佳方法是同时垂直和水平地思考。虽然用您的设计来深入挖掘组织可以促进创新，但是要确保组织中所有受影响的人都能接受该设计。不存在完成设计的正确或错误方法，但是最好执行一些有关水平和垂直方法概念的研究，以确定哪一种方法更适合您，或者是否应该同时使用两种方法。 同样，了解组织对此项技术也会发挥作用。当您从整个组织中获得的反馈表明您的计划似乎不错时，您知道自己已经找到了正确的方法。在设计的这个部分，不要害怕与尽可能多的人交谈。您从越多的人那里探出反馈，您就越有机会为组织找到正确的方法。 里程碑在深入研究除设计和 IT 以外的企业架构元素时，里程碑有一点含混不清。它们不一定是可测量的里程碑，因此在研究我这里列出的里程碑时，您需要有一点创造性和周密的思维。 对于任何企业架构设计，都存在影响业务员工的更改。因此，与公司的交流团队合作是非常关键的，以确保更改不仅得到理解，而且还在整个组织中得到采用。更改不是在单个步骤中实现的。它是在三个关键步骤中实现的：
这些步骤通常通过持续的交流进行处理，其中一个关键消息堆叠在另一个关键消息之上。 让我们面对它：您和其他人工作数月以确保您创建的设计无缝地部署到组织中。但是除部署团队以外的其他每个人完全不清楚即将发生的更改。他们处于所谓的无意识阶段。甚至在您开始考虑部署广泛影响组织的新软件或硬件之前，您就需要通过交流有关该更改及其为什么有必要的信息，从而让组织做好准备。受影响的人需要知道会发生什么结果以及何时发生。 当组织为即将到来的更改做好充分的准备时，您可以推进到实现更改的下一阶段：帮助人们接受更改。他们知道更改并不意味着他们将会喜欢更改。接受阶段旨在帮助构建公司方向的积极意识。只有在此阶段之后，人们才会接受或支持该更改并开始采用它。 您在实现更改的过程中的角色非常关键。没有您的知识和输入，交流团队甚至无法开始与员工交流正确的信息。没有正确的信息，员工就不会接受所发生的更改。而且如果员工不采用您做的更改，您就已经遭遇了潜在的失败。 IBM® Rational® 产品套件拥有各种可帮助您实现组织更改的工具。developerWorks 文章“Organizational change in the Internet age”提供了有关此主题的很好见解。 此里程碑涉及到一点自省。尽管最明显的地方是在部署之后，但可以在该过程中的任何位置使用此里程碑。问自己以下问题：
价值是一个模糊不清的术语。它通常基于人们的感知。人们是否认为 他们正在从您的设计中获得预期的东西？如果是，则该设计可能至少实现了您预期的大部分价值。不过您需要执行一些调查来确定。不要依赖帮助您实现该设计的人们。他们 很可能认为该设计有价值！相反，应该利用交流团队来执行一些调查，或者自己对员工或一线管理人员执行一些随机的电话调查。 他们是真正能够告诉您该设计是否为他们实现了任何价值的人。如果他们的工作更容易，如果工作效率更高，如果停机时间缩短，则您就获得了有关该设计价值的有力保证。但是如果您听到不是那么满意的报告，请不要惊慌。使用那些报告作为学习到的教训，并将它们用作即将到来的升级的基础。记住，用户起初通常不情愿采用新工具。如果您在用户响应中听到大量有关该技术的恐惧，可直接与教育和交流团队合作确定下次可做什么不同的工作，以在下一次设计部署之前通过培训和针对性信息来减轻那些恐惧。 总结本文为您提供了一些要在处理企业架构设计和实现时考虑的新观点。您的组织具有独特的业务需求，因此务必要确认这其中哪些观点对您有价值，哪些观点对您没有价值。一般情况下，这里列出的观点几乎在任何场合下都有效。决定因素在于您以新的态度来处理企业架构的意愿。请继续关注本系列中的下一部分，其中将讨论当前（或按原样）的体系结构文档记录。 参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
