设计 IPS 是为了消除早期软件分发、安装和维护机制中长期存在并对 Oracle Solaris 客户、开发者、维护者以及 ISV 造成严重问题的一些问题。
IPS 基本设计目标包括：
通过使软件更新能够在计算机正在执行生产工作时进行，最大限度地缩短计划内停机时间。
通过支持快速重新引导至可运转的已知软件配置，最大限度地缩短计划外停机时间。
尽可能自动化新软件的安装和对现有软件的更新。
解决软件大小日益增长以及分发介质空间有限所带来的难题。
确保能够确定是否按照软件包设计者（发布者）定义的步骤正确安装了软件包。此类检查应当不具有可欺骗性。
引入相应机制（尤其是通过使用区域）以在各种级别轻松实现 Oracle Solaris 的虚拟化。
减少为现有系统生成修补程序或升级程序需要做的工作。
使其他软件发布者（ISV 和最终用户自己）可以轻松创建和发布适用于 Oracle Solaris 的软件包。
这些目标引出了以下理念：
利用 ZFS 快照和克隆功能，根据需要动态创建引导环境。
由于 Oracle Solaris 11 需要 ZFS 作为根文件系统，因此区域文件系统也需要在 ZFS 上。
用户可以根据需要创建任意数量的引导环境。
IPS 可以根据需要（在修改正在运行的系统之前出于备份目的或者为安装新版本的 OS）自动创建引导环境。
消除用于安装、修补和更新的重复机制与代码。
此理念将导致 Oracle Solaris 的维护方式发生一些重大改变，包括以下重要示例：
所有 OS 软件更新和修补都直接通过 IPS 来执行。
任何时候只要安装了新软件包，该软件包就已经是恰好合适的版本。
软件包安装的无欺骗性验证要求可带来以下结果：
如果软件包需要支持以多种方式进行安装，则开发者必须指定这些方式，以便验证过程可以考虑此项。
脚本编写过程本身是不可验证的，因为包管理系统无法确定脚本编写者的意图。此问题与稍后讨论的其他问题一起决定了在打包操作期间禁止脚本编写。
软件包不能包含用来编辑其清单的任何机制，因为如果有这样的机制，验证将无法进行。
如果管理员希望通过不符合原始发布者的定义的方式安装软件包，则包管理系统应当能够让管理员轻松地重新发布要更改的软件包，以便明确更改范围，使更改在升级后不会丢失，并且可以采用与原始软件包相同的方式进行验证。
为了不受空间大小的限制，引入了一个软件系统信息库模型，可通过几种不同的方法访问此模型。可以将不同的系统信息库源组合到一起以提供一整套软件包，并且这些系统信息库可以作为单个文件进行分发。这样，将不需要像以前那样要求在单个介质上包含所有可用软件。为支持断开连接的操作或有防火墙的操作，提供了用于复制和合并系统信息库的工具。
支持多个（可能存在竞争关系的）软件发布者这一需求将导致以下决策：将所有打包元数据存储在软件包本身中，不存在用于存储诸如所有软件包及其相关项之类信息的任何主数据库。出于性能考虑，系统信息库中包含了来自软件发布者的可用软件包的目录，但也可以通过软件包中包含的数据重新生成该目录。