Appendix C. Glossary
This glossary is divided into two parts: common acronyms, and the most important integration and information technology terms used in this book. Note that this glossary will be maintained on the book’s Web site, www.integrationfactory.com.
Note: Italicized acronyms are also included in the following definitions section.
Common Acronyms
API:
Application program interface
B2B:
Business to business
B2C:
Business to consumer
BI:
Business intelligence
BPEL:
Business Process Execution Language
BPM:
Business process management or business process modeling
BPMN:
Business Process Modeling Notation
CDC:
Changed data capture
CORBA:
Common Object Request Broker Architecture
DBMS:
Database management system
DI:
Data integration
EAI:
Enterprise application integration
EDA:
Event-driven architecture
EII:
Enterprise information integration
ESB:
Enterprise service bus
ETL:
Extract, transform, load
FTE:
Full-time equivalent (staff)
HTTP:
Hypertext Transfer Protocol
ICC:
Integration Competency Center
IS:
Information systems (organizational unit)
IT:
Information technology (organizational unit)
ME&C:
Mutually exclusive and comprehensive
MDM:
Master data management
MOM:
Message-oriented middleware
ODS:
Operational data store
POC:
Proof of concept
REST:
Representational state transfer
SLA:
Service level agreement
SOA:
Service-oriented architecture
SOAP:
Simple Object Access Protocol
SOR:
System of record
SQL:
Structured Query Language
UDDI:
Universal Description, Discovery, and Integration
XML:
eXtensible Markup Language
Definitions
application: A deployed and operational IT system that supports business functions and services. Applications encapsulate data and are supported by multiple technology components. Applications may be logical or physical but are distinct from the technology components that are used to construct them.
Application program interface (API): A set of public programmatic interfaces that consists of a language and a message format to communicate with an operating system or other programmatic environment, such as databases, Web servers, and so forth. These messages typically call functions and methods available for application development.
bus: An abstract software pattern used to transfer data between multiple systems. In contrast to the hub-and-spoke pattern, it uses a federation of components that all follow a common policy or protocol to send, route, and receive messages.
business glossary: A list of business data elements with a corresponding description, enterprise-level or domain-specific synonyms, validation rules, and other relevant metadata. Used to identify the source of a record, quality metrics, ownership authority, and stewardship responsibility.
business object: An encapsulated unit of application functionality closely aligned to data and data access considerations.
business process: A structured description of the activities or tasks that have to be done to fulfill a certain business need. The activities or tasks might be manual steps (human interaction) or automated steps (IT steps). Business processes might be managed and implemented using modeling notations such as BPMN or EPC or execution languages such as BPEL. Some people differentiate between workflows and business processes by stating that business processes describe more generally what has to be done, whereas workflows describe how activities or tasks should be carried out.
canonical: Reduced to the simplest and most significant form possible without loss of generality.
canonical data model: The definition of a standard organization view of a particular information subject. To be practical, canonical data models include a mapping back to each application view of the same subject. The canonical data model is frequently implemented as an XML hierarchy. Specific uses include delivering enterprise-wide business intelligence (BI), defining a common view within a service-oriented architecture (SOA), and streamlining software interfaces.
canonical model: A design pattern used to communicate between different data formats. The basic idea is that rather that writing translators between each and every format (with potential for a combinatorial explosion), it is sufficient just to write a translator between each format and the canonical format.
capability: A thing that an organization, person, or system is able to do. Capabilities are typically very coarse-grained and may bring together a combination of people, processes, and technology.
coupling: A dependency between two computer hardware or software elements or systems. Tight coupling is when the elements are strongly dependent on each other so that when one changes, the other is impacted. Loose coupling reduces dependencies between systems through techniques such as middleware abstraction layers, asynchronous communication, or compensating transactions rather than two-phase commit transactions to maintain consistency. In general, loose coupling leads to more complexity. For this reason, in a specific architectural style it is important find the right amount of loose coupling. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.
data entity: An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations.
data governance: The policies and processes that continually work to improve and ensure the availability, accessibility, quality, consistency, auditability, and security of data in a company or institution.
data integration: Accessing data and functions from disparate systems to create a combined and consistent view of core information for use across the organization to improve business decisions and operations.
data mart: A database structured for specific analysis and historical reporting needs.
data warehouse: A subject-oriented, integrated, time-variant, and historical collection of summary and detailed data used to support the decision-making and other reporting and analysis needs that require historical, point-in-time information. Data, once captured within the warehouse, is nonvolatile and relevant to a point in time.
Enterprise application integration (EAI): An approach to integrating distributed systems so that they use a common infrastructure (middleware and/or protocol). With this approach, for each system it is enough to provide and maintain only one adapter to the infrastructure, instead of a specific adapter for each of the systems with which it communicates. The infrastructure might use a bus or hub-and-spoke approach.
Enterprise service bus (ESB): The infrastructure of an SOA landscape that enables the interoperability of services. Its core task is to provide connectivity, data transformations, and routing so that systems can communicate via services.
event: A notification sent to a more or less well-known set of receivers (consumers). Usually, the receivers of an event have to subscribe to a certain type of event (sent by a certain system or component). Depending on the programming or system model, the systems sending the events (the providers) might or might not know and agree to send the events to the subscribing receivers.
Event-driven architecture (EDA): A software architecture pattern promoting the production, detection, consumption of, and reaction to events.
governance: The discipline of tracking, managing, and steering an IS/IT landscape. Architectural governance is concerned with change processes (design governance). Operational governance looks at the operational performance of systems against contracted performance levels, the definition of operational performance levels, and the implementation of systems that ensure the effective operation of systems.
hub and spoke: An abstract software pattern used to transfer data between multiple systems. In contrast to the bus pattern, it uses a central component that coordinates all communication between senders and receivers.
information object model: A model used to provide traceability from the enterprise function and information subject models to the business glossary (i.e., an information object includes a list of data elements from the business glossary). Possibly used for assessing current information management capabilities (reflected in process and target systems models) or as a conceptual model for custom-developed application components.
integration: (1) An infrastructure for enabling efficient data sharing across incompatible applications that evolve independently, in a coordinated manner, to serve the needs of the enterprise and its stakeholders. (2) The capability for efficient data sharing across applications in a coordinated manner to serve the needs of the enterprise and its stakeholders. The end result is a system-of-systems that supports sharing data and functions across incompatible applications to create a combined and consistent view of core information for use across the enterprise to improve business decisions and operations. (3) The capability to constructively face the tensions of incompatible business systems that need to interoperate and, rather than simply coupling them to satisfy a tactical need, generating a creative solution that contains elements of the individual systems but is superior to each—in other words, creating synergy where the whole is greater than the sum of the parts.
Integration Competency Center (ICC): A permanent cross-functional team operating as a shared-services function supporting multiple organizational units and sustaining integration in a coordinated manner. Alternate names include Business Intelligence Competency Center (BICC), Integration Center of Excellence (Integration COE), Data Quality Competency Center (DQCC), SOA Center of Expertise (SOA COE), Integration Solutions Group (ISG), Enterprise Data Management (EDM), and other variants.
integration factory: A cohesive integration technology platform that automates the flow of materials and information in the process of building and sustaining integration points. Examples of automation include requirements definition, code generation, testing, and migration of code objects.
integration point: A data exchange or dependency between two business systems that provides discrete functionality and is designed and managed as a functional unit. An integration point may involve one or more interfaces with each of the systems involved and may involve any number of middleware elements, but it is still considered as one integration point. Conversely, if system A publishes the same data using the same interface to systems B and C, it is considered as two integration points (A–B and A–C). Furthermore, if data is combined from systems X and Y and then sent to system Z as a single message, it is also considered as two integration points (X–Z and Y–Z).
interface: The externally visible definition of the operations permitted on an application component.
interoperability: The ability of different systems to communicate with each other. Interoperability between different applications, platforms, and programming languages is a fundamental goal of integration.
lean integration: A management system that emphasizes creating value for end customers, continuous improvement, and eliminating waste as a sustainable data and process integration practice.
measure: A quantitative performance indicator or success factor that can be traced on an ongoing basis to determine successful operation and progress toward objectives and goals.
metadata: Data about data and data processes. Metadata is important because it aids in clarifying and finding the actual data.
meta-model: A description of a model. A meta-model refers to the rules that define the structure a model can have. In other words, a meta-model defines the formal structure and elements of a model.
methodology: A defined, repeatable approach to address a particular type of problem. A methodology typically centers on a defined process but may also include definition of content. May be used interchangeably with the term method.
middleware: Computer software or hardware that connects other software components or systems. This technology evolved to provide for interoperability in support of the move to coherent distributed architectures, which are used most often to support complex distributed applications. It includes Web servers, application servers, and similar tools that support application development and delivery. Middleware is especially integral in managing and optimizing a system-of-systems at the enterprise level. Middleware sits “in the middle” between applications that may be working on different operating systems. It is similar to the middle layer of a three-tier single-system architecture, except that it is stretched across multiple systems or applications. Examples include EAI, ETL, EII, BPM, SOA, and MOM (message-oriented middleware).
operational data store: A database that is subject-oriented, read-only to end users, current (non-historical), volatile, and integrated; is separate from and derived from one or more systems of record; and supports day-today business operations and real-time decision making.
organization unit: A self-contained unit of resources with line management responsibility, goals, objectives, and measures. Organizations may include external parties and business partner organizations.
pattern: A common combination of logic, interactions, and behaviors that form a consistent or characteristic arrangement. An important use of patterns is the idea of design templates that are general solutions to integration problems. They will not solve a specific problem, but they provide a sort of architectural outline that may be reused in order to speed up the development process.
platform: A combination of technology infrastructure products and components on which various application programs can be designed to run.
process integration: Automation of processes that cut across functional or application boundaries where process state needs to be maintained independently of the underlying application systems or where multiple data consumers or data providers need to be orchestrated as part of a business transaction.
protocol: The rules governing the syntax, semantics, and synchronization of communication.
publish/subscribe: A message exchange pattern where a service consumer subscribes to get a notification message from a service provider when a certain condition or state occurs or changes.
road map: An abstracted plan for business or technology change, typically operating across multiple disciplines over multiple years.
role: The characteristic and expected behaviors of an individual, derived from his or her responsibilities and preferences in providing value to the organization.
service: In an organizational context, a set of benefits delivered by a service provider, mostly in close coordination with other service suppliers, commissioned according to the needs of the service consumer, and used by the requesting service consumer for supporting day-to-day business tasks. For example, an ICC provides services to internal consumers that may be other IT or business functions.
service, information system: A service that is specifically provided by an automated IT-based solution. In an SOA, the IT realization of self-contained business functionality, sometimes also referred to as a Web service. Technically, a service is a description of one or more operations that use messages to exchange data between a provider and a consumer.
Service level agreement (SLA): A formal negotiated agreement between two parties that usually records the common understanding about priorities, responsibilities, and warranties, with the main purpose of agreeing on the quality of the service. For example, an SLA may specify the levels of availability, serviceability, performance, operation, or other attributes of the service (such as billing and even penalties in the case of violations of the SLA).
Service-oriented architecture (SOA): In its most general sense, an approach for architectures where the interfaces are services. In a more specific sense, it is an architectural style for dealing with business processes distributed over a large and heterogeneous landscape of existing and new systems that are under the control of different owners. The key concepts of SOA are services, interoperability, and loose coupling.
system: A set of interacting or interdependent computer hardware and software components forming an integrated unit. In this book, the terms system and application are often used interchangeably. A business system supports capabilities in a particular business domain (such as finance, marketing, manufacturing, sales, etc.), whereas an integration system supports capabilities in a particular integration discipline (such as data integration, process integration, data quality, business intelligence, etc.). See also the definition for system-of-systems.
system of record: The single authoritative, enterprise-designated source of operational data. It is the most current, accurate source of its data.
system-of-systems: The collection of interconnected systems in an enterprise. Modern systems that form systems-of-systems are not monolithic; rather they have five common characteristics: operational independence of the individual systems, managerial independence of the systems, geographical distribution, emergent behavior, and evolutionary development.
transfer price: The price that one subunit (department or division) charges for a product or service supplied to another subunit of the same organization. Transfer pricing is the mechanism used by ICCs to charge for their services on either a market, cost-plus, or negotiated basis.
web services: A set of standards that serves as one possible way of realizing an SOA infrastructure. Initially started with the core standards XML, HTTP, WSDL, SOAP, and UDDI, it now contains over 60 standards and profiles developed and maintained by standardization organizations, such as W3C, OASIS, and WS-I.
workflow: Similar to a business process; a description of the activities or tasks that have to be done to fulfill a certain business need. Some people differentiate between workflows and business processes by stating that business processes describe more generally what has to be done, whereas workflows describe how activities or tasks should be carried out.