InfoQ: Graph Databases, NOSQL and Neo4j

InfoQ: Graph Databases, NOSQL and Neo4j

Relationships between standards

Typical parameters in impact prediction and decision-making

Typical parameters to be taken into account in impact prediction and decision -making include:
•  nature (positive, negative, direct, indirect, cumulative);
•  magnitude (severe, moderate, low);
•  extent/location (area/volume covered, distribution);
•  timing (during construction, operation, decommissioning, immediate, delayed, rate of change);
•  duration (short term, long term, intermittent, continuous);
•  reversibility/irreversibility;

•  likelihood (probability, uncertainty or confidence in the prediction);
•  significance (local, regional, global).

仪表板和记分卡的区别是什么？

许多人互换使用“仪表板”和“记分卡” 这两个术语，但是，这两个术语之间存在显著差异。记分卡是一种报表类型，用于显示关键绩效指标 (KPI) 和每个 KPI 的性能目标的集合。而仪表板是一个容器，其中包含相关的记分卡组和在 SharePoint 网站中组织在一起的报表视图。换言之，仪表板包含其他项目（比如记分卡、报表和筛选器）的集合。

什么是报表？

报表是根据特定业务要求转换为有格式和组织好的信息的数据的样式表。您将在仪表板上看到的报表类型包括分析图表和网格、Excel Services 报表、网页报表和 ProClarity Analytics 报表。报表可以是简单的静态图像或高度交互的数据显示形式。您可在一些类型的报表中对数据进行排序、筛选以及向上钻取、向下钻取或钻取。

什么是记分卡？

记分卡用于根据目标测量绩效。一般情况下，记分卡显示用于直观传达组织在努力达到特定目标时的整体成功或失败的图形指标。记分卡基于一组关键绩效指标 (KPI)，每个指标都代表组织绩效的某一方面。将这些 KPI 组合在一起，可提供特定时间点的组织绩效的快照。下列屏幕截图所显示的是一般记分卡。

什么是 KPI？

KPI 是一种与目标相关联的度量。KPI 通常表示度量值距其预先确定的目标的距离。KPI 分数及其指标旨在让业务用户一目了然地了解结果是否达到目标。例如，最常用的一种衡量零售是否成功的标准是同店销售额。如果特定商店的销售额逐年提高，则管理层将会认为该店的表现稳定。如果该店某一年的表现没有往年好，则管理层可能会感到担忧。合理的目标可能是每家店的销售额每年增长 10%，然后相应设置 KPI。

什么是指标？

指标有时也称为图标，是提供有关绩效的直观提示的图形元素。指标使用红绿灯符号，红色表示存在问题，黄色表示可能存在问题，绿色表示绩效达到或超过其目标。但是，也可使用其他类型的指标（比如对勾或笑脸符），具体取决于用于创建记分卡的程序。

什么是仪表板？

仪表板是各种类型报表的容器，其中包括记分卡。它可能包含一个或多个页面，且每个页面上可能具有多个模块。这些模块称为 Web 部件。典型的仪表板可能包含一个记分卡、一个分析报表和一个分析图表，但也可能存在许多变体。一些仪表板为用户提供高级交互功能，其他仪表板则显示静态图像。交互的程度和类型取决于用于创建仪表板的程序。

每个 Web 部件都保持一个与其数据源的连接。Web 部件相互之间可独立操作，也可以链接到一起，这样，您在一个部件中单击的目标将确定您在其他部件中看到的内容。将这些报表组合在一起，可清楚地了解当前组织绩效。

http://office.microsoft.com/zh-cn/sharepoint-server-help/what-is-the-difference-between-a-dashboard-and-a-scorecard-HA101772797.aspx

Scorecards and Dashboards – What’s the Difference?

Advanced Metadata Architecture

by David Marco

Published: July 1, 2000

Published in TDAN.com July 2000

Corporations are demanding more and more functionality from all of their IT (information technology) systems, and meta data repositories are no exception to this rule. In this article I will address the more complexed architectural challenges that arise with implementing a meta data repository that requires more advanced functionality. While most repository initiatives are not attempting to implement these features, they are certainly the type of functionality that is being demanded from corporations. It is also important to note that these concepts can be implemented separately or in-conjunction with one another.

Bi-Directional Meta Data

Typically the architecture of a meta data repository is one directional. Meta data sources (i.e. data modeling tool, extraction/transformation/load tools, front-end tools, etc.) flow into the repository and are integrated together to satisfy the various needs of the business (business meta data) and IT (technical meta data) department. A bi-directional meta data architecture allows for meta data to be changed in the repository and then be feed back from the repository into it’s original source. For example, a user could go through the repository and change the name of an attribute (field) in one of the decision support system’s data marts. This change would then be feed back into the supporting data-modeling tool to update the physical model for that specific data mart.

