Software Delivery Management
OSIM is EAL’s own, assured Open Source Integration Methodology which has evolved as a result of many years experience of implementing enterprise-class open source solutions. It is aimed at realising robust applications which are compatible with a user organisation’s structure and strategies and can be implemented in an efficient, standards-based manner.
OSIM applies four perspectives to each implementation project:
Selection
Evaluate and choose the correct open source application(s).
Extension
Adapt and enhance the application to meet the organisation’s goals.
Integration
Seamlessly introduce the new system within the existing business and technical environment.
Deployment
Ensure the solution is successfully deployed to the user community and that appropriate support policies are in place.
Why Would You Need This Service?
Standards
OSIM is based on current Standards and Best Practice including:
- Scaled Agile Framework (SAFe);
- The Open Group Architecture Framework (TOGAF);
- IBM Rational Unified Process (RUP);
- Open Unified Process (OpenUP);
- Unified Modelling Language (UML);
- Evolutionary Process for Integrating COTS-based Systems (EPIC);
- IT Infrastructure Library (ITIL);
- Software Process Engineering Metamodel (SPEM)
Implementation
OSIM, at its core, is based on the Scaled Agile Framework (SAFe) and IBM Rational Unified process (RUP), which has been adapted specifically for open source implementations, and the process is further customised for each engagement. RUP is the most robust methodology in existence for software implementation projects and EAL has considerable expertise in its use.
The approach is risk-driven, iterative and architecture centric, ensuring that all significant risk is driven out as early as possible during the project so that unpleasant surprises do not emerge when it is too late to correct them within project timescales.
Adapting the Process
EAL engagements come in many flavours. In some cases, we simply construct the required solution and then integrate it within the existing environment; in others, the solution is part of a wider project or programme in which we participate, not only in the development effort but also in the practices and processes that surround it.
To ensure that we can operate as an effective, collaborating partner, we apply various techniques to align ourselves with client practices whilst preserving the resilience of our own methods. The process is therefore adapted, within specific guidelines, to integrate with each environment; these guidelines include, for example, integration with Prince2, PMBOK, Agile and XP methods. Additional guidelines cover Enterprise Architecture (TOGAF), Programme and Portfolio Management, Support policies (ITIL) and various open source solutions.
How We Deliver This Service
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.
Deliverables
Delivery Method – Project Structure
The lifecycle of an OSIM project is divided over time into four sequential phases, each concluded by a major milestone. At each phase-end, an assessment is performed to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move into the next phase.
Each phase comprises one or more iterations; an iteration is timeboxed (always finished on the scheduled date) and has a clearly defined and documented set of objectives which are designed to contribute to the end-phase objectives.
An iteration is a complete development lifecycle and results in fully-tested software of production quality. Using a process of continuous integration, the system evolves so that each iteration produces progressively expanded content, allowing the opportunity to receive user feedback early and avoid lengthy deviations from what is acceptable. The system evolves, so each iteration produces progressively expanded content.
Early iterations focus on eliminating risk so that by the end of the second phase (Elaboration), the remaining effort is highly predictable. Software projects that are late are usually characterised by attempts to achieve perceived value (functionality) early whilst leaving the ‘difficult’ elements until later in the project – by addressing risk early, any unforeseen problems can be addressed within the planned project schedule.
Work Content
A typical project requires fewer resources for the early, risk-focused iterations; the following diagram illustrates an example of how work is distributed across the phases:
The diagram illustrates the four phases (horizontal axis) and disciplines or workflows (vertical axis) which describe the types of activity applied. The graph indicates (approximately) the varying emphasis per discipline depending on the project phase. For example, more time would be spent on requirements in early phases and more on implementation in later phases.
Typical Outcomes
1. Accessible in both usable and approachable manner
The framework is accessible to all as it is on their website and you can see the homepage with the diagram. This image gives a larger picture of the framework and all the configurations can be viewed at one click.
2. Agile practices are codified quickly
The practices of agile can be codified easily using OSIM and the usage of the underlying SAFe framework and hence even a beginner can master the concept quickly. For instance, the definition for an agile team, a (Product Owner) PO a (Scrum Master) SM can be understood just in a click.
3. Agile practices are given an extension
OSIM and SAFe has safely extended the agile model to the portfolio and program level. Again OSIM and SAFe did not use any new techniques but codified existing elements including user stories, features, and an epic hierarchy. This means OSIM and SAFe can be adopted even by a naïve team and there is no additional training required.
At the same time, novel concepts like Agile Release Train (ART) were introduced and used at the program level. In short, the ease of use and introduction to modern concepts makes SAFe a very popular and adaptable framework.
4. Agile practices are grounded in enterprise context
As already mentioned when many frameworks focus only on the development area, OSIM and SAFe as a holistic approach but at the enterprise level. Understand this with an example. SAFe recognises that estimates must be done at the program or the portfolio level. Also, it agrees that estimates depend on the features and epics. Only later on it descends to the story and points. While practitioners might consider this as disrespect when they look at the team level. However, SAFe grounds agile practice at the enterprise level and embrace the concepts correctly.
5. Very specific
OSIM and SAFe thus codifies, extends and grounds the agile practices for complex systems at ease. Concurrently, it offers terms, practices, and concepts in particular and not generalise to allow developers to use them precisely. The primary focus of OSIM and SAFe is to tie the knot between agile and lean practice and develop software.
People who are keen on developing software than debating methodology will love the way OSIM plays.
6. Lightweight framework
One does not need to spend ages in mastering the concept of this framework. It is lightweight in the sense, the graphics presented on the home page will direct the user to a web page. It contains the definition, concept, reference links, and all details. Therefore learning becomes mastering within no time. Organisation need not worry about resource availability with OSIM and SAFe working knowledge but can handpick talented resources and recommend them to do SAFe certification training. It is easy to learn and implement.
Case Studies
Authenticate to download the PDF.
Contact Us to Get Started
We will come back to you to discuss your situation as soon as possible
