Modification of a software after delivery to correct faults, to improve performance or other attributes, or to adapt the application to a changed environment.
A single source of common business data that are agreed upon and shared across the organization, and are used across multiple systems, applications, and processes. Examples include data about customers, products, employees, suppliers, materials, vendors, and so on.
A methodology that determines potential eligibility or computes benefit levels based upon some assessment of the incomes and assets of a family or household.
Data that describes other data.
Or simply microservices, is a variant of service-oriented architecture that has grown in popularity in recent years. Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined application programming interfaces (APIs). These services are owned by small, self-contained teams. Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating timeto-market for new features. It is a method of developing software applications as a suite of loosely coupled, independently deployable, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal. The opposite of this is the monolithic architectural style. For example, Amazon has migrated to microservice architecture. Amazon gets countless calls from a variety of applications—including applications that manage the web service API as well as the website itself—which would have been simply impossible for their old, two-tiered architecture to handle. In a microservice application, each service usually manages its unique database. See Werner Vogels video for more detail (https://vimeo.com/29719577).
The term “app” has evolved to specifically connote software that is designed to reside on a mobile platform such as a tablet or mobile phone. It encompasses a user interface that interoperates with web-based resources that provide access to a wide array of information that is relevant to the app and local processing capabilities that collect, analyze, and format information in a manner best suited to the mobile platform. Additionally, a mobile app provides persistent storage capabilities within the platform. Mobile apps are generally downloaded from application distribution platforms that are operated by the owner of the mobile operating system, such as the Apple App Store (iOS) or Google Play Store.
Unlike microservices, a monolith application is always built as a single, autonomous unit. In a client-server model, the server-side application is a monolith that handles the HTTP requests, executes logic, and retrieves/updates the data in the underlying database. The problem with a monolithic architecture, though, is that all change cycles usually end up being tied to one another. A modification made to a small section of an application might require building and deploying an entirely new version. If you need to scale specific functions of an application, you may have to scale the entire application instead of just the desired components. Monolithic systems use a single logical database across different applications.
In multi-tenant software architecture —also called software multi-tenancy— a single instance of a software application (and its underlying database and hardware) serves multiple tenants (or user accounts) at a Software-as-a-Service (SaaS) delivery. A tenant usually is a group of users—such as a customer organization—that shares common access to and privileges within the application instance. Each tenant’s data is isolated from, and invisible to, the other tenants sharing the application instance, ensuring data security and privacy for all tenants. In the most common usage scenarios, the CMIS will mainly be used by municipality (the user's organizational unit) staff. Depending on the implementing country, municipalities may need to be isolated from the other municipalities. There are also cases (like the Italian case), where data isolation is needed for a group (a cluster) of municipalities (in Italy these groups are called "Ambiti"). There are cases of specific cities (like Rome) that are single Municipalities but have smaller administrative divisions (called “Municipi”). So, an Ambito of Rome consists of “Municipi” and not Municipalities. Nevertheless, there are other cases where there is no need for data isolation between the municipalities and the data is shared among all organization units (like the Greek example). Therefore, the Case Compass prototype is developed as a multi-tenant web application. In cases where there is no need for data isolation among the organizational units, a single tenant can be used by all users. In the Case Compass, the term "administrative unit" is used for the administrative divisions (Municipalities or smaller divisions like the Italian "Municipi"). So a tenant's data can refer to one or more (a group of) administrative units (it is up to the client to define what an administrative unit refers to).