策略eaiprinciples.doc

in a sense, methodologies are like coaches they dont magically guarantee success, but they do provide principles and practices that can lead to the best solutions. Over the next few months, this column will dig into Enterprise Application Integration (EAI) methodologies, examining 10 principles based on the five EAI laws (see the July 2002 issue of eAI Journal):从某种意义上说，方法论的角色就像教练一样，它不一定能保证成功，但它所提供的准则和实践指导着最佳实践。下面将论述的10条准则源于五条EAI原理。 The whole is greater than the sum of the parts.整体的作用远大于个体作用的简单聚合 There is no end-state.事物的发展永远没有终点 There are no universal standards.没有适用一切事物的规律 Information adapts to meet local needs.信息需要契合实践需要 All details are relevant.所有的现象都存在千丝万缕的关联The 10 principles include lessons learned from both the study of other scientific disciplines and practical experiences gained from applied system integration activities over many years. Theyre neither complete nor universal. Experienced practitioners must decide which of the principles apply in a given situation, how to modify them, and when new ones are needed. This month well start with the first two principles.这10条准则源于对其它科学规律的研究和应用整合的实践活动。他们即非完整，也非通用。有经验的实施者必须根据实际情况确定适用哪条，应做些什么修改，或使用新的准则。Align Plans to Strategy制定短期计划和长期策略The successful implementation of end to end integrated solutions is based on a fundamental alignment between business and technology along several dimensions. The Capability Maturity Model (CMM) for software (see Figure 1) is an approach that can be applied to other disciplines relevant to EAI, including the maturity of the business in managing processes; the IT organization in engineering enterprise-level integration solutions; and the whole organization in the use of models or metadata in planning and managing operations.These maturity models can be used to establish an overall target for the organization and to keep the various business and IT organizations in alignment as they move toward the target. For example,it would be wasteful (if not impossible) for an organization to invest in being at level 3 on the EAI maturity scale and level 5 on the modeling maturity scale if it was still at level 1 from the business process maturity perspective. Timing is another key alignment dimension. Given the magnitude and variety of challenges associated with achieving higher maturity levels, how should one get started? Some challenges can be tackled immediately; others will require fundamental changes in organizational structure, technology, and industry maturity that could take many years to accomplish. Although no single approach can address each enterprises unique position, start by aligning plans along three different horizons: Short-range (next 100 days): The focus is on a deliverable task plan. Develop tactical plans that address immediate needs and deliverables. Release incremental functionality frequently and pilot new initiatives. Medium-range (next 100 weeks): The focus is on preparing a joint business and IT road map. List all related business and IT initiatives, identify dependencies, and update the road map quarterly with a two-year rolling window. Long-range (next 100 months): The focus is on devising a strategic plan. Establish a long-term target maturity level, develop integration requirements and enterprise standards, and make policy decisions (addressing what to develop in-house and what to outsource, etc.).These activities are grouped based on how quickly we think they can be completed. The detailed plan is driven by the priority that each enterprise places on the overarching objective. Some of the medium- and long-range activities can start immediately and proceed in parallel.具体整合的程度由多方面的因素在决定，可以根据企业的具体情况，制定不同的整合规划。短期规划（100天内）：制定战术性计划，立即需要的且是可以实现的。慢慢增加新的功能或启动新的计划。中期规划（100周内）：准备一个业务流程及it路线图。列出所有相关业务和it活动，标识相关内容，异2年为限，季度性的更新路线图。长期规划（100月内）：制定一个战略性的规划。确立长期性的成熟目标，确定整合需求，及企业标准，制定政策。Consolidate First, Integrate Second强化为先，整合其次Just because we can integrate independent systems doesnt mean that it should be our first choice for developing business solutions. Integration adds overhead and additional layers of complexity that should be done only when necessary. The first choice, whenever feasible, should be to consolidate disparate systems that perform similar functions.整合增加了企业的费用和额外的复杂性，只有必需才实行。首要的选择应当是加强执行业务功能的离散系统。Many fragmented, overlapping systems in organizations today are the result of different parts of a company building their own systems and duplicating functions that exist elsewhere. This is especially true when companies merge. To prevent this, organizations must adopt a stronger predisposition to consolidate system components and increase reuse across the enterprise.This principle does not negate the principle of business process evolution or intentional variation in processes. Having duplicate systems performing similar functions can be good if we understand that the objective is not to permanently operate with competing processes, but to use both systems only until we determine which one is best.Principle 3: Use a process-driven approach to develop end-to-end solutions.采用流程驱动方式来开发端到端解决方案Enterprise-level integration is challenging because it requires dealing with multiple integration problems for which theres no single solution. Integration dimensions can include data, process, platform, network, organization, location, employees, customers, and products, among others. 企业级集成具有挑战性，因为它需要处理许多集成问题，而不存在一个通用解决方案。集成因素包括，数据，过程，平台，网络，组织，地域，员工，客户，产品，等等。With so many variables, the potential solutions are infinite. Thousands of competing software products address the integration challenge. Where do we start? Traditionally, a data-centric approach to integration has been prominent, but this conflicts with EAI principle 4. Furthermore, some industry analysts say that 80 percent of electronic data in companies is unstructured (that is, it resides outside of databases, typically in text files). With the explosion of the Web and the appearance of content-based search engines, its becoming increasingly clear that data can be accessed successfully even without a database. Still, the distinction between structured and unstructured data remains critical.面对如此之多的变数，解决方案也不确定。存在许多的软件产品应对整合的挑战。该从何而起?通常，一个以数据为中心的整合方案会首先进入人们的眼帘，但这同规则4冲突。许多分析家宣称80%的数据是非结构化的，分散在数据库之外。随着互联网的发展和基于内容的搜索引擎的出现，数据可以轻松访问而无须数据库。然而，结构化和非结构化数据处理的差别依然严重。In some organizations, data integration (or another integration dimension) is the biggest immediate problem and will drive the integration solution. Data and other corporate assets are key dimensions, but the integration cornerstone generally is the business process.在某些企业中，数据集成（或其它集成要素）是最大的问题，决定着集成方案。数据和其它要素作为主要考虑因素，但是集成的基础通常为企业流程。The business event model is the common integration element driving all others. The business event is a container of data that occurs in a process context. Its the first step in bringing the process and data dimensions together. Changes to the end-to-end business processes should be driven through the business event model at the enterprise level, down to the departmental and application level, up to the supply chain level and across to other integration dimensions (location, systems, network, etc.).业务流程模型通常驱动其它的要素。业务事件在处理的上下文中包含了需要的数据。端到端的业务处理过程由企业级的业务事件模型驱动，下到部门和应用层次，上到供应链层次，并且关联其它集成要素（地域，系统，网络等）。Principle 4: Establish clear lines of ownership and accountability.确定明晰的属主和责任整合最终的责任总会落在高层领导身上，包括CIO , CFO ，甚至CEO。然而，集成使得分散的元素像一个整体一样工作。集成总是缺乏明确的责任者。属主和责任的两个重要方面是： 初始的集成方案开发、部署管理 现有共享集成设施的维护管理The ultimate responsibility for integration always resides with a C-level executive (chief information officer, chief financial officer, and even chief executive officer). However, since integration involves making independent elements work as one, integration initiatives often lack clear owners of daily responsibilities. Two critical aspects of ownership and accountability are: Program management for the initial deployment of an integrated solution Ongoing management of the shared integration infrastructure.Many organizations recognize the need for a program team for the initial integration integration deployment and appoint a program manager to head up the effort and assume overall responsibility. The program manager is responsible for marshalling resources and coordinating the efforts of related projects to achieve a specific overall objective. Program management is a relatively well-established discipline with a large body of knowledge available. Unfortunately, few organizations have clearly defined ownership and responsibility for sustaining system integration. Without this accountability, solutions rapidly degenerate once theyre deployed because the components continue to evolve independently with insufficient focus on evolution of the integration as a whole. The well-understood organizational problem is that local optimization leads to global deterioration. Global control and standards are part of the equation, but these must be tempered with the realization that an ecology isnt a machine, and there will always be areas beyond global control. The solution is to build up an organizations capability to understand and reuse systems resources built with little architecture. This would include an embedded metadata layer, as well as technologies such as data profiling and reverse architectural engineering. Proactively managing and maintaining deployed integration must be someones primary responsibility. This generally involves the creation of a central EAI management group with a leader and a staff to support the scope of responsibilities.需要建立一个专门小组来进行整合，是所有组织都能意识到的。然而整合结束后呢？因为系统发展的，局部的优化导致整体的恶化。如何解决这个问题。问题的答案是建立一个小组，需能够理解并重用系统资源。管理和维护整合系统是他们的主要职责。Principle 5: Enforce EAI architecture明确EAI体系结构Architecture refers to how computer system components are organized and integrated. A multi-tiered, non-redundant, coarse-grained architecture should be defined and enforced across the enterprise.A multi-tiered, non-redundant architecture means the total set of functions involved in the end-to-end integrated solution are provided by distinct layers, each providing unique and non-overlapping services. This architecture must apply to the entire enterprise and should be coarse grained to provide sufficient high-level consistency for interoperability and a certain degree of local freedom. For example, the architecture should support semantic diversity (different interpretations of the same data) and permit use of diverse technical tools and techniques. Where to draw the line between enforced standards and individual choice is a matter of enterprise culture and policy.The architecture should also provide the basis for organizational responsibility and ownership of each layer. For example, the architecture may state that: Business data persists at the application component layer and not in the middleware layer. Stewardship of the data (including transforming it to a common enterprise definition, maintaining its integrity, availability, etc.)is the responsibility of the application owner.Theres no standard enterprise architecture; each enterprise must create its own. Figure 1, an outline of five-tiered architecture, could be used as a conceptual starting point:Notes on the EAI architecture: The business process layer may or may not exist in a given enterprise. If it does exist, it may not come into play in a given integration since the process mediation layer can handle some rudimentary (根本的，未发展的) inter-application processes and maintenance events. This layer really emerges when theres a clearly identified business process owner and a business process management tool is used. The inference engine (推理机) provides linguistic interpretation rules for ambiguous inputs and to generate a “best fit” output based on “fuzzy logic” principles. This is a critical EAI service since translating information from one domain to another with different semantics and no “crisp” mapping rules is a common problem.Principle 6: Mandate integration requirements for new applications在新应用中考虑整合需求Application requirements are generally specified by end users or application owners focused on maximizing the applications utility within their defined domain . Integration is often an after thought. This can drive up integration costs over the life of the application. For example, applications should be designed such that every function a user can perform through a Graphical User Interface (GUI) or system command can also be performed through an Application Program Interface (API). For applications to talk with each other requires some form of API, but for many applications, the API is missing or incomplete. 每个功能均提供api.Consider another example: Applications should be designed with the assumption that theyll be part of a larger, end-to-end process. Specifically, the applications internal processes should have multiple points at which the process could be started and stopped (by inbound events) and checkpoints (outbound triggers) for participation in a flexible, enterprise wide process.Since they involve design considerations that arent readily changed for applications already in production, it will take many years for integration requirements to permeate an enterprise. Still, these essential, non-functional requirements should be added to the functional requirements. Ultimately, this will help reduce the cost of end-to-end solutions.Principle 7: Develop a common representation of data and process.建立数据和过程的通用表示。The goal of this principle is to create an interchange language thats: Common to all applications within the enterprise Generic enough to be decoupled from any application Robust enough to represent an applications data and process information .This would facilitate communication between the various applications because they would all “speak the same language”. There are many efforts under way throughout the industry to gain agreement on common definitions of data and process elements. Some industry segments have progressed further than others. For example, the manufacturing industry has its Standard for the Exchange of Product data (STEP), which can be used to exchange product models among Computer-Aided Design (CAD) systems. Various industry bodies, led by the National Institute of Standards and Technology, are working on Process Specification Language (PSL) to permit the interchange of process models between different manufacturing processes. Its not clear when, if ever, we can expect to see a truly universal, industry-neutral interchange language. Until then, each enterprise must develop its own common language preferably in collaboration with existing standards bodies within their own industry.A critical point is deciding on the semantics with which to develop the common language. The Object Management Group (OMG) Managed Object Format (MOF) provides a superior approach. Its the only M3-level meta-meta-model with widespread acceptance. If its used as a base mother tongue, well have greatly increased the ease of systems interoperability and understanding.Principle 8: Test early and often.Despite the limitations of models and the risks of abstracting away too many relevant details (EAI law five), we must continue to work toward building better models. The goal is to build executable models and simulators that are close enough to real-world processes and systems to provide meaningful management information with a reasonable ability to predict outcomes. We should be able to do so at a small fraction of the cost of the real thing. Theres a tendency in the early stages of an integration project to describe the solution in abstract terms while leaving many of the details to later stages. Often, this means that programmers end up making business decisions or that theres a great deal of churn in the design and coding phase to resolve the details. The power of a simulator, even in the early stages of requirements definition, is that it forces early disciplining in resolving details about the process and data to be exchanged between systems. This can greatly reduce time, cost, and risk in later phases. Simulators can also be effective in: Testing components and end-to-end integration Validating “what-if ” scenarios for alternate business processes Supporting change management and end-user training programs.Thorough use of simulation for end-to-end processes in a given enterprise helps business and technology leaders modify parameters and process rules and observe the result. The more we do this, the closer we can come to realistically predicting outcomes.What we need is the equivalent of the human genome map for DNA. In Enterprise Application Integration (EAI) terms, this means we need a standard definition of every function of all applications within an enterprise or supply chain. Universal Description, Discovery, and Integration (UDDI) and Web Services Description Language (WDSL) are two technologies that could provide the registry and metadata definition for the application function map. Unfortunately, these World Wide Web Consortium (W3C) specifications must be reconciled with the OMG. Generating a complete map for a supply chain could include between 100,000 to 1,000,000 functions and is likely to be as big a task as mapping the human genome. To sum up key concepts: Use simulation in the exploratory stage to predict possible outcomes of decisions and changes to technology or business process . Use integration simulators to test requirements before detailed design and coding begins . Write software components with built in testing functionality so that they can constantly test themselves .Principle 9: Re-factor interfaces constantly so they never become legacy.A stable interface is key to sustaining quality integration, yet theres no stability in applica