Application integration, APIs and modernization
The reason for the workaround is usually gone. The workaround is still running.
We connect the systems you already own, replace the spreadsheets and scripts holding them together, and modernize the applications worth keeping.
How we approach it
Most organizations don't need a new application. They need the five they have to agree with each other. Orders live in one system, inventory in another, finance in a third, and the glue between them is an export, a spreadsheet and somebody who knows which column to paste where. When that person is on vacation, the business finds out how much it depended on them.
We start by tracing the data, not the screens: where each record is created, who changes it, where it's copied, and which copy everyone trusts. That usually turns up a small number of integrations that would remove most of the manual work. Those get built first, through documented APIs where the systems offer them and through a well-behaved database or file interface where they don't.
Workarounds get the same treatment. Somebody hit a constraint once, built around it, and it worked. Then the constraint went away and the workaround stayed, because four other things depended on it by then. We find those, price what each one costs to keep, and remove the ones that don't earn their place. Temporary is a word, not a mechanism. A date and a named owner make something temporary.
Modernization follows the rule we use everywhere: price it before you build it. Some legacy applications should be rewritten. Many should get an API in front of them and be left alone. A few should be retired outright, with their data archived somewhere you can still search it. You get a recommendation for each, with the cost and the risk of each option, and custom development only where nothing off the shelf fits.
What you get
- A data-flow map of the systems involved: sources of truth, copies and manual steps
- An integration design covering APIs, data contracts, error handling and monitoring
- Built and documented integrations, with runbooks your team can operate
- A modernization recommendation for each application: keep, wrap, rewrite or retire
- A list of the workarounds still running, each with an owner and a date
- Dashboards or reports on the integrated data, where they're needed
What a first engagement looks like
- 1
Discovery
A fixed-scope trace of how data moves between your systems, and where people are doing the moving by hand.
- 2
Fixed price
You know the price before we start. We set it from the size and scope of the discovery, so it fits your organization rather than a one-size package. If we find something that would change the scope, we tell you first, and nothing extra happens without your OK.
- 3
Written read-out
A written document: what we found, what we'd do, what it costs, and what we'd leave alone.
- 4
You decide, in writing
Nothing moves to a build until you say yes in writing. Taking the read-out and doing the work yourselves is a fine outcome too.
Every engagement is led by a senior architect, and we bring in specialists from our bench when the work calls for them. After the first job, some clients keep us on as a fractional CIO or CTO for the decisions that keep coming.
Questions CIOs ask
Should we build custom software or buy a product?
Buy when a product fits most of the need and the gap is process, not data. Build when the workflow is what makes you different, or nothing on the market handles your data. Most answers end up as a product plus a thin integration layer.
Our ERP vendor says its connector handles everything. Do we still need integration work?
Maybe not. Test the connector against your three ugliest real cases before you trust it. If it handles those, use it. If it doesn't, you'll know exactly where the custom work is.
How do we modernize a legacy application nobody wants to touch?
Put an API in front of it first. New systems can then use its data without changing it, and you buy time to decide whether it gets rewritten or retired.
Who maintains the integrations after you leave?
Your team, with documentation and runbooks written for them. We build on platforms your staff already know, and we don't leave behind anything only we can fix.
Do you only work with companies in Jacksonville?
No. Do IT Right Consultants is based in the Jacksonville, Florida area and works with clients across the United States. Most of the work happens remotely, with site visits when the job needs them, and partners extend our reach when an engagement goes overseas.
An example
Real-time supply-chain visibility for a manufacturer
A manufacturing organization was making supply-chain decisions from disconnected systems, delayed reports and manual extracts. The work was API integration with the operational and supplier systems, a SQL reporting model with the business rules written down, and exception reporting that flagged at-risk orders and materials.
The result was real-time visibility into supply-chain and operational activity, faster warning of exceptions, and far less time spent preparing reports by hand.
Read the supply-chain analytics case studyWhere this applies
Find the workaround that's costing you most.
A 1-hour app development call on Microsoft Teams, times in ET.