This architecture is highly desirable for two key reasons. First, it allows vendor tools to share meta data. This is especially desirable in the decision support marketplace. Most corporations that have built a decision support system did so with “best-of-breed” tools, as oppose to integrated tool sets that are supplied by one vendor. However, these tools are not integrated with one another and do not easily communicate. Even those tools that can be integrated traditionally require a good deal of resource intensive manual programming in order to share meta data. Second, bi-directional meta data is attractive to corporations that want to implement a meta data repository on an enterprise-wide scale. By enterprise-wide meta data I mean companies that want their meta data repository to store information on all of their IT systems (both decision support and operational systems). A bi-directional architecture would allow a corporation to make global changes in the meta data repository and have those changes sweep throughout all of the tools of their enterprise.

Figure 1: Bi-Directional Meta Data Architecture

As we can see a bi-directional meta data architecture provides a corporation tremendous value in allowing their disparate tools to communicate with one another. This need is why both the Meta Data Coalition (MDC) with the Open Information Models (OIM) and the Object Management Group (OMG) with the Common Warehousing Metadata (CWM) have looked to resolve this situation by providing a industry standard meta model. The meta model is the physical database model that will store the meta data. By creating an industry standard meta model third party vendor tools can plug their applications into this model to share meta data with one another. Bi-directional meta data will become a reality as a global meta model standard emerges from either these groups. It is important to understand that even once we have a meta model standard it will take time for the various software vendors modify their applications to work with this standard. This will enable these applications to have the ability to share data, which creates tool interoperability. Each vendor’s tools have unique internal designs to them. As a result, even after we have a global meta model standard for decision support, and the vendors modify their tools to support it, we will not have 100% meta data sharing. I do believe that it is possible to have a good 75% of the meta data be sharable, which is a much better situation than what we have to deal with today.

Bi-Directional Architectural Challenges

There are three obvious challenges to implementing bi-directional meta data. First, is it forces the meta data repository to contain the latest version of the meta data source that it will feed back into. Second, someone can be making a change to the meta data in the repository and at the same time someone else can be making a change to the same meta data at its source. These situations must not only be systematically trapped but also resolved. Third, additional sets of program/process interfaces need to be built to tie the meta data repository back to the meta data source.

Closed Loop Meta Data

Corporations want to be able to integrate their customer relationship management system, decision support system, e-business solution to their operational systems to provide one integrated business intelligence system. By integrating these systems together information, especially customer information can be shared throughout the organization. This enables corporations to provide new and higher levels of customer service. In addition, service intensive industries (e.g. banking, financial services, retail) corporations want to have their systems make certain business decisions for them, without manual intervention. For example, a retail company that sells consumer electronics would want an e-business system that would allow a customer to go through the internet to search for and order whatever components they wanted. When the customer would select these components, a program interface would fire off to the customer relationship management system and other products that the customer has previously ordered could be offered to the customer. Maybe if the customer hasn’t ordered the items in awhile a discount would be offered. Once the customer has finished their shopping another interface would be sent to the corporate decision support system. This system would then update the customer’s credit rating and return this new rating to the e-business system. It is this type of integrated, closed loop systems that are the mark of excellence.

Of course this desire for closed loop systems will directly impact our meta data repositories. A closed loop meta data architecture allows for the repository to feed its meta data back into a corporation’s operational systems. This concept is similar to the bi-directional meta data architecture in that the meta data repository is feeding it’s information (meta data) into other applications, or in this case operational systems. The closed loop meta data architecture is gaining more and more notoriety in corporations that want to implement a meta data repository on an enterprise-wide level. This would allow a corporation to make global changes in the meta data repository and have it sweep throughout the operational systems of an enterprise.

Figure 2: Closed Loop Meta Data Architecture

Closed Loop Architectural Challenges

The closed loop meta data architecture adds some additional complexity to the meta data repository initiative. First, if the meta data that will be feed from the repository to the operational system can also be maintained in the operational system this would require that the meta data repository contain the latest version of that operational system’s meta data. If not than the user of the repository could not be sure of updating the latest copy of the meta data. Second, someone can be making a to the meta data in the repository and at the same time someone else can be making a change to the operational system. These conflicts must not only be systematically trapped, but also resolved. Third, program/process interfaces need to be built to tie the meta data repository back to operational systems. Currently few companies are attempting this architectural technique, however it is a natural progression in the architecture of meta data repositories.

Designing the Optimal Metadata Tool

by David Marco

Published: October 1, 2004

Published in TDAN.com October 2004

Many government agencies and corporations are currently examining meta data tools in the marketplace to decide which of these tools, if any, meet the requirements for their meta data management solutions. Often times these same organizations want to know what types of functionality and features they should be looking for in this tool category. Unfortunately, this question becomes very complicated as each tool vendor has their own personalized “marketing spin” as to which functions and features are really the most advantageous. This leaves the consumer with a very difficult task, indeed especially when it seems like none of the vendors tools fully fit the requirements that your meta data management solution requires. At EWSolutions we have several clients that have these exact same concerns about the tools in the market.

