Database Reference
In-Depth Information
2.
Technology independence
: The development of enterprise applications as interface-dependent
but implementation-independent cooperating constellation of N-tier components enables
applications to be continuously upgraded in terms of the technology that is most suitable for
the specialized requirements of different units of the applications. This enables the applica-
tion to employ the most suitable technologies currently available while also accommodating
new technologies as and when they become available in the future.
3.
Phased implementations
: This is a very significant architectural characteristics for large enter-
prise applications like mySAP ERP. Enterprise applications like mySAP ERP not only have
to continuously enhance and upgrade its functionality and performance to meet the relent-
less expectations of new customers, but they also have to achieve this without disrupt-
ing the ongoing operations of the ever-increasing installed base of its existing customers.
In context of a specific enterprise, this characteristic implies the ability to implement or
upgrade various functionalities or modules of the enterprise solution as and when required
across an extended period of
time regardless of the versions, upgrades, and even changed land-
scapes of this solution or, for that matter, even other applications
. We discuss below the basic
service-oriented strategy for the enterprise component architecture (see Section 10.1.3.4
“Enterprise Component Architecture as a Strategy: Service-Oriented View”).
The more successful is the enterprise application solution, the more stringent are the
constraints arising out of this characteristic requirement of enterprise applications!
This is also the prime driver behind the gathering momentum of Services-Oriented
Architectures (SOAs) like SAP's Enterprise Services Architecture (ESA) and Oracle's
Fusion Architecture.
4.
Accommodation of changes
: The enterprise component architecture enables accommodation
of changes in a unit of the applications without affecting the actual functioning and per-
formance of the other units. This characteristic and the advantages accruing from it are
directly related to the partitioning or layering of the enterprise applications. For example,
enterprise architecture conceives of a database abstraction layer to access a database rather
than writing directly to a specific database. This layer presents a constant interface to user
components of the database while taking care of the specificities of communicating with
a particular database(s). As and when required, merely by changing the database abstrac-
tion layer enables changing the existing database without disrupting any other parts of the
system.
10.1.3.3 Enterprise Component Model
The component model maps the business processes and entities identified by the business model
onto a platform-independent IT model. The component model takes into account various aspects
like the distributed nature of the application, interface design, relationships and dependencies
within the components, and locality of data. A component model can be described as an archi-
tecture and a set of Application Programming Interfaces (APIs) that enables developers to define
and create software components that also have an ability of be connected dynamically together and
interoperate with other components. Most components operate within a possible nested hierarchy
of containers.
