When a new integration project kicks off at Devikone, developers follow a clear structure that guides the process. This allows experts to focus on what they do best – helping clients by simplifying their daily work through integrations. But what exactly are the phases in a typical integration project?
Before we dive into the project phases and details, let’s answer a basic question: what is a typical integration project like?
Even for experienced software developers, it might come as a surprise how “simple” integration projects actually are.
“Most integrations follow a waterfall-style model. That is, we know we need to move data between a source and a target system, based on predefined rules,” says Tuomas Palenius, CTO and one of Devikone’s founders. A common example would be building an API between two systems.
Integration development differs from traditional software development in that clients usually don’t have specific customization needs or many different user or experience layers.
“Integration work follows very structured models, which also allows us to give extremely accurate time estimates – integrations are more science than art,” Tuomas explains. This also gives developers a clearer picture of what to expect on their desks.
When a developer joins Devikone, they receive comprehensive onboarding, often in the context of a real client project.
“Here, you get hands-on right away,” Tuomas says.
Before the actual project begins, a review of the client’s other systems is conducted, along with mapping data flows between systems, assessing the current situation and expectations, and compiling a list of contacts.
After that, the actual planning phase begins with the client.
“This phase includes everyone essential – both the developer writing the integration and the person designing the architecture,” Tuomas notes, adding: “Our goal is to train Devikone experts to handle both roles.”
Every new Devikone employee has access to the Integration Academy, a resource covering the open-source integration tools we use, including aspects of design, coding, and testing. The academy also reviews different integration architectures. “It helps build context and an understanding of the principles and methods we use in integration work,” Tuomas explains.
For the first project – and any that follow – internal project templates and workflows make onboarding much easier. You never have to start from scratch. “Developers don’t have ‘artistic freedom’ – in the best sense – because we’ve chosen a clear perspective on how integrations are delivered at Devikone,” Tuomas says with a smile.
Why is that?
“It improves quality and makes it more rewarding to focus on solving the actual problem when you don’t have to invent practices from thin air. You can follow the technical plan and the established patterns,” Tuomas explains. “That ensures the integrations stand the test of time, and documentation is handled consistently across projects.”
“It Improves Quality and Makes It More Rewarding to Focus on Solving the Actual Problem”
In the early phase, in addition to establishing client contacts, technical connections are opened, data flow diagrams are created, communication with other vendors is arranged, system access is set up, and existing mapping documentation is reviewed.
Once the planning phase is complete, the real fun begins – building the integration. This involves setting up connections to source and target systems and implementing mappings. “We have standardized, well-proven code templates for integrations that help get started quickly,” Tuomas says.
The work involves maintaining communication with the client and resolving any issues that arise. These are discussed in internal team meetings with support from people like Tuomas.
“The most important thing for me is creating an environment where the developer can get into a flow state while working.”
“If your day ends with an unresolved problem, it can weigh on you,” Tuomas adds.
The cornerstones of our projects are daily meetings where experts review current information and create implementation tasks in Trello. Each integration has a planning document, which is updated and refined as needed based on what comes up during implementation. Execution and planning are synchronized daily during these meetings.
When an integration project nears completion, testing begins – usually in the client’s test environment. Once sufficient testing has been completed, the project moves to production. “Going live is a structured process, followed by additional testing and result evaluation,” Tuomas explains.
Throughout the project, careful documentation is maintained. The quality benchmark is that another developer should be able to pick up the integration from version control and continue the work. This means documentation is up to date, the code is properly commented, style guidelines have been followed, and tests exist and pass. Before going live, a quality review ensures all agreed deliverables are completed.
In terms of time, a typical integration project is wrapped up in about five working days. Often, the client may have other integration projects running in parallel. Overlapping work can occur, but the goal is for each Devikone expert to be responsible for one client at a time.
“It doesn’t serve a developer’s core work if they’re juggling too many different project management tasks,” Tuomas says.
Once an integration project is complete, it’s time to pause and evaluate how it went. With some clients, separate maintenance agreements may be made, covering the monitoring of completed integrations.
“What’s certain is that with every integration built, you gain new skills – even if you don’t realize it in the moment,” Tuomas reflects. So while integration building may seem straightforward, every client is different, and every integration is unique to their challenges. Growth is inevitable.
As our integration architect Kari Aarnioki said after six months at Devikone: “I’ve learned more in six months at Devikone than I did in many years before.