对企业信息的全面掌控。
安全、管理和监视成功实现SOA三大步骤
设想一下，如果你询问一位首席执行官是否知道他的全部企业应用程序在什么地方，安全状况如何以及是否正确地进行管理，结果会怎么样呢?他可能以为你是疯子。他很可能这样做。然而，令人惊奇的是许多不能准确回答这三个问题的销售人员却正在设法销售SOA服务。
事实是，由于其承诺的全部好处，SOA作为一种环境很自然地比它的前身更难控制： ·通过把所有的逻辑和数据集中在一起，基于托管的计算很容易管理、保证安全和监视。 ·通过把逻辑、数据和用户接口分开，客户机-服务器计算会产生一定水平的混乱和永远无法真正控制的失控成本。这里关键的因素是失去中心的控制。在过去的15年里，这个因素决定了计算。
·现在我们拥有了SOA。SOA为我们提供了敏捷性、灵活性、传统的延伸、投资回报和更多的东西。SOA的不利方面是SOA能够不确定地分布，从而使其成为最困难的东西，除非有现成的合适的基础设施。
随着企业日益增多地利用广泛分布的架构，并且一方面访问第三方的服务，另一方面把自己的应用程序作为Web服务提供，他们需要能够明确地回答这些问题：我知道我拥有什么吗?它安全吗?严酷的现实是许多企业在不能回答这些问题的时候就走上了SOA的道路。因此，他们使用老式的计算范例永远也不会实现SOA的目标。
没有保证安全、管理和监视服务的能力，企业就不应该考虑解决SOA的问题：
·安全：IT部门需要解决“中间人攻击”和“最后一英里”安全漏洞。除非恰当地治理，SOA才能允许让任何人在任何地方和任何时间启动、部署和编排一项Web服务。这项服务可能同数千个其它的服务在一起，显著增加安全风险。此外，这种情况也能够让虚假的服务伪装成合法的节点冒充真正的服务，破坏保证实现SOA功能的信任等式。通过采用运行时治理，IT能够通过服务发现和自动强制执行政策等方式减少风险。
·监视：除非你能够实时地看到你的服务和服务周围正在发生的事情，否则，你就不能放弃SOA治理的责任。理想的方法是商务流程的可见性，让你从商务流程的角度管理你的SOA。
·企业级管理：同所有其它形式的系统管理一样，在一个不同种类的SOA环境中实时地从一个控制台查看、管理和控制所有服务的能力是最基本的要求。SOA治理需要从规划到设计、从开发到应用、从运行到优化等全部过程的管理和工具能力。最后，这种能力允许用户根据业务或者IT标准定义、排列和优先安排事情以便管理服务级协议。
SOA承诺给企业带来巨大的好处。同以前的大多数IT范例一样，它一直被过分地宣传，
甚至吹嘘到了预期超过现实的程度。
为了让事实纠正过分的宣传并且防止人们失望，早期的SOA应用者需要保证建立一个牢固的基础。这个基础能够让人们像10年前一样进行控制。其它任何表示能够实现SOA的东西都可以看作是又一个一时流行的IT狂热。
IT项目经理必备的三种能力
信息化项目对企业而言，无疑是一项系统工程，既要符合企业发展战略，又要各部门协同配合，还要把握技术方向，因此作为企业信息化项目负责人的项目经理(往往由CIO担当)，在项目实施过程中起着关键作用，正所谓“成也萧何、败也萧何”，项目经理的能力是项目成功实施的基础。
一、项目经理应具备组织能力。
项目经理的组织能力具体表现在组建高效的项目小组、规范组织的工作范畴、明确项目成员的分工、协调各项工作的进度。拥有较高组织能力的项目经理，能够建立科学规范、分工合理、协调一致、高效精干的项目组织机构，作为项目成功的组织保障。
① 组建高效的项目小组。组建项目小组是项目开始的第一步，由于信息化项目往往牵扯的部门较多，因此项目小组的组建应考虑多个部门的共同参与，同时将各参与部门的人员分为实施人员和决策人员，并分别组成项目“领导小组”和“实施小组”的两层管理结构。这样，一方面能够让参与部门的各个层面充分了解项目的情况，另一方面可分别让项目的“决策”与“执行”寻找到合适的落脚点。
② 规范组织的工作范围。规范项目小组的工作范围，同时确定项目的实施内容，不仅可以有效保证项目组的工作目标明确，而且也是有效控制项目在实施过程中不断被扩展的有效途径。一般来说，项目范围的定义是项目组根据内部需求提出来的框架，这个框架一般会涉及到企业的具体业务，是项目实施过程的指导，并需要在项目执行过程中不断细化，因此要求项目经理具备把控工作范围的能力，否则项目会像滚雪球一样，越滚越大，远远超出项目的时间、成本预算。
③ 明确项目成员的分工。责任清楚、分工明确是任何一项工作的基础，尤其是像信息化项目这种涉及部门多、业务流程复杂的项目，更需要项目经理对项目组的每一位成员进行明确分工。
④ 协调各项工作的进度信息化项目强调各部门之间的协调配合，每一个部门的项目进度出现问题，都会影响到项目的总体进度，因此项目经理除关注项目的总体进度外，仍需协调各部门的项目进度，这样才能使各部门工作衔接流畅，从而步调一致，协同发展。
其次，项目经理应具备决策能力。
项目经理不仅仅是IT部门的管理者，更是项目组的决策者，在错综复杂的信息化项目中，项目经理应探查项目相关的各种信息，对其进行筛选，并对各种解决方案进行优势分析，
从相关技术、设备、服务、行情等信息出发，进行分析预测，优中选优，做出符合项目战略的项目决策。
第三，项目经理应具备沟通能力。
项目经理在信息化项目中承担了企业(甲方)、实施方(乙方)、第三方咨询机构之间联系和协调的任务：企业通过项目经理将项目需求传递给实施方;实施方通过项目经理将项目方案提供给企业;第三方咨询机构对项目的诊断和建议也往往通过项目经理来传达。因此项目经理实际上在信息化项目管理中扮演了“三方”之间桥梁的角色，其与任何一方的沟通出现问题都会影响到项目的进展。因此一个好的项目经理，一定是一个好的沟通者，通过与项目任何一方以及项目组成员的沟通，才能全面了解用户、决策者、实施方，乃至咨询机构对项目的真实评价，及时发现潜在问题，并通过征求各方意见，协调各方关系，找到能够保障项目顺利进行的办法。沟通可以是多方面的，口头的、书面的、甚至定期不定期的项目通风会、讨论会都会成为项目经理沟通的手段。
IT项目管理工具探讨之一------项目群管理
目前专门针对IT行业、软件行业的项目管理工具越来越多，但大多数产品目前还只是具有较通用功能，一些管理精细的要求难以在工具中得到支持。笔者根据实际应用，探讨一下项目管理中的工具支持功能，此为系列之一，欢迎从事项目管理工具研究或者感兴趣的人员 ，探讨研究。
一般有一定规模的软件开发组织，项目基本上都是项目群。一般规模的项目群可能分为两级，一个项目群下面包括若干项目组，大的项目，项目分级可能有3到4级。目前的管理工具对于项目群的支持都不够好，项目管理中对于项目群的描述，也是篇幅有限，认为管理好所有子项目，即可。对于项目群中各个项目之间关系一般很少阐述。一般的项目管理工具即使支持项目群的管理，也就是可以象树形展开那样，对项目群信息进行汇总查看，对于项目群的各个项目之间的关系、管理模模式等都不涉及，项目群就是若干项目的简单组合而已。
实际中，我以一个ERP软件公司为例，简单阐述下两种典型的组织架构下的两种项目管理模式，。
1、项目单独型：此种情况下，项目群中每个项目组是较为独立的，彼此间的任务基本没有太多联系。
这种模式下，每个项目组的项目经理，负责从需求、开发、测试整个的管理与跟踪，整个项目的项目计划跟踪由项目经理负责，这种管理模式下，项目群可以简单的看作是一系统子项目的集合，大部份能够支持项目群的项目管理工具都可以支持。
2、混合模式：
上述管理模式中，因为不利于资源的整合和利用，目前很多公司进行了改进，所以一般会将需求、测试从单个项目组中抽出来，组成需求组和测试组。
这样情况下，严格意义上讲，高级项目经理才是真正的项目经理，但在实际中，如果让高级项目经理(一般我们称为部门经理)负责项目任务的建立、跟踪，是完全不可能的。一般的部门，估计项目任务有好几百条任务，部门成员有20-30人，没有哪个部门经理能承担得了这个工作量。而且，在这种模式下，工作量估算也是分开的。
一般工具的解决方案就是，与上一种模式中的一样，将需求组、开发组、测试组也视为一个项目组，单独建任务。这样又产生两个问题：
1、 同一个功能点，被重复建了三个任务，并且之间没有任何关联，部门经理要跟踪功能点的完成情况，很麻烦;
2、 需求、开发、测试之间协作会较累，比如，我们在项目中，都要实时标记，是否提交开发、提交测试、测试完成，结果不知道要针对哪个任务进行标记。
所以我认为，现有的项目管理工具，即使是专门针对软件开发的项目管理工具，都没有考虑到这么细，这样的需求有一定个性化，但我认为在很多大型研发组织，还是有一定的代表性。说明管理工具的需求做得得还不够精细和深入，或者缺少。
我建议的解决方案是：对于项目群的管理，支持项目组的任务建立关联和继承关系，比如
上述混合模式中，开发组任务可以由需求组任务继承，测试组由开发组继承，需求组、开发组、测试组关注自己组的任务，对于部门经理，因为这些任务这间有继承关系，所以可以展现从需求、开发、测试的一体化跟踪表。
IT项目管理工具探讨之二_需求管理、项目管理
目前大部分的针对软件开发的项目管理工具，除了提供项目任务管理，有些已提供需求管理、变更管理等功能，但往往三者是独立功能，之间没有集成，造成在实际使用中的不便。
一、需求管理与项目管理的集成
对于做管理类软件的软件公司，一般都是业务驱动，由需求人员决定每版本的需求点，以此形成开发任务，至于非功能需求(如性能改进)，一般由开发组决定，一般占的比例较少。
需求管理功能，包括原始需求的收集，整理成业务需求，然后再细化为概要需求。往往是需求人员使用的，侧重于对需求的记录，不需要任务管理功能。
项目管理，主要侧重于任务的跟踪管理。
实际中大部分的任务都来源于需求管理的输出—概要需求点，概要需求点就是需求人员的需求任务，需求人员对每个需求点进行详细需求分析，再生成开发任务进行开发、测试。
从上述看，需求管理与项目任务管理，虽然侧重点不一样，但它们是密切相关，在软件开发中，需求点是任务的主要来源。
实际应用上，因为管理工具不支持两者集成，结果造成两方面使用不便： 1、项目任务往往来源于概要需求点，需要重复建立项目任务;
相关推荐：
loading