Although I have no plans on starting a software company, I would like to take this opportunity to play software designer, and present my optimal meta data tool’s key functionality.

One of the challenges with this exercise is that meta data functionality has a great deal of depth and breath. Therefore, in order to properly categorize our tool’s functionality, I will use the six major components of a managed meta data environment (MME):

• Meta Data Sourcing & Meta Data Integration Layers
• Meta Data Repository
• Meta Data Management Layer
• Meta Data Marts
• Meta Data Delivery Layer

I will now walk through each of these MME components and describe the key functionality that my optimal meta data tool would contain.

Meta Data Sourcing & Meta Data Integration Layers

For simplicity sake I will be discussing this “dream” tool’s functionality for both the meta data sourcing and the meta data integration layers together. The goal of the meta data sourcing and integration layers is to extract the meta data from its source, integrate it where necessary, and to bring it into the Meta Data Repository.

Platform Flexibility

It is important for the meta data sourcing technology to be able to work on mainframe applications, distributed systems and from files (databases, files, spreadsheets, etc.) off of a network. These functions would have to be able to run on each of these environments so that the meta data could be brought into the repository. I did not include AS 400 environments in my list of platforms because of its fairly sparse use; however, if your information technology (IT) shop’s preferred application platform is AS 400, clearly your optimal meta data tool would work on that platform.

Prebuilt Bridges

Many of the current meta data integration tools come with a series of prebuilt meta data integration bridges. The optimal meta data tool would also have these prebuilt bridges. Where our optimal tool would differ from the vendor tools is that this tool would have bridges to all of the major relational database management systems (e.g. Oracle, DB2, SQL Server, Informix, Sybase and Teradata), the most common vendor packages (e.g. Siebel, SAP, PeopleSoft, Oracle, etc.), several code parsers (COBOL, JCL, C+, SQL, XML, etc.), key data modeling tools (ERWin, Designer, Rational Rose, etc.), top ETL (extraction, transformation and load) tools (e.g. Informatica, Ascential) and the major front-end tools (e.g. Business Objects, Cognos, Hyperion, etc.),

As much as is possible I would want my meta data tool to use utilize XML (extensible markup language) as the transport mechanism for the meta data. While XML cannot directly interface with all meta data sources, it would cover a great number of them.

These meta data bridges would not just bring meta data from its source and load it into the repository. These bridges would be bi-directional and allow meta data to be extracted from the meta data repository and brought back into the tool.

Lastly, these meta data bridges wouldn’t just be extraction processes, but also have the ability to act as “pointers” to were the meta data is located. This distributed meta data capability is very important for a repository to have.

Error Checking & Restart

Any high quality meta data tool would have an extensive error checking capability built into the sourcing and integration layers. Meta data in a MME, like data in a data warehouse, must be of high quality or it will have little value. This error checking facility would check the meta data which it is reading and would check it for errors and then capture any statistics on the errors that the process is experiencing (meta meta data). In addition, the tool would have error levels of the meta data. For example it would give the tool administrator the ability to configure the actions based on the error that occurred in the process. For example, should the meta data be 1) flagged with an informational/error message; or 2) flagged as an error and then not loaded into the repository; or 3) flagged an a critical error and the entire meta data integration process is stopped.

Also this process would have “check points” that would allow the tool administrator to restart the process. These check points would be placed in the proper locations to ensure that the process could be restarted with the least degree of impact on the meta data itself and on its sourcing locations.

Meta Data Repository

The meta data repository component is the physical database which is persistently cataloging and storing the actual meta data. The repository, and its corresponding meta model comprise the backbone of the MME. Therefore, in listing out the optimal meta data tool’s functionality I will pay special attention to the design and implementation of the meta model.

Meta Model Design

A meta model is a physical database schema for meta data. Anytime an MME is being implemented there are integration processes that need to be custom built in order to bring meta data into the repository. Therefore, a good meta model needs to be understandable to the repository developers working with it. As a result, the meta model should not be designed in a highly abstracted, object-oriented manner. Instead mixing classic relational modeling with structured object-oriented design is the preferable approach to designing a meta model. On the other hand, when highly cryptic (abstracted) object-oriented design is used for the construction of the meta model, it becomes unwieldy and difficult for the IT developers to work with.

The possible exception to this guideline would be if the abstracted object-oriented model has relational views built on the model that would allow for read/write/update capabilities. These views must be understandable and fully extendible.

Meta Model Implementation

The meta data repository must not be housed in a proprietary database management system. Instead it should be stored on any of the major open relational database platforms (e.g. SQL Server, Oracle, DB2, Informix, Teradata, Sybase) so that standard SQL can be used with the repository.

