AgileApps Support Wiki Pre Release

Difference between revisions of "On-Premise Installation"

From AgileApps Support Wiki
imported>Aeric
(Created page with "An ''on-premise'' installation of the platform is one that is installed and managed locally--typically behind the organization's firewall. ==Features== {{On-Premise Installation ...")
 
imported>Aeric
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
An ''on-premise'' installation of the platform is one that is installed and managed locally--typically behind the organization's firewall.
An ''on-premise'' installation of the platform is one that is installed and managed locally--typically behind the organization's firewall.
==Features==
<noinclude>__TOC__</noinclude>
{{On-Premise Installation Features}}
==Features and Benefits==
{{:On-Premise Installation Features}}

Latest revision as of 21:18, 26 November 2013

An on-premise installation of the platform is one that is installed and managed locally--typically behind the organization's firewall.

Features and Benefits

An on-premise installation of the platform is typically used by large organizations to manage costs and to take advantage of additional features.

Fundamental Benefits

The fundamental benefits of an on-premise installation include:

  • Fixed cost
    Although the initial cost is higher, it costs nothing extra to add additional users--and additional tenants, which can be a benefit for a very large and/or commercial organization.
  • Firewall protection
    Running the platform behind the corporate firewall provides an additional layer of security and data privacy.
  • Deterministic upgrades
    The version of the platform that is running in the cloud is upgraded once or twice a month. Those upgrades provide fixes and new features, but they may also introduce new issues, and may include interface changes. For an organization that requires maximum stability, an on-premise installation provides consistent behavior that is upgraded only when the organization deems it prudent.
  • Custom installation
    The platform runs across multiple servers. For high-volume applications, many additional servers can be added to eliminate bottlenecks. An on-premise installation allows the organization to monitor server loads and customize the installation, adding additional servers wherever they are needed to maximize performance.
  • Application control
    The applications that are available for installation by a tenant can be limited to those you select.

Additional Features

Additional features provided by an on-premise installation include:

  • Corporate Branding
    The platform can be configured to display your brand.
  • Multiple Tenants
    An organization can create multiple distinct tenants, selectively sharing data among them and automatically updating applications. A commercial venture could have multiple independent clients for a single application. Or a large organization could have different tenants for different departments, effectively isolating them from one another while sharing data in strictly determined ways.
  • Multiple Service Portals
    Each tenant can have only one copy of the ServiceDesk application, primarily because external customers use the same URL to access the Service Portal to create and track cases, peruse a knowledge base, or engage in community interactions. Since there is only one URL per tenant, there is only one portal for customers to access. With an on-premise installation, an organization can circumvent that limitation, by creating a different tenant for each application that needs a Service Portal. Data can then be shared between the applications using Tenant Data Sharing Policies.
  • Broadcast messages
    All users see the broadcast message when they log in, for as long as it is in force.
  • Custom Java Libraries
    The organization's libraries can be integrated directly into the platform--for example, to access enterprise applications.
  • Introspection and Reflection libraries
    The standard Java libraries that provide these advanced features expose public cloud users to unnecessary risk. But while leaving them out provides an extra layer of protection for cloud users, it also introduces some limitations for Java programmers. For example, to build a general-purpose data display tool, it is necessary to ask "What kind of object is this?", and then use the appropriate display mechanism for say, a HashMap or an ArrayList. But the libraries needed for that purpose are not available in the public cloud. (They're only needed for the most sophisticated of applications, but when they're really needed, they're indispensable.)
Learn more: