Our Model

Design Goals

We architect solutions that are based on a set of clearly-defined design goals. These goals, and NOT technology, are what dictate the solutions we recommend and employ.

Simplicity The architecture must be based on a limited set of elements that integrate well with one another. The principles of the design for each element should be well understood, and the suitability for their intended use must be accepted within the software engineering community.

Reliability The architecture must provide fault-tolerant-level reliability for mission-critical applications. As such, it should be composed of elements and protocols that are considered "industrial strength."

Extensibility Architectural components must be able to integrate with the current set of transaction processors and inquiry systems, and with those yet to be developed.

Availability Applications that produce and maintain enterprise data values may require periodic downtime maintenance. Nevertheless, access to enterprise-level information that is generated by an OLTP application, a batch application, or an externally generated data feed must be accessible to inquiry applications throughout the enterprise on a 24x7 basis.

Fault Management The architecture must support rapid automated detection and recovery from hardware and communication failure. It must also support administrative notification and alarms in the event of a failure.

Efficiency The solution must make efficient use of client, server and network resources.

Security The architecture must support user authentication and authorization, and the ability to audit all inquiry requests and service requests.

Scalability The architecture must support applications that may scale from small work groups to the entire enterprise, and the ability for an application to integrate geographically remote sites, including corporate and customer sites.

Portability Applications and their distributed components must be portable across hardware and operating system platforms, and be accessible by languages used in legacy systems and those supported in emerging or future technologies.

Ease of Development and Administration Components used for application development must facilitate rapid application development and maintenance. APIs must be consistent and intuitive. The system must be relatively easy to administer and manage.

Non-Disruptive Implementation The implementation of the architecture and its components should be relatively non-disruptive to the usability of existing systems, and it should not significantly impede the ongoing development efforts of the various application development teams. Any architectural change must provide users with at least the same level of function and ease of use.

Time to Development There must be a high degree of confidence that the architecture can be implemented within the timeframe that is agreed upon.

• Development
• Testing
• Implementation
• Training
• Licensing and
• Maintenance

Enterprise Information Integration and Straight Through Processing

There are several key concepts that differentiate the MQS enterprise informational model (EIM).

Background

Activities that impact the state of a business enterprise have become increasingly dispersed, and are no longer confined to one or two mainframes in the corporate data center. Nevertheless, a change in the state of one data element is often significant beyond the boundaries of the process that acted upon that data element.

There have been various architectural attempts to reconcile the impact of an increasingly distributed systems network. Periodic consolidation and reconciliation have been attempted though data warehousing, and the adding of inquiry function to transactional processors. Each of these approaches possess inherent architectural limitations.

EIM™ is MQS's highly extensible distributed integration model. This architectural model and and the use of open integration components greatly simplifies the task of delivering highly distributed data integration, and ensures that all enterprise data is accurate, secure and rapidly accessible.

Component roles and responsibilities

EIM is a more functionally decentralized design model than traditional n-tier distributed architectures. Responsibilities of the various business application components (agents) are based on their functional roles as information producers, information consumers, service requestors, and service providers. At its core, EIM is a set of rules and guidelines that delineates and limits the roles and responsibilities of the various distributed systems components.

EIM is not software

Although an enterprise will employ various software components to implement the MQS model, EIM is an architecture and not software. As an architectural model, EIM views all data as relational and all processing as asynchronous. Information is distributed throughout the enterprise as ordered and atomic units of work. It recognizes that the state of enterprise data is constantly changing, as is the relationship of the various data elements.

Essential model benefits

Based on the inherent many-to-many characteristic of the distributed systems environment, EIM seeks to exploit the benefits of the relational data model. Similarly, based on the performance and reliability constraints of synchronous inter-process communications in a highly-distributed environment, EIM employs an asynchronous inter-process communications architecture.

Strategic benefits

• Eliminates the need to re-engineer your portfolio of business applications, or migrate to new runtime languages or platforms
• Can be implemented rapidly and in phases
• Can be implemented non-disruptively and tailored to coincide with the functional release strategy of a systems organization
• Connects highly geographically distributed environments
• Integrates environments that suffer regular communications and hardware failures
• Ensures the highest level of performance and reliability
• Supports both procedural and object oriented design models
• Exploits industry accepted, industrial strength, off-the-shelf components
• Delegates function to appropriate tools and components rather than relying on a single middleware product
• Allows customers to utilize the skills of their current development staff
• Cost effective and normally involves a rapid return on a customer's investment
• Provides platform and tools choices that are not tied to any one hardware, operating system or database tools vendor