Semantic Taxonomy

Many government agencies and large corporations IT departments are looking to define an enterprise level classification/definition scheme for their data. This semantic taxonomy would then provide these organizations with the ability to classify their data, in order to identify data and process redundancies in their IT environment. Therefore, the optimal meta data tool would provide the capabilities to capture, maintain and publish a semantic taxonomy for the meta data in the repository.

Meta Data Management Layer

The purpose of the meta data management layer is to provide the systematic management of the meta data repository and the other MME components. This layer includes many functions, including (see Figure 1: Meta Data Management Layer):

• Archiving - of the meta data within the repository
• Backup - of the meta data on a scheduled basis
• Database Modifications - allows for the extending of the repository
• Database Tuning - is the classic tuning of the database for the meta model
• Environment Management - is the processes that allow the repository administrator to manage and migrate between the different versions/installs of the meta data repository
• Job scheduling - would manage both the event-based and trigger-based meta data integration processes
• Purging - should handle the definition of the criteria required to define the MME purging requirements
• Recovery - process would be tightly tied into the backup and archiving facilities of repository
• Security Processes - would provide the functionality to define security restrictions from an individual and group perspective
• Versioning - meta data is historical, so this tool would need to version the meta data by date/time of entry into the MME

Figure 1: Meta Data Management Layer

The optimal meta data tool would also have very good documentation on all of its components, processes and functions. Interestingly enough too many of the current meta data vendors neglect to provide good documentation with their tools. If a company wants to be taken seriously in the meta data arena they must "eat their own dog food".

Meta Data Delivery Layer

The meta data delivery layer is responsible for the delivery of the meta data from the repository to the end users and to any applications or tools that require meta data feeds to them.

Web Enabled

A java based, web-enabled, thin-client front-end has become a standard in the industry on how to present information to the end user and it certainly is the best approach for an MME. This architecture provides the greatest degree of flexibility, lower TCO (total cost of ownership) for implementation and the web browser paradigm is widely understood by most end users within an organization.

This web enabled front-end would be fully and completely configurable. For example, I may want options that my users could select or I may want to put my company's logo in the upper right hand corner of the end user screen.

Pre-Built Reports

Impact analysis reports are technical meta data driven reports that help an IT department assess the impact of a potential change to their IT applications (see Figure 1: "Impact Analysis: Column Analysis for a Bank" for an example). Impact analysis can come in an almost infinite number of variations, certainly the optimum meta data tool would provide dozens of these type of reports pre-built and completely configurable. Also the tool would be able to push" these pre-built reports and any custom built reports to specific users or groups of users desktops, or even to their email address. These pushed reports could be configured to be released based on an event trigger or on a scheduled basis.

Figure 2: Impact Analysis: Column Analysis for a Bank

Website Meta Data Entry

Most enterprise meta data repositories provide their business users a web-based front-end so that the data stewards can enter meta data directly into the repository. This front-end capability would be fully integrated into the MME and it would be able to write back to the meta data repository. In addition, not only would this entry point allow meta data to be written to the repository, it would also allow for relationship constraints and drop-down boxes to be fully integrated into the end user front-end. Moreover many of these business meta data related entry/update screens would be pre-built and fully configurable to allow the repository administrator to modify them as required. The ability to use the web front-end to write back to the repository is a feature that is lacking in many of today's meta data tools.

Publish Graphics

The optimal meta data tool would also have the ability to publish graphics to its web front-end. The users would then be able to click on the meta data attributes within these graphics for meta data drill-down, drill-up, drill-through and drill-across. For example, a physical data model could be published to the website. As an IT developer looks at this data model they would have the ability to click on any of the columns within the physical model to look at the meta data associated with it. This is another weakness in many of the major meta data tools on the market.

Meta Data Marts

A meta data mart is a database structure, usually sourced from a meta data repository, that is designed for a homogenous meta data user group (see Figure 2: "Meta Data Marts"). "Homogenous meta data user group" is a fancy term for a group of users with like needs

Figure 3: Meta Data Marts

This tool would come with pre-build meta data marts for a few of the more complex and resource intensive impact analysis. In addition, we would have meta data marts for each of the significant industry standards like Common Warehouse Meta Model (CWM), Dublin Core and ISO 11179.

Metadata Management Foundation Capabilities Component

http://mike2.openmethodology.org/wiki/Metadata_Management_Foundation_Capabilities_Component

Foundation Capabilities for Metadata Management are the basic capabilities required to model, integrate, store, distribute and publish metadata to support an Information Architecture. While Metadata Management is a core component that could stand alone, management of metadata crosses each foundation capability in the Information Architecture. Metadata Management foundation capabilities provide functions to other foundation components and upward to support metadata Enabling Technology services.

