Successful Connectors: Best Practices and Implementation Strategies

The best practice with connectors is always is to force a rule-based approach and tackle any exceptions as an aftermath or rule-based exhaustion as opposed to beginning with an exception-based approach.

The exception-based approach is luring and attractive because it values human choice and the preservation of the current process structure. But it charts a vector to a place that will offer no good alternatives to scale and sustain healthy processes in the long term. In that regard beginning by thinking about the exceptions as opposed to the rules is a mistake that we avoid at all costs.

Short-term gain for long-term pain in a nut-shell.Most organizations we work with share this in common: they seek current process preservation. When technology is sought, it's meant to embrace the current process as opposed to find a middle ground between process limitations and efficiency.

Our connectors are a way to bridge the flow of content from a repository onto BWX and then back. While we understand the occasional need to cherry-pick a file or another for a connector-based job, the best practice for connectors is to follow a rule-based approach as opposed to a manual approach.

‍The manual approach temptation explained

‍Manual approaches are tempting because they do not require any bit of process change. People can explore the exact file they want to get translated and kick off a translation project using the connector. The problem with the manual approach is that it's not scalable, not sustainable, and predictable (difficult to improve on).

That is why we explore the manual approach only after we have exhausted all possibilities of fitting connector behavior into rule-based behavior.It's necessary to deal with exceptions, but you can't design by exception.

A successful product and its respective implementation is based on rules that cover the largest possible percentage of use-cases. Use-cases that are left uncovered then need to be carefully assessed to explore the workarounds and solutions in order to instrument them within the proposed paradigms.

Here is an example: client A has a connector that works based on a schedule but occasionally they have projects that require an off-schedule run. Here a few different options on how to approach this:

1. Manually request an off-schedule run to our support team
2. Use our CLI to request an off-schedule run
3. Create an off-cycle branch/directory that gets polled more frequently than the typical schedule in order to pick up urgent jobs.

Here is another example: client B is used to cherry-picking files to start the localization process. Rather than perpetuate the manual approach, most cherrypicking processes do follow behavior that can be reversed engineered.

It's always worth the effort to push this reverse engineering to its limits. If you start with a manual approach or focus on covering the exceptions right from the gate via UI, that will then become a debilitating crutch rather than a program accelerator.When we think of a connector, we always think about automation.

That's the real process efficiency driven by a connector. Exporting and importing projects is a small gain when it comes to connectors. The real gain revolves around the business rules and the predictability and governance they generate.

The problem is that if you design and implement by exception, automation never really becomes an option. Automation by definition requires some degree of process change and if we don't push for this process-software fit we end up not exceeding expectations and become peddlers of the digitization of chaos.

This is not what we are about and we will not embrace this.Small-scale connectors must follow the same design and principles of large-scale connectors so that they can scale and grow efficiently. Most localization programs request solutions based on current (which is actually the past) use cases as opposed to forward-facing use cases that project more files, more cadence, more locales, less time-to-market, less cost, and more people working together.

If you don't set off in the correct framework course correction, later on, is costly and very challenging because you will miss the change window introduced by a new implementation.All of our connectors, big or small are based on rules and parameters.

They are governed by the same design principles and none of them require a UI to operate properly. The UI can be an interesting add-on to a mature connector, but mostly to easily change the connector configurations as opposed to a way to start projects off manually.

We cannot promote long-term success if we are complicit with the acceleration of existing analog processes.  

Rather, our goal is to translate the analog processes into digital thinking so that they become truly software compatible allowing data-oriented automation.We are used to managing connectors that process thousands of files per day into nearly one hundred different locales.

We have learned over the years that the same ingredients that make a large-scale connector successful must be respected for small-scale connectors as well in order to adhere to basic design principles of scalability and sustainability.