在你考虑企业系统管理这个问题的时候，首先进入你脑海的公司有CA，HP，IBM等公司。他们为企业提供全面的管理套件，用于监控和管理企业中大部分IT部件的行为，使得企业在IT管理中能够应付自如。虽然你没有考虑具有同样论调的微软，但是，微软有其独到的解决方案，他们正在尝试将全面的系统管理变成其遗传物质的一部分。
微软的 Server部门的高级副总裁——Bob Muglia，对这个问题做了如下的解释：“因为绝大多数的软件最初在设计的时候并没有考虑到可管理性和性。我们现在的处境非常尴尬，因为我们的软件非常复杂，而且存在许多漏洞，正是这些原因使得企业在网络管理和IT资产方面投入了巨大成本，从而成为许多企业的经济负担。这对于Windows和其他的平台来说都是事实。我们必须改变人们开发软件的方式，并且要保证这些新开发的软件从一开始就要考虑其可管理性。”
如何解决这个问题是我在前一个专栏中所提到的“指导企业”中的一部分。不应该事后再在企业中集成一个价格不菲而且非常复杂的解决方案，而是应该在一开始就考虑这个问题。理想的情况应该是这样，为了实现一个具体的任务，即便是环境中的条件发生了变化，也应该能够适应分布式的IT资源并能够完成该项任务。这种兼容性要求应用程序设计和配置环境之间有较高级别的联系，这样就能够保证系统可以在任何级别——操作系统、应用程序、网络、——都能够自动维持在最优状态。这个过程应该简单而自然，如同植物需要阳光，光合作用是遗传代码的一部分。
对于一个复杂的IT环境，将IT等价于光合作用的概念简直是一种幻想。没有一剂良药可以实现企业IT环境的自动管理。但是，微软在改进其软件体系结构和研究操作系统控制方面做出了长期的探索，这给企业特别是那些以Windows为中心的企业留下了深刻的印象。
微软的“动态系统计划”（DSI，Dynamic Systems Initiative）的核心是系统定义模型（System Definition Model——SDM）。使用XML技术作为其基本数据格式，设计SDM的初衷是用来捕获硬件和软件的基本结构和定义，包括配置方案、“健康模式”以及操作策略等有关信息。
微软公司的企业管理部门副总裁，Kirill Tatarinov这样解释，“SDM将是我们表达对于个人组件期望状态的一种方法，它将企业作为一个整体来考虑，通过SDM，只要部件连接在网络中，开发者就可以访问所有的部件。这种动态连接是微软的不同之所在。虽然应用程序可以动态响应，并且可以重新配置，但是大多数其他部件都是手动实现的（重新配置）。企业的高级定义和拓扑结构的高级定义之间的动态连接，以及与低级组件之间的连接是微软“动态系统计划”（DSI，Dynamic Systems Initiative）的主要特异之处。
结构化的SDM的实现方法允许应用程序或者服务的主要架构师在计划中更精确的定义需求和期望的结果，这样开发者可以更容易的解析它们。另外，根据Tatarinov的介绍，使用SDM方法编码的不同层次（应用层、网络拓扑层、操作系统层和层）之间必须配合使用。在开发的过程中，策略之间的冲突以及不同层次之间的限制就应该得到解决，而不是将这些问题留到测试或者配置的过程中才解决。
在数据中心里，网页服务和各种语言也能够用来来描述和记录操作和管理的任务与策略，并在软件中记录其他手动任务。SDM能够提供用于运行这些操作策略所必需的IT环境信息。这些信息是在研发的阶段就已经集成到硬件和软件资源中，而不是将其和智能或者操作意识结合在一起。如果其中的一个参数发生了变化，如网络的速度或者服务器的利用率发生了变化，通过内置的定义和策略，受变化所影响的组件将自动知道如何去处理下面的过程。
从本质上来说，这个概念是微软为了激活效用计算或者按需计算而定义的。
这是一个非常引人注目的概念——DSI和SDM听起来好像是IT业的光合作用，至少在Windows世界中是这样的。但是到目前为止，这还只是理论上的概念，而理论常常是推动IT环境向前发展的最大的力量。
我非常想准确的知道，这些理论是如何转换到现实世界的，而且我想看到实现IT资源的“从一开始就考虑可管理性”的路线图是如何实现的。
根据微软的企业管理部门经理David Hamilton的解释，公司将把管理软件中的智能化处理部分移植到应用程序本身，这个过程大致分为几个阶段。
“向应用程序中移植智能处理大致由三个阶段构成，” Hamilton 表示，“第一个阶段是产品发布之后再发布管理软件，所有的智能化工作都是实现在管理软件中，而行业中早就在强调这一点。在这种环境中，实现对应用程序的管理是最基本的。你可以通过工具来管理Exchange，查看信箱中进出的数据流，但是你无法看到应用程序的内部工作，或者无法理解应用程序的上下文。”
Hamilton表示，在第二个阶段，提供商提供应用程序的管理信息，系统管理软件可以使用这些管理信息。他给出一个关于Exchange微软操作管理器（MOM）管理布丁（MP）的例子。Hamilton 表示，“Exhange MOM MP可以解释应用程序产生的行为和事件，并且可以给出恰当的警告，记录系统的临界值，并且可以发送上下文敏感信息报告。” Hamilton指出，从技术的角度出发，阶段一到阶段二真正的进步是“警告”所表示的含义更加清晰。
最后一个阶段，也就是第三个阶段，大多数的管理基础设施都成为管理平台的一部分，这部分也将转移到开发过程中去。没有更多的额外的管理补丁。操作性的数据将被直接输入到开发过程中，根据应用程序具体的管理规划来应用程序的行为。根据Hamilton的说法，对于IT组织来说，与第二阶段相比较而言，第三阶段的最大的好处在于：成本和复杂性降低了，而创建可管理的应用程序也变得更简单。Hamilton 表示，“这才是真正的操作设计。”
第三阶段并不是意味着应用程序可以自我治愈，也不是意味着人机交互管理IT基础设施已经称为历史。Tatarinov 表示，“要想使得应用程序能够自我治愈，在设计时就必须考虑到自我治愈这一点，否则就无法实现所谓的自我治愈，整个程序的运行过程就是一个黑盒子。”
我要求他们给出一个第三阶段的例子，这个例子在应用程序的设计之初就将管理考虑在其中，但是他们对此谈的很少。Hamilton引用了微软的SQL服务器的管理补丁这个例子。“包含代码的数据库软件在很深的层次上跟踪事件。使用这些数据，我们可以越过预先设计的限制，而且可以在出现问题之前进行适当的调整。无论如何，在这一点上它要比第二阶段要强。”
Muglia为我描述了一个时间表，要达到成熟的第三阶段，大约还需要10年左右的时间。“在未来的两到三年的时间中，我们将看到非常显著的进步，而在未来的五年时间内，我们将看到一个巨大的飞跃。另外，它还需要五年的时间才能真正的大量出现，因为对于公司来说，研发和生产还是需要大量时间的。”
一个即将来临的较大的举措是在今年后期将要发行的Visual Studio的下一版本——代码名字为Whidbey。它将包含一个应用程序的模型工具——代码名字为Whitehorse，一旦开发者配置了应用程序，这个工具允许开发者提供SDM格式的信息帮助实现应用程序的管理。为了能够实现这个目的，应用程序可以象网页服务那样公布他们的管理数据和方法，公开基于XML格式的访问和管理控制台的选择。这样微软的管理软件和其他控制台将能够解释、控制和管理从其他应用程序中收集的SDM信息。
根据Hamilton的解释，SDM作为DSI的一部分，通过将基础设施的设计和确认与应用程序的设计相连，SDM比UML（统一建模语言）更胜一筹。Hamilton表示，“使用SDM，基础设施的架构师可以规定数据中心应该是什么样子，应用程序的架构师可以设计面向服务的应用程序，测试者或者操作管理者就应该确保所设计的应用程序在指定的数据中心能够真正工作。这样在企业配置他们的关键任务时，架构师和操作管理者之间进行良好的沟通可以减少配置过程中出现的各种冲突，从而可以为企业在配置关键任务的过程中节约时间和金钱。”
这种协调整个企业中的基础设施架构师、应用程序设计架构师和操作员之间关系的努力，对于减少IT项目的失败几率来说具有同样的重要性。但是，这样可能使得代码不是很可靠。随着各种各样的参与者加入，常常是放弃了这个服务和应用的最初目的或者其最初的目的遭到了破坏。微软的奠基人，Word的创建者，Charles Simonyi，现在正在开发一个工具，以帮助在整个开发的过程中维护在设计时就已经详细说明的各种值。他的公司——Intentional Software正在推动软件开发的革新，例如面向方面（Aspect-Oriented）的编程，这个工具将软件设计和程序编码联系得更加紧密。
一些标准实体，例如分布式管理任务团体（DMTF），现在正在制定管理的标准规格。Hamilton指出，虽然微软现在正在和DMTF进行合作，但是在整个生命周期中将更加注意突出其SDM特征。
Hamilton表示，“为了能够构建并且能够推进DMTF的公共信息模型（CIM）规范的发展，使得能够在数据中心实现一个与平台无关的、适用各种不同IT环境的行业标准服务器的硬件体系结构，我们正和一些标准的实体紧密合作。SDM工作在任务的上一层，SDM不是将注意力集中于单个的硬件组件，而是将整个分布式系统视为一个整体，SDM用于描述IT系统中这些不同的组件是如何组合在一起，成为一个完整的系统来发挥作用的，并且还将描述这些不同的组件之间的关系。”
当然，大多数企业都有几百万行遗留下来的代码。Hamilton表示，SDM可以用于为现存的系统建模，并将这些代码进行改进并且很自然的融入到SDM开发的系统中。但是由于大量遗留下来的和自定义的代码的相关文档非常少，这使得构建SDM计划面临着巨大的挑战。谈到如
【责编:admin】
--------------------next---------------------
