Cockpit: Decision Support Tool for Factory Operations and Supply Chain Management (continued)


Previous Next     Page 5 of 14

COCKPIT ARCHITECTURE

Architecture Design Guidelines

The single most important attribute of a software architecture design is the ability to handle change. The Cockpit's architecture is designed to adapt to ever-changing technology, user base, and business requirements. Optimized for application-specific requirements, the criteria driving the Cockpit's architectural design and technology selection included the following:

  • maintainability, scalability, extensibility, and interoperability

  • multidimensional query support and drill-down capability

  • highly interactive active and static views

  • various levels of user sophistication

  • guaranteed and consistent performance for LAN, WAN, and off-line environments

  • push/pull information delivery, coupled with the ability to provide scanning and notification information in near real-time.

The ATM Cockpit addresses these system and application-level requirements through adoption of an n-tier Internet architecture, utilizing subsystem interfaces that conform to open industry standards and the Intel internal architecture reference model.

The Cockpit's component architecture is based on Windows* Distributed interNet Applications (DNA)*, and its decision support implementation is consistent with Microsoft data warehouse and Intel DSS UtilityŽ architecture frameworks.

Overview of Component Architecture

The Windows DNA backbone provides the foundation for the Cockpit's Component Object Model (COM) based components to easily deploy, scale, and interoperate in the Internet environment. Based on Internet Explorer*, the Cockpit's presentation layer relies on Microsoft Office 2000* Web Components (PivotTable and PivotChart) to present multidimensional data in table and graphical formats. Custom Cockpit ActiveX* objects provide user-friendly navigation that drives Office 2000* Web Components. These components facilitate seamless integration with Excel 2000*. For future extensibility of the presentation layer, the Cockpit's architecture supports replacement of these components with other vendor solutions. The Cockpit's business layer provides the security and personalization services necessary to ensure that the Cockpit application is secure and easy to use. The above services are provided through server-side components built on Site Server and Active Server Pages (ASP).

Site Server offers data persistence to the Cockpit's personalization information through a Lightweight Direct Access Protocol (LDAP) interface that provides the migration path to the future Windows 2000* Active Directory* service.

Figure 7: Reusable framework components for the Cockpit UI Indicator Reporting module

Reusable UI Framework

The largest benefit of the Cockpit's architecture is realized through the use of OLAP technology. The OLAP engine encapsulates multidimensional query process complexity from the Cockpit's user interface (UI) and business logic. Communication between client-side Office 2000 Web Components and OLAP cubes (data) are handled through the OLE DB1 for OLAP (PivotTable Service) database standard on the client.

The abstraction layer, supplied by client-side PivotTable Service, allows the Cockpit client to connect to OLAP data on the server over the LAN, across a WAN connection, or on the user's PC. This abstraction layer aids in insulating the UI from the data source.

Any OLAP cubes implemented by other organizations are directly accessible from the Cockpit's UI and middle layer components. Other non-OLAP data sources or data structures can be accessed through a custom OLE DB for OLAP Provider.

Consequently, the Cockpit's UI and middle-tier implementation can be used as an enterprise UI framework for all OLAP applications within the company. This helps the bottom line by avoiding redundant cross-company development time and cost.

The Cockpit User Interface

Figure 8: Reusable framework components for the Cockpit UI Scanning and Notification module

The Indicator Reporting Module
The Cockpit's Indicator Reporting module allows access to all information contained in the Cockpit OLAP database. When we were considering the look-and-feel for the Cockpit user interface (UI), we initially reviewed several commercially available tools that provide Web-based OLAP analysis. Although these tools were generally quite capable, further research revealed several notable problems when it came to the Cockpit's business requirements.

Firstly, these tools are aimed at users with OLAP experience. The Cockpit's customer base of senior managers with minimal or no OLAP experience would have to undergo significant training.

Secondly, these tools allowed for little customization and would require a comprehensive single vendor solution. Clearly, our implementation would benefit from a customizable front-end and the ability to interoperate with industry standards at all levels of the application.

The Scanning and Notification Module
The Scanning and Notification module, as the name reflects, scans Intel's internal and external environment for potential problems and events of interest, and reports the results to the user via a push mechanism. The current implementation uses an active channel approach to deliver events to the user. This implementation requires a separate front-end and a small stock-ticker-like tool to run on the user's machine. We are exploring other simpler ways to disseminate the event information; Microsoft Outlook* and e-mail are two possibilities.

Overview of DSS Architecture Framework

The Cockpit's back-end data services comply with Intel's DSS Utility architecture framework. Intel IT DSS Utility partners provide OLAP cubes that are suitable for multidimensional query capability. These cubes adhere to an established extract, transform, and load process. All Cockpit indicator data resides in databases optimized for OnLine Transaction Processing (OLTP) in the manufacturing execution and other operational environments. Extracted data are sent through a cleansing process for storage in the corporate-wide data warehouse.

The Cockpit dependent data mart2 is derived from the corporate-wide data warehouse. OLAP cubes are built from Cockpit's staging data mart. The resulting cubes can then be hosted on the same or on a different server to be accessed by the Cockpit's UI front-end.




Previous Next     Page 5 of 14

1 The OLE DB for OLAP (PivotTable Service) database standard from Microsoft offers an SQL client/server solution with a standard access method to data and the ability to use various front-ends.
2 Dependent data mart is a type of data mart that acts as a subset of a larger data warehouse which combines databases across an entire enterprise. Data marts are usually smaller than larger data warehouses and focus on a particular subject or department.