solutions
OSIM - Package Selection and Integration
As open source applications are free of licence costs, there is often a temptation to be less than circumspect when choosing the correct solution - without the normal budgetary constraints, the rigour associated with developing and approving a business case is often missing. However, the impact of implementing a major application is the same, whatever its nominal cost.
To ensure that the application is not only fit for purpose but also compatible with the enterprise's business and technical architectures, OSIM employs an adapted version of the Evolutionary Process for Integrating COTS-based Systems (EPIC) from the Software Engineering Institute (COTS = Commercial off-the-shelf).
Building solutions based on pre-existing packages is different from typical custom development in that the packages are designed to meet the needs of a market segment rather than a given project's specification. An understanding of the package functionalities and how they are likely to change over time in relation to the requirements and user business processes must be attained and used to drive the resulting architecture.
Many projects have tried unsuccessfully to integrate third-party packages by defining the requirements, formulating an architecture to meet those requirements, and then trying to fit the packages into that architecture. Instead, when building solutions based on pre-existing packages, it is important to be able to define and make trade offs between certain characteristics.
These characteristics, shown to the right in the diagram, are defined by the EPIC process as the four spheres of influence; they represent competing interests that must be considered in creating a viable solution that effectively leverages the capabilities of the open source solution:
Stakeholder Needs | Requirements (including quality attributes such as performance, security and reliability), user business processes, business drivers and operational environment.
|
Architecture and Design | The essential elements of the system, the relationships between them, and how they fit with the enterprise system. The elements include structure, behaviour, usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs.
|
Marketplace | Available and emerging technologies and Open Source products, non-development items and relevant standards.
|
Programmatics and Risk | The management aspects of the project. These consider the cost, schedule and risk of building, fielding and supporting the solution. Key to these management aspects are the cost, schedule and risk of any change to business processes.
|
These four spheres are simultaneously defined and traded through the life of the project because a decision in one sphere will inform and likely constrain the decisions that can be made in another sphere. For example, a stakeholder need may be stated in a way that it cannot be satisfied by any known pre-existing package.