Users of an enterprise business software system expect the system to provide for them a rich set of functionality. For example, a finance system might be expected to prepare paychecks, prepare tax returns, create end of the year reports, etc. A personnel system might be expected to prepare reports of personnel sorted or categorized in various ways, to process the hiring of employees, etc. The built-in functionality is maintained by the software provider and is expected to remain correct over time, for example as the tax codes or hiring laws change. Additionally, the software provider may discover flaws in released software that need to be corrected, and develop more advanced features to be added to the software. These factors all necessitate that the software provider periodically create updated versions of the enterprise business software.
In addition to the functionality built into the enterprise business software, users expect the software to be extensible and modifiable. Many typical business processes differ significantly in their details from company to company, and the enterprise software needs to be modified by the user to meet his company's needs. Users may also desire unusual functionality that is not built into the enterprise software system. A typical user of business software invests a great deal of time and money in customizing the software to correctly perform all of the tasks necessary to his company.
A software provider seeking to upgrade an enterprise business software package faces a significant challenge when a customer has extensively customized his installation of the software. If the new version of the software completely overwrites the previous installation, all of the customizations will be lost, and the customer will need to repeat all modifications to the software. Overwriting modified parts of the software can be avoided by only upgrading parts that have been left by the customer in their default state. However, this process is difficult to automate, so it becomes extremely time-consuming and expensive, and risks the possibility that a part of the software that is essential to upgrade will be skipped.
Some enterprise software systems are installed and maintained on computing hardware owned by the client. Other enterprise software systems use a service model architecture, also known as software as a service (SaaS). In enterprise software systems using a service model architecture, the software provider maintains both the software and hardware systems, which are used remotely by the customer. The software provider may design their service model architecture in such a way that a separate enterprise system is used for each customer on separate computers, or they may design it such that all customers share a single enterprise system. Using a single enterprise system increases the scalability of the service model architecture to large numbers of customers by reducing the total number of hardware and software systems that require regular maintenance. However, the complexity of the system increases when it gains the ability to handle multiple customers. The system must ensure that customers cannot access each other's data, even though data belonging to many different customers is stored in the same memory and accessed with the same system. It must further distinguish system-wide data, which is available to all customers.
The service model architecture enterprise software system designates customers as tenants of the shared enterprise system. Some data object classes in an object-based enterprise software system are designated as tenanted, or belonging to a specific tenant. Data instances of the tenanted object classes belong to the tenant that created them, and may only be accessed by the tenant they belong to. Some data object classes are marked as non-tenanted, or not belonging to any tenant. Data instances of non-tenanted objects are accessible by any tenant of the enterprise system, and are not modifiable by tenants.
USPTO Backgrounds
USPTO Backgrounds