Contents  [hide] 1 Model Management 2 Metadata Integration 3 Identity Matching 4 Validation 5 Versioning 6 Configuration Management 7 Model Query 8 Access Control

Model Management

Model Management is the capability to manage structures and processes used to describe the metadata in a system. Organisations generate a vast quantity and breadth of metadata that is available for analysis and reuse. Not all metadata is valuable to capture and manage at any given time. Model management is the capability and discipline for describing the scope and depth of metadata in the form of a metadata model.

Metadata models are themselves an information asset that must be managed over time. The most effective metadata management systems are those that are flexible due to comprehensive model management capabilities. The core model management capabilities a metadata management system should aspire to have are:

• Definition – a capability to define metadata models through user input into a managed system

• Extensibility – a capability to extend or change the metadata model to reflect changing information consumer requirements

• Analysis – a capability to perform analysis through standard and ad-hoc reports

• Interface – a capability for other Foundation and Enabling Technologies to access metadata models through programmatic interfaces

Model management capabilities support an evolutionary metadata management system. The metadata needs of an organisation will most definitely change over time and the metadata management system must also provide the ability to adapt and change in step with the organisational needs.

Metadata Integration

A Metadata Integration capability provides a basic ability to build metadata flows into and out of a managed metadata environment. Metadata is produced and consumed by a variety of components in the Information Architecture. To achieve consistency, quality and reuse utility, metadata must be integrated between the sources of record for metadata. Metadata Integration provides the foundation for active metadata management in a model driven architecture.

Metadata Integration itself should be model driven by interfacing with Model Management capabilities in the architecture to provide a framework for repeatable development processes and reusable components to integrate metadata.

Data Lineage metadata traces the lifecycle of information between systems, including the operations that are performed upon the data. The need to establish a comprehensive view of Data Lineage has grown in importance over the past few years, particularly with renewed compliance requirements. The ability to trace lineage of data from producers to consumers will be an importance feature of the SAFE Architecture.

Identity Matching

Identity Matching as a foundation capability is both a strategic and technical component of the metadata architecture. The need for Identity stems from the inherently distributed nature of metadata throughout the Information Architecture and the desire for metadata reuse utility. To ensure consistent and accurate reuse of metadata in a model driven architecture, a system must have the ability to identify metadata uniquely so that the metadata may be reused, validated and versioned within the managed metadata environment.

Validation

Validation capabilities ensure the quality and consistency of metadata flowing through the managed metadata environment. It is critical that metadata be reliable and complete when building a model driven architecture. Metadata validation needs to be user controlled so that fit for purpose rules can provide the right balance. Not all metadata need follow the same criteria. A too stringent validation rule may prevent any metadata entering the system, but a too loose rule may corrupt the system.

Versioning

An understanding of metadata history is important metadata in itself. Versioning of metadata provides the ability for looking back into history to gain a more comprehensive understanding of the current state. Some level of metadata versioning is a foundation capability. The granularity of versions will depend on individual requirements of the organisation, but the system should provide the fundamental capability.

Configuration Management

Like other information assets, metadata has its own development lifecycle. Configuration Management is a fundamental process for developing metadata. Central to the capability of metadata Configuration Management is the role that process and governance plays in the development and operations of a managed metadata environment. Metadata governance and control involves providing the technology tools and human procedures to ensure that the system runs smoothly and evolves in a controlled manner, but also provides the agility adapt and evolve.

Model Query

Model Query provides the fundamental ability for publication of metadata and enables service oriented application development. Where metadata Integration capabilities provide low level programmatic capabilities for integrating sources of record for metadata, Model Query provides a higher-level access layer that abstracts the detail of access to metadata. Model Query capabilities form the foundation of providing Metadata Reporting Packages and is a component of providing content to Enabling Technologies in support of Metadata Services.

Access Control

Metadata can often be sensitive information that should have restrictive controls to prevent unauthorised access. Metadata Access Control is a foundation capability that compliments Model Management capability by providing a control layer over metadata models. Access control is a foundation capability for building a model driven architecture. Access Control is integrated into the metadata access mechanisms though Model Query, Integration interfaces, Metadata Services and Reporting Packages.

Metadata Access Control is complimentary to Security foundation capability for Infrastructure in the overall Information Architecture. Metadata Access Control supplements the limitations of some security systems to provide control over metadata attributes and relationships.

Metadata-Driven Enterprise Data Management – Future or Fantasy?

http://www.b-eye-network.com/view/3426
by Deborah Poindexter



Is your data out of control? Is your enterprise data management fragmented and inconsistent? Can you answer these questions? If the answer to any of these questions is no, then enterprise data management may be a discipline you should investigate. Because data is the foundation of all business decisions, enterprise data management (EDM) is continually gaining acceptance as a critical function of IT. Data must be carefully managed and controlled to achieve its full usefulness and value to the organization, and to allow sound business decisions to be made and refined. EDM comprises several components: data quality, data governance, master data management and a managed metadata environment. Typically, we manage each of these components separately with little or no overlap. Sometimes they are managed by many organizations using many disparate tools. But does this approach really accomplish what we are all looking for – consistent, high quality, dependable, interoperable data assets? If the answer is no, we must ask how can we achieve data nirvana with EDM. A metadata-driven methodology for EDM allows all components to share information about the data as it moves through its life cycle, thereby enabling consistency, accountability and true control of data assets.
What is a metadata-driven EDM? It is simply the centralized management of all metadata to create a semantically rich, robust and dynamic metadata interchange. Metadata flows bi-directionally from source to metadata repository and back to source. The managed metadata environment (MME) becomes the origination point for semantic changes, and also the system of record for security, compliance, access and regulatory policy. And of course, the MME is the single source of truth for all information about data and process.
Let’s examine how a metadata-driven approach could affect each component of EDM.

• Data Quality: To achieve data quality, a holistic view of the data is required. Solving a problem in application A can break application B. Having access to the metadata forall the steps in the life cycle allows the data quality team to easily spot points of failure, origination points and redundancies. When data quality issues are discovered, the metadata will point to the appropriate business and IT contact to begin the process of correcting the data.

• Data Governance: Data governance requires an owner and a steward for every piece of data. Having a named person who is responsible for the care and feeding of the data at any given point in its life cycle (“steward”) expedites data quality issues, change requirements, influences the development of new applications and can enable reuse of the data. Governance also helps us understand whether the data is enterprise-level or business-unit or subject-area specific data, knowledge which can be of extremely valuable in data warehouse development. Since data stewards understand their data intimately, drive standards and data quality, and generally have a vested interest in “their” data, they can be wonderful champions for a metadata-driven approach.

• Master Data Management (MDM): MDM is defined as the formulation and implementation of a unified set of principles, processes and practices, fully supported by a governing body, to provide consistent management for all corporate master data environments. MDM is such a logical way to track, explain, understand, compare and report on master data that it should be a fundamental in all organizations.
  
  For most of us, master data is the beginning of the data life cycle. A managed metadata environment allows us to understand redundant master data (sounds like an oxymoron, doesn’t it?) and whether we can clean it and reuse it. Once again, the data steward plays a critical role in this process. Nowhere in the data life cycle is impact analysis more critical than in targeting master data to be managed as part of the enterprise’s key assets. Complete, accurate and reportable metadata easily reveals the impact of changes to master data on ALL systems and their owners, which means no nasty surprises in data usage at any point in the life cycle.

• Managed Metadata Environment (MME): While we certainly capture information about data quality, data governance and master data in our MME, isn’t there more to our total data galaxy? What about our OLTP systems, data warehouses, messages and unstructured data? They should all be part of the MME. An MME allows us to link all data to its stewards, master data sources (if not the original source) and applications that access or update it. An MME shows the flow of the data into and through the OLTP systems, who is responsible for those systems as well as the data created and updated therein. It allows us to see these systems as sources and targets, both for other OLTP systems as well as for data warehouse environments. What happens to the data as it flows along its path? Where are our points of failure? What metrics are we capturing? All this information should be part of an MME.

