P5EE - Definitions

• is worthy of and suitable for use in large enterprises and
• solves a set of problems which are particularly relevant to large enterprises.

• Enterprise System - Enterprise Software running on an Enterprise Platform (which, by implication, has the Attributes of an Enterprise System as defined below)
• Enterprise Solution - same as an Enterprise System. This term simply emphasizes that the system solves an Enterprise Problem.
• Enterprise Software - Software that solves an Enterprise Problem (rather than a departmental one) and that is written with an Enterprise Software Architecture
• Enterprise Software Architecture - A Software Architecture which allows software to exhibit all of the attributes of an Enterprise System when run on an Enterprise Platform
• Enterprise Platform - A set of computing and networking resources which enable installed Enterprise Software to exhibit the full attributes of an Enterprise System (most often referring to availability, scalability, and reliability)
• Enterprise Problem - A problem that is particularly important for large enterprises to solve, such as:
  • interoperating (bi-directionally) with a wide variety of legacy systems
  • integrating data from (and coordinating atomic, failsafe transactions across) disparate computing systems, locations, and data storage technologies
  • accessing any data anywhere in the enterprise from anywhere else in the enterprise (remote objects and method invocations, by reference or by value)
  • accessing any programming logic anywhere in the enterprise from anywhere else in the enterprise (remote procedure calls and messaging)
  • supporting a geographically dispersed (and perhaps culturally diverse) user base (internationalization, language translation, browser-sensitivity, bandwidth-conscious)
  • accommodating large transaction loads, high throughput, and massive data storage
  • accommodating changes in business logic (by allowing code to closely model business objects and processes, and by facilitating data-driven programming so that reconfiguration rather than further development can accommodate the changes)
  • automating of business processes across departments in the enterprise
  • maintaining of security where data is of high value and the vulnerabilities are many
  • ... in fact, the inverse of each of the Attributes of Enterprise Systems below are Enterprise Problems
• Software Architecture - The internal design of software, enabling the software to exhibit a certain set of attributes (i.e. the "architectural requirements"). The Software Architecture must take into account the capabilities and limitations of all of the target Platforms (Hardware/Operating-System/Networking) on which the Software will be run. An attribute of the system can only be realized if the Software Architecture and the Platform both support it.

     Enterprise System = Enterprise Platform +  Enterprise Software
     Enterprise System = Enterprise Platform + (Enterprise Problems solved + an Enterprise Software Architecture)
        (still useful) = Non-Enterprise Platform + Enterprise Software

• Availability - the assurance that a service/resource is always accessible
• Scalability - the ability to support the required quality of service as the load increases
• Reliability - the assurance of the integrity and consistency of the application and all of its transactions. The ability to provide a required reliability service level depends on the close coordination of the hardware, networking, operating system, storage subsystem, application framework, and application software.
• Security - the ability to allow access to application functions and data to some users and deny them to others
• Interoperability - the ability of the system to share data with external systems and interface to external systems.
• Leveragability - the ability that stored data, programmed logic, and other system resources available anywhere in the enterprise should be accessible from everywhere in the enterprise
• Maintainability - the ability to correct flaws in the existing functionality without impacting other components/systems
• Extensibility - the ability to add/modify functionality without impacting existing functionality
• Manageability - the ability to manage the system in order to ensure the continued health of a system with respect to scalability, reliability, availability, performance, and security.
• Portability - the ability of the software to run on a variety of hardware and operating system configurations
• Accessibility - the ability to access system functions through different user agents and in different human languages

• Longevity - the assurance that the tools and technologies the system is built with will continue to work and be supported far into the future
• Popularity/Buzz - the assurance that since other people are using the same technologies that (1) there will be a sufficient talent pool to maintain it, and (2) if there are problems, the manager who selected the technology won't be hurt politically within his organization

• Transaction System - Users enter data into a transaction-oriented system and the results are visible immediately to all other users of the system. These systems must have robust, local and distributed transaction control capabilities, so that multiple, coordinated changes in data may be accepted as a whole or not at all.
  Similarly, there must be some form of locking to arbitrate between multiple users attempting to modify the same piece of data at the same time. This arbitration may use pessimistic locking (select for update, interact with user, release by commit or timeout) or optimistic locking (select with last_update_dttm, interact with user, allow commit only if not modified in between).
  Transaction systems load small amounts of data at a time from potentially huge (and potentially distributed) transaction repositories, modify that data, and write it back. Disconnected (i.e. not "online") transaction entry must be supported by repository synchronization and conflict resolution.
  Transaction systems frequently need auditing capabilities and sometimes history-tracking so that undesirable changes may be traced and perhaps undone.
  Other Descriptions: Online Transaction Processing (OLTP), Data Maintenance.
• Reporting System - Users need to view Enterprise Data (i.e. any data in the enterprise, stored in whatever system in whatever form) textually (in tables) and graphically based on user-defined criteria. They need to by able to drill down to details, see comparisons, and distribute views of the data. Furthermore, server-side tools and capabilities must support the data repositories by performing data conversion/import, data extract/export, real-time and periodic (batch) updates, and bidirectional synchronization with sub-repositories (i.e. data-warehouse => data-mart) or peer-repositories.
  Other Descriptions: Online Analytical Processing (OLAP), Executive Information System (EIS), Decision Support System (DSS), Data Warehouse, Data Mart
• Batch System - Batch systems are generally run from a scheduler based on date/time/dow/dom and perhaps dependencies on other tasks or external events (arrival of files, etc.). They often process large amounts of data (perhaps even the entire database), so keeping all of the data in memory is rarely an acceptable design approach. Batch processes may be distributed in order to maximize throughput or to access distributed data and resources.
  Batch subsystems are often a part of Reporting Systems or Transaction Systems.
• Real-time or Near-Real-Time System - Real-time systems are usually used to control, monitor, or communicate with equipment that operates in real-time. I/O should never block the central event handler of a real-time system. Rather, the central event handler delegates waiting on I/O to other threads or processes while it goes back to handle the next event. Often, response time guarantees are required of real-time systems.
  True real-time systems must necessarily be run on a real-time operating system. Since most common operating systems are not real-time operating systems (Unix, Linux, etc.), and since high-speed is generally of the utmost importance, Perl in general and the P5EE in particular are not ideally suited for this type of system. However, Perl and the P5EE are suitable for building Near-real-time systems.
  A near-real-time system is where everything in the system is event-driven and is accomplished "as quickly as possible". Near-real-time systems sometimes even allow synchronous I/O within an event handler if it is known to be fast relative to the expected rate of arrival of events to be dispatched. This approximates a real-time system if there are suitable computing resources and the response-time requirements are not extreme. Various event-dispatching daemons (such as "inetd", "named", and "snmpd" written in C, and "lbnamed" written in Perl) are examples of near-real-time systems.
  Near-real-time subsystems are often a part of larger systems which include Reporting Systems or Transaction Systems.
  Other Descriptions: Event-Driven Systems

Gartner Group: Enterprise Applications

Software products designed to integrate computer systems that run all phases of a businesses' operations to increase internal coordination of work and cooperation across an enterprise. These products facilitate the integration of core business operations and processes, including sales, accounting, finance, human resources, inventory and manufacturing. An implementation might involve a single application, or portions of a single application, or an enterprise system could control all major business processes in real time, via a single software architecture on a client/server platform. In the future, enterprise software will also play an important role in external linkages with suppliers, business partners and customers. A subset of enterprise applications, enterprise resource planning (ERP), software was developed for manufacturers as the next generation of manufacturing business systems and manufacturing resource planning software.