P5EE - Definitions
[ Project Status
| CVS Activity
| Mailing List
| Discussion Archive
| J2EE Security
Simply put, something in the realm of computing becomes an "Enterprise"
thing when it
This is not to say that the "Enterprise" thing may not be used to solve
the lesser problems of small enterprises, departments, workgroups, or individuals.
But it also guarantees that if the solution adopted by one of those smaller
groups suddenly is required to be adopted by the larger enterprise, it is worthy
and ready to do so.
- is worthy of and suitable for use in large enterprises and
- solves a set of problems which are particularly relevant to large enterprises.
For the purposes of this P5EE discussion, the following definitions
will be used.
This can be summarized with the following equations.
- 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,
- 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
Attributes of Enterprise Systems
Enterprise Systems are systems which have the attributes enumerated below.
When systems have these attributes, they are such that large enterprises can
invest substantial corporate resources in them.
Other attributes suggested have been:
- Availability - the assurance that a service/resource is always accessible
- Scalability - the ability to support the required quality of service as the
- 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
Types of Enterprise Systems
There are many Types of Systems in a large Enterprise.
Enumerating the types is necessary to ensure that the P5EE will be able
to support them all (or at least to describe the degree to which it
can support them).
- 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
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.
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.
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
The Gartner Group defines
Enterprise Applications as
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.