The Metadata-Driven MethodologyIf all these attributes are captured, managed and reported from a managed metadata environment, doesn’t it make sense to make the MME the center of our data universe? That’s what a metadata-driven methodology is all about – using the metadata as the starting point for all EDM functions. Imagine a data warehouse front end that simply provides the user with a pick list of metadata objects on which to build a report. Based on the user, the MME would decide which metadata objects to display, which associated objects the user was cleared to see, what the content should contain, what formula to apply to any derived or calculated fields, and how and where to deliver the finished report. All this is metadata. Unfortunately, it is currently captured in many places by many applications and not typically managed as an asset. Having a single source for metadata knowledge is tantamount to having the Rosetta stone for the organization’s data.
Imagine every new development project starting with the MME to determine what data currently exists which can be reused, who owns the data, how comprehensive it is, what other processes affect it and where it is currently reported. The MME would also determine project scope by performing impact analysis for the entire data life cycle. It would deliver data models to your data architects, transformation rules to your integration architects, and data quality requirements and metrics to your data quality staff – all from a single point of reference.
How to Accomplish Metadata-Driven EDMOkay, so you agree to the premise that a metadata-driven enterprise data management approach is the right thing to do. Can you actually do it with existing tools? Probably not, unfortunately. Current metadata management tools are not able to effectively extract and couple all the metadata needed to produce a robust data lineage that must include identifying data stewards, transformation/integration rules, processes, metrics and security. Could you accomplish this with existing technology? Probably, but it would not be a trivial exercise.
What is the answer to this conundrum? There are many factors which will help you decide which route to take. First, is your organization managing its metadata at the enterprise level currently? If so, you are on the path to success with a metadata-driven EDM approach. If not, rally the troops and educate your organization and its management on the critical nature of metadata management. Sarbanes-Oxley (SOX) can be a good place to start! Management already understands the importance of Sarbanes-Oxley compliance. Metadata management can make gathering the legally required information for SOX a breeze.
The first step in any data-related project – or any project actually – is requirements gathering. Really understand the metadata requirements for your organization. Can the metadata-driven approach satisfy most of these requirements? If so, you can make a business case to continue your quest. Create a metadata model to help you understand these requirements. In the future, this model may become the basis for extending your current MME.
For some organizations, a large data warehousing project provides a great place to start driving this approach. To successfully build and administer a data warehouse, metadata must be clearly understood and managed. On the sourcing end of the warehouse, metadata describes where the data is extracted, who owns it, what transformations and mappings must occur to get it into the warehouse plus any cleansing activities. Operational metadata is required to properly manage, distribute and secure the data in the data warehouse. Building or interfacing with the data delivery layer of a data warehouse can be enhanced by well-managed metadata. If you are extracting data from the warehouse into marts, use your MME to capture, track and report on the destination for each data element and what rules are applied. Operational metrics may also be part of your MME. Obviously, a great deal of metadata is created and should be managed within the data warehouse. Since a data warehouse project is an area that is fairly well understood, unlike some of our legacy OLTP systems, it is often a good starting point for a metadata-driven EDM approach.
Sound like a big job? It is. This is why we are all counting on the metadata repository vendors to continue expanding and enhancing their products in the years to come. An MME must provide a way to capture, associate, maintain, navigate and report on the most valuable asset in your organization – metadata.
In the final analysis, it is obvious that a metadata-driven EDM is the best way to care for your data, but few organizations are ready for the cultural and technical challenges it presents. By continuing to grow awareness of the essential value of enterprise data and metadata management, by urging software vendors to embrace this vision, and by continuing to support the principles, processes and practices of good data management, we lay the foundation for future realization of metadata-driven enterprise data management.

site:http://www.zaptechnology.com/products/business-intelligence/business-intelligence-capabilities.asp

Zap Business Intelligence

BI Capabilities

A complete BI solution

Zap Business Intelligence is a single, complete solution to meet your business intelligence needs. Whether the management accountant is completing end of month financial reports, or the operations manager is modeling alternative price points, with Zap Business Intelligence, they use the same solution. Capabilities include:

• Dashboards
• Reports, charts, ad-hoc analysis
• Key Performance Indicators
• Scorecards
• Alerts & report scheduling
• Extending and sharing
• Business templates

Dashboards Dashboards provide an instant visual snapshot of performance. Most companies use role-based dashboards, for instance the CEO views an executive dashboard across different functions covering the entire organization, whereas regional sales managers view sales analysis for their territory. Dashboards must be easy to configure and customize to meet the varied needs of users. Zap Business Intelligence dashboards offer:

Drag-and-drop creation – Users simply drag-and-drop reports, charts, KPIs, scorecards and rich text onto dashboards – no programming is required. Dynamic resizing – Layout adjustments are automatic, such as resizing charts to fit a dashboard cell, and dynamically resizing an entire dashboard to suit the user’s screen resolution. Guided analytics – Any cell within a dashboard can be sliced by any other cell in the dashboard; meaning users can easily navigate the data based on their own personal requirements. Drill down for detail – Drill down from a dashboard to lower level reports for more detail.

Reports, charts, analysis Zap Business Intelligence provides flexible, self-service reporting that improves the accuracy and efficiency of reporting processes. Automate reporting workflows to improve the timeliness of information. This empowers users to move beyond manual reporting and provide more strategic analysis that will impact the bottom line. Unlike many alternatives, Zap Business Intelligence is a single solution for both reporting and analysis, ensuring minimal administration and training overhead. Drag-and-drop functionality includes:

