The purpose of this document is to provide guidelines for projects in which the ONEiO solution has been integrated. The intended audience is ONEiO partners project personnel.
Key components in a successful integration project
Firstly, you will need to be aware of what the process of integration is, in addition to why it is being done. The integration project will often start with the statement; ‘we need to integrate incident process’, however this is something that is usually agreed upon at a commercial level and lacks the crucial information as to how the integration needs to work.
In this document we outline the ways in which to move forward from this point in order to ensure a successful integration outcome as well as optimise results. The key factors being:
- Both parties should have a clear understanding what is expected of them in the process.
- Simplicity should always be the goal.
- Create the first version of the integration as early as possible.
- Validate the plan with real-life examples that simulate the daily process to test cases.
Project team / project roles
Managing to successfully run a full integration project requires clear identification of all the integral roles and expertise involved in the project. This is usually a combination of technical and process knowledge needed to cover the whole spectrum of topics in the process of making decisions and finding the right solution. Here we have put together a list of knowledge and expertise necessary - in a typical case any one person can take on multiple roles in a project:
Project manager
Tool developer(s)
- To create triggering mechanisms and modifications to end systems involved
Infra specialist(s) (if needed)
- To set up connections to endpoints
ONEiO admin
- To create integration logic and rules
Process owners from both parties
- To draw-out the process flow that the integration should fulfil.
Process users
- To validate that the drawn-out process flow accurately reflects the daily work.
Testers
- To ensure that the implementation works as intended.
Where to start?
It is beneficial to separate the integration project into two tracks - a technical track and a process track. These will normally run side-by-side and should be coordinated by the Project Manager in order to progress without delay.
Technical & Process track
Technical track
Participants: Project manager, tool developer(s), infra specialist(s), ONEiO admin
Technical track includes all definitions and implementations that enable the integration to relay messages between integrated parties. Topics to cover in this track commonly include:
- Defining of credentials
- Firewall openings (if needed)
- Message type defining
- Message content defining
This track will normally start with the setting-up of environments and connections. After the connections have been tested, smoke-tests can then be performed to confirm that the integration is working technically. As ONEiO provides the technology to connect the end-points, there is no need for traditional development work in this track.
Depending on the systems that are to be connected, it may also be necessary to define message types and content structure. In the case of connecting to commercial software, these variables will often be predefined.
Process track
Participants: Project manager, process owners, process users, ONEiO admin
Within the process track, all parties agree the process that the integration should produce.
Process flows
- Basic use cases
- Exception cases (if exists)
Attribute mappings
- Data relays
- Data mappings
- Conditional translations
Process flows
Attribute mappings
Testing
Participants: Project manager, process owners, tool developer(s), testers, ONEiO admin
Smoke-tests
The first test in the project is a smoke test between the parties. In this test, connection and credential are confirmed to be working.
Test planning
The process of test planning is probably the most important part of the project. It consolidates all of the integral parts of the implementations and then describes the planned solutions and its functionalities. The test case document also provides all parties with the possibility to confirm that all mandatory aspects of the integration are taken into account while defining the flows and mappings. Test planning should start in conjunction with the process track.
The test document is also a very useful to revert back to in the future when changes need to be made to the integration.
Planning typically includes
- scenario defining
- scenario documenting
- resource reservations
- scheduling of tests
Technical testing
Technical testing will normally be carried out by by the tool developers and integration administrators. During this test, the team runs through the same test cases that were used in UAT. In this phase the team can iterate the implementation so that it is then ready for UAT.
User Acceptance Testing (UAT)
The User Acceptance Test is the test where the implementation is confirmed to be working as planned. The test is performed by someone that will be using the integration in production. If some parties have a separate staging environment, the solution is transferred to it at this stage. The test is set to follow the specified plan in detail and testers will document their actions and results to the test document. A decision is then made based on these results as if to whether the implementation is accepted as production-ready.
Production validation
See ‘Validation Test’ in the next section.
Production roll-out
Participants: All
Production roll.out should be planned in detail. Plan should include the following steps
Implementation tasks
All necessary tasks must be carefully planned. Some parts can typically be imported to production ‘as they are’, but some may need manual work.
Scheduling
Generally, there will be varying maintenance windows to be taken into account when planning a production start. At this point, it is also important that all required resources are available for when the production start is planned.
Validation test
Once production implementation has been activated, it is crucial to agree upon test cases that will confirm that all functions work in production as they did in the test environment.
Roll-back plan
In any case a roll-back plan is needed. In this plan, the team describes the steps that will be taken if something unexpected happens during the roll-out and the team is not able to fix the problem "on the fly". The plan should also define who is responsible for deciding if and when the roll-back plan is executed.
Comments
Please sign in to leave a comment.