Integration and connecting multiple systems together is so easy so why don’t we just jump in and do it?Integration and connecting multiple systems together is so easy so why don’t we just jump in and do it?
Often when I train new developers in integration they throw out their methodologies for development out the window and think they can just jump in and start connecting systems together. When working with different teams on projects it more important to fit in with the team’s than to be charging off implementing integrations on development systems to prove that you can do this really fast.There is no winner in a one horse race.
Which methodology doesn’t matter as long as there is a plan and throughout the planning phase the pitfalls are identified. I personally prefer an iterative methodology, without singling one out, that is in synch with the developers/implementers of the other systems.
The most important part is to be patient and allow flexibility as there can be times of waiting for teams to finish their parts and times where functionality will change due to restrictions in implementations. The first step and the last is the documenting of what you are planning on doing through to what you actually do. This is an iterative process that continuously requires you to be rigorous in continuously updating your plan/documentation.
All good integration projects start with a plan. For me that plan and documentation is always evolving. A project I am currently working on requires me to jump in and out of the project as the different project teams finish their parts. As I go I document all the development and all the testing I am completing as each iteration passes. So when confronted with an Urgent request for an update on my testing it was easily a matter of releasing my current version of my documentation.
This also allows me to provide estimates and updates as the project evolves. Clients will demand to know know how long and how much. Without the common response of “How long is a piece of string?” I do prefer to do a few days of discovery to start the building of the plan. This allows me to document the high level requirements, identify key systems, start the process of gaining access and to provide an estimate of the effort.
Hence the start of the evolving plan. As the project evolves so does the plan and the estimates can become more accurate. The plan that starts at the very beginning of the project eventually becomes the completed documentation of how the project was implemented including all the configurations, designs, assumptions and design changes.
Without a plan and without a methodology you are essentially going back in time to the 90s when developers were sometimes referred to as hacks (before hackers become common). Or even early as Benjamin Franklin stated “By failing to prepare, you are preparing to fail.”