Management reports – A powerful, central interface to automate and streamlines management reporting. Select reports, scorecards, dashboards and charts into a report pack, add images, title pages, a table of contents, and explanatory text to create a PDF. Reports are automatically refreshed on open. Flexible list and aggregate reports – Stop the use of unsecured spreadsheets by providing more powerful functionality than a pivot table in a central web environment. In-line charts and KPIs – Information is presented at-a-glance in pivot-tables, with instant trend insight eliminating the need to click around to find information. What-if – Developed using enhanced report features such as sliders, what-if functionality allows users to easily model different scenarios. Slicing – Superior data comparison from flexible slicing presents only what's relevant based on slice selections already made. Ad-hoc analysis – Move beyond reports that just tell you 'what' happened, to analyze the 'why' behind performance. Users can answer any question at any time, exploring multidimensional data from many different perspectives by filtering, drilling down, slicing and dicing. Deep drill-through – Navigate data in real time to find answers to even the most complex questions, without having to write new reports. Drill through on calculated members and select multiple cells within a report. Real time reports – Gain all the benefits from Reporting Services reports while providing users with a single reporting environment. Integrate real time reports and geo maps from Reporting Services in your Zap reports and dashboards, and slice them by any dimension. Flexible functions – The solution comes with extensive pre-defined formulas to help users with common calculations, such as days sales outstanding and bottom inventory count. These in-built functions range from formulas for relative time, to statistical functions and OLAP operations, adding powerful functionality to even the most basic cubes. Visualization – Add a chart to a report in a single click. Choose from a wide range of charts, and even make the chart 3D. View data hotspots with conditional formatting and heatmaps. Automated report scheduling – Schedule the automatic distribution of reports, knowing that security will be automatically applied so users only see authorized data, even for PDF management reports.

Key Performance Indicators Key Performance Indicators (KPIs) are individual metrics that measure performance against target. Zap Business Intelligence KPIs offer:

Drag-and-drop creation – Users simply drag their calculations and measures onto a KPI. No coding is required. Flexibility to customize – Users can set anchors, choosing whether ‘less is good’ or ‘more is good’ on their KPI. Add extra needles to supplement the actual and target figures. Dynamic calculations – Boundaries and target figures can be dynamically calculated, useful when using KPIs within filtered dashboards. Flexible formatting – Zap provides a wide range of gauges and options, providing a customized look and feel.

Scorecards Scorecards are a collection of key performance indicators (KPIs) providing an at-a-glance snapshot of performance against targets. Scorecards highlight business goals, and the difference between those objectives and real results. Scorecards in Zap Business Intelligence are fully configurable and provide:

Drag-and-drop creation – Users simply drag KPIs onto their scorecard. Drill through – Scorecards can be linked to underlying data, allowing users to click through and further investigate problem areas. Weighted KPIs – Weight issues within a scorecard by importance, and sort the scorecard to ensure the most important areas are viewed first. Additional metrics - Add extra columns, such as same period last year, or trend for the quarter, so users aren't restricted to showing metrics for past, current, and target figures. Automatic creation from hierarchies – Save time creating detailed scorecards. Simply create a KPI at the top level of a hierarchy, and have KPIs automatically created for the dimension members you select. This helps pinpoint exactly which area is affecting an overall KPI by viewing the products and departments that contribute to the overall figure.

Alerts and report scheduling Alerts and report scheduling provide an early warning system to notify users about changes in performance. They help automate discovery and learning, and remove the task of manually monitoring performance and providing updates. This configurable functionality includes:

Alerts – Notify users of key changes to KPIs such as gross margin falling under target, or a new sale being made; and changes to resources such as reports. Alerts can also be sent based on scheduled events, such as a daily sales update each morning. Alerts with insight – Alerts can be sent with contextual reports to immediately highlight the cause of the change. Flexible distribution and subscription – The same report can be scheduled to run multiple times with different parameters, formats, frequencies, and destinations. Report distribution is based on a combination of events and timeframes. Zap Business Intelligence users can also subscribe to existing reports to gain more control over the information they receive. PDF management reports can be distributed to non-Zap users, such as customers. Security automatically applied – Individual user security is automatically applied to any analytics that are distributed with an alert.

Extending and sharing Extend and share Zap Business Intelligence as much and as often as required.

Extend the online help – Add new tips and tricks, explanations, meta-tags or even videos within the application. Gadget – Easily display and deploy a KPI or a chart on the desktop as a Vista or Windows 7 gadget, controlling the refresh rate and setting a Drill Across Resource. Multi-tenancy – Use a single deployment of Zap Business Intelligence to serve multiple organizations. Multilingual – Zap Business Intelligence supports automatic presentation in the user's local language. SharePoint Integration – Zap Business Intelligence is SharePoint-ready, giving end users flexible slicing and filtering.

Business Templates Re-usable business templates transform the way BI is used. They drastically reduce the time and technical resources needed to create and maintain custom analytics. Templates can shorten the implementation of a BI project, and help gain immediate results that impact the bottom line.

Typically, business logic is hard-coded into reports, restricting the easy re-use of this logic across other analytics or deployments. Zap Business Intelligence incorporates business logic into a layer of building blocks, serving as the foundation for analytics. When this foundation layer is changed, all analytics are instantly updated. Zap Business Intelligence allows the creation of an entire suite of business templates based on the foundation layer, which can be easily shared across territories, companies, and entirely different deployments of the solution. With Zap Business Intelligence, simply map the foundation layer and all the analytics automatically fall into place. For example, pre-define account ranges for reports, so there is no manual selection or maintenance for individual report creators.