In this article, we explore the seemingly counterintuitive concept that time dedicated up front to defining your software integration process has the potential to reduce your project’s overall elapsed time to delivery and, very importantly, ensure that development dollars spent with Softjourn or any software dev firm are deployed most efficiently, delivering the software-based solutions your business needs—on time, on budget and with minimum frustration.
Living in the Digital Age, we’ve all come to expect instant gratification. Even waiting a few minutes to microwave a cup of water for tea seems an inordinate inconvenience. We want what we want—and we want it now.
When it comes to business operations, software has both enabled and fueled the 21st century addiction to immediate results. We believe software can do anything, and we look to developers and engineers to create software magic. As a company 100% focused on software, we love creating “magic” for our clients and are committed to delivering software solutions as quickly as possible to give our clients every marketplace advantage.
But we also recognize that when it comes to software integrations—such as weaving together off-the-shelf software solutions or meshing systems acquired through mergers—speed sometimes can be a misleading goal. That’s because speed, while important, is only one component of a successful software integration. Dedicating time up front to thoroughly define a project before integration work begins is time well spent.
In this article, we offer our experience-based perspectives on the value of a period for definition at the start of every software integration effort—regardless of whether you’re working with Softjourn, another software development firm or even integrating using your in-house team.
The definition of software integration process
Software integration doesn’t only involve programs, systems and applications; it’s also about business requirements and desired outcomes, which are the starting point in the software integration definition process.
At Softjourn, the definition process is a collaborative effort during which we work together to establish what your successful integration looks like. Once the outcomes you need to achieve are identified, we explore your business requirements, focusing on unique or special elements intrinsic to your business operations. Our goal is to uncover assumptions—the obvious ones and those so ingrained you don’t even think about them—on which your business is built, with the goal of incorporating these into your integration definition.
Only then do we move on to the more technical aspect of the definition process—digging into the programs, systems or applications to be integrated. In this phase, we evaluate the code base for obvious attributes—such as the programming language, overall code quality and outdated libraries or dependencies—as well as its nuances—such as code antipatterns and functionality that require refactoring before integration can happen. We’re also on the lookout for any necessary fixes or upgrades to the code—all with the goal of identifying potential issues and mitigating risk. And, of course, we conduct this evaluation for each program, system or application being integrated to create a strategy to enable them to harmonize seamlessly.
Throughout this interactive definition process, we ask probing questions to clarify areas of ambiguity, helping you evaluate your needs and refine your expectations. Your responses pave the way for successful integration and, even more importantly, optimizing ongoing performance of your integrated system. Although there are no set questions because each integration is unique, these are examples of the types of information we collect as part of a typical definition process:
- Integration solution architecture
- Integration services and components
- Data flows
- Communication protocols
- Technology preferences
Establishing the game plan
As we proceed through the definition process, we’re acting not only as your integrator but also your technical consultant, sharing our experiences and recommendations with the goal of helping you make the best decisions for your business.
Our heavy focus on working consultatively is reflected in our initial game plan document. In most cases, this document provides options for your consideration, along with our analysis of those options and recommendations. Providing options, we believe, is an important part of the value we deliver, because there is rarely, if ever, a single “right” path for an integration. Invariably, there are tradeoffs, often involving timing, expense and specific deliverables. It’s our role to help you understand your options and tradeoffs, if any, so you can make informed decisions.
Based on your evaluation of the options, we prepare a clearly articulated final game plan, including a projection of the timeline and budget, which becomes the roadmap for your integration. And when we say the game plan is final, it’s final with an asterisk. We know the unexpected happens. In fact, it wouldn’t be normal if it didn’t. So, when changes are needed, we adjust the plan accordingly.
Whom does the definition process benefit: You or us?
The answer is clearly both. We benefit because dedicating time upfront minimizes surprises that can have negative effects on integration delivery, cost and functionality. Other important benefits include enabling us to source, acquire and schedule required resources, including personnel for efficient and timely allocation of human capital. Plus, there’s the very real benefit that well-defined integrations run more smoothly, reducing frustration and miscommunication.
These same benefits accrue to you because our interests are aligned around a successful, efficient integration. Just as we benefit, you benefit from the certainty of outcomes, including functionality, timing and cost. In addition, you benefit from an integration process that is as frictionless as possible. No one wins when an unanticipated twist uncovered late in an integration necessitates a timeline change or going back to management for additional funding.
Well run integrations keep productivity high on both sides, so everyone can focus on driving business goals forward.
Why not start implementing immediately?
This, in fact, is common in our business. Some software development firms tell prospective clients they can define the integration while actively programming, thereby “saving” time. Alternatively, to avoid a thorough definition phase, the firm will present a high-level vision of the integration that lacks necessary detail to be useful.
Both approaches may sound great at the start of an integration, but we believe you’re likely to pay for the fast start down the road as business requirements or idiosyncrasies in the code base, for example, gradually become apparent. Although these unidentified requirements or quirks could have been dealt with easily if they were identified early, learning of them once an architecture is established and/or programming has begun can contribute to delivery delays, cost increases and/or compromises on functionality.
Firms that take this highly questionable approach often position it as a competitive advantage, but we believe it’s a false saving. The short-term good feeling created by jumping into action is long forgotten when delays, costs and challenges to get the right people on the job and other obstacles are encountered. Defining your integration on the fly is the surest way to create frustration and require compromise as your business deadline comes near.
How is software integration like building a house?
The process of software integration is incredibly similar to building a house. You’d never build a house without a well-defined plan, including understanding what the buyer wants, examining the property on which it’s to be built, contracting with an architect to create blueprints and lining up the contractors you need—like plumbers, electricians, carpenters and painters—so the right skills are available at the right time. It’s the same with software. Just because we’re talking about code vs. wood, brick and concrete, a definition process supports achieving the desired outcome. You may think you can’t afford to take the time to complete a definition process, but we contend you can’t afford not to. You either put the time in up front or you pay on the back end. The former is always the best option, in our opinion, to achieve the best results for your integration. If you have questions—and especially if you have doubts or concerns—about dedicating time to the definition process pre integration, please contact us. We’re happy to put on our consultant’s hat and share how dedicating time at the beginning of your integration to the definition process can offer you a big-time payoff. And, as always, we’ll be fully transparent because there’s nothing more important than earning your trust.
An Interview with Solutions Architect Lyubomyr Nykyforuk:
Why Pushback Happens
Although integration definition is an IT best practice, there are still some who question its value. We asked Lyubomyr Nykyforuk, solutions architect at Softjourn, to share how he responds to questions about dedicating time to a definition process before integration.
Q: Why do you think some push back on the idea of definition before integration?
LN: Mostly, it’s an abundance of enthusiasm to get started. Many business people believe the sooner we start integrating, the sooner they’ll be able to launch the product or deliver the enhancement they’re planning.
Q: Is that accurate—the sooner you start coding, the sooner the client will see results?
LN: Like clients, we want to move to the implementation stage as fast as possible, and we’re also excited to get underway.
And, for simple projects, particularly when we’re familiar with the scope of the project or when the scope includes multiple decoupled components, we may be able to progress almost immediately to the coding phase. For these integrations, we can jump right in and conduct iterations of the definition and implementation phases as we go along.
But integrations can be surprisingly complex, even those that don’t seem so on the surface. The level of effort put into the definition process always pays off in the end, whether the integration is obviously complex or seemingly simple.
Q: Why?
LN: Because if you don’t take time to understand the whole picture before you start, you’re inevitably going to make material discoveries during the implementation process that will require you to double back and make changes. Issues that would have been relatively easy to address and plan for if they were uncovered during the definition process may become obstacles if they’re identified after integration activities have started, potentially jeopardizing the cost, timing and functionality of the integration.
Q: Do clients think they’re being scammed when you propose a definition period?
LN: I don’t think so. It’s more about enthusiasm battling logic. They’re under a lot of pressure to deliver because the business world is moving fast, and they don’t want to be left behind. And it’s always easy to underestimate the technical complexity of a project someone else is working on.
For me, the key is transparency. At Softjourn, we strive to be transparent with our clients. That means backing our recommendations to dedicate time to integration definition with solid reasons, including risks of moving ahead without this period for discovery.
If anyone feels scammed by the proposal of a definition period, those companies probably shouldn’t be working together. The client/integrator relationship is extremely sensitive, and it’s built on trust. If potential clients don’t trust a recommendation for an IT best practice, they likely won’t trust the integrator’s analysis or recommendations, which isn’t a formula for a positive relationship.
Q: What are we talking about in terms of timing for the definition process?
LN: Of course, that depends. For extremely simple integrations, we often can complete the definition process in a day or several days. Simple, but more complex integrations may take a week or two. And, if we’ve completed similar integrations or are already familiar with your systems, we can sometimes draw analogies, which can speed the process, as I mentioned earlier.
Complex integrations, particularly those in which acquired systems haven’t been vetted by due diligence, can take a month or more. That sounds like a long time, but dedicating that time pays off in saving an equal amount of time—or likely even more—on the back end.
Q: Any final advice for someone who's on the fence about whether a definition period is needed?
LN: At Softjourn, we build a tremendous amount of consulting into the definition period. We look at everything from the vantage point of the client and what it needs to accomplish, so our options and solutions are client-specific and reflect our best thinking. There’s a lot of value embedded in that consultative process—enough, I think, to make the definition period prior to integration time well spent.
Also, as part of the definition process, we create documentation and graphics that can be useful to clients in other ways—for example, as part of their permanent documentation, for use in marketing materials or even in pitch decks to investors. Our work takes the client’s vision and makes it tangible, and there’s real value in that, especially for startups, fintechs and others that need to demonstrate their potential.
Definition Before Software Integration: Case Study
