The Breakdown Between Workgroups
As a business evolves, its workflows, internal processes, and teams follow suit. Companies quickly outgrow their trusted tools, and teams find themselves distanced from one another by their specific responsibilities and goals. As a result, they eventually operate in silos and face different challenges, creating a major breakdown in efficiency and productivity for the company overall. To remedy the situation, they need to find a bridge to one another.
At this point, companies face what we call the workgroup conundrum. They must adopt a technology solution to address their business challenges while simultaneously connecting their teams.
As a Business Solutions Architect, I see a very common problem related to software development for workgroups. My team and I call it the Workgroup Conundrum. It defines the struggle for all teams in an organization to get what they need from existing internal systems.
For example, a team may accomplish 75% of their work with a program. However, they struggle with the other 25% manually, spending the bulk of their time on just a few tasks. Once this technology need gets to a critical point, they often notify IT and request a solution.
IT then must start considering a new application to help this department accomplish their goals and increase efficiency. The first question they ask is, “Do we purchase something off the shelf or build something ourselves?” The former is often less expensive but may not fit the exact needs of the workgroup, exacerbating the issue. The latter can be costly and time-consuming, draining resources from all teams involved.
We find ourselves helping organizations navigate this challenge so often through our consulting work that we wrote a white paper to share our top insights. You can download that resource here. We recommend it to anyone on the journey of getting software that meets their needs.
The Alternative: A Hybrid Approach
However, with the advent of powerful, heavily customizable platforms like Salesforce, we talk to many companies with a slightly different problem. They already have the systems they need in place. Unfortunately, these systems don’t talk to one another, creating silos in the organizations and cutting down on collaboration between teams. In the long run, this disconnect breeds inefficiency and halts the flow of data through the organization.
These companies have entirely valid reasons that they can’t just put everything into one package. They have to move forward with multiple systems in place, sometimes used by different workgroups, sometimes by the same workgroup. These combinations look all different ways and often involve hybrid ecosystems of enterprise software, off-the-shelf packages, and custom software.
So how do they remediate this issue and cohesively connect their systems? This brings us to the topic of custom integrations.
Integrating Critical Systems
Many enterprise suites and off-the-shelf software packages offer some tools for integration with other systems and data sources. Some well-built custom software will also have its own APIs.
In all cases, these pre-created tools and APIs themselves were still designed with a relatively general purpose in mind and are often “tool-centric” in their vision. They are designed with the tool from which they originate in mind as the crux of your use case.
Often the tools and APIs available require data structured in a specific format or conform to a simplified understanding of the rules, data, and technical wherewithal of the users who will rely upon them. These options work for some of our customers, and we help many customers implement them. However, as often as not, our clients suffer from their limitations.
And we are in this new era in which Software-as-a-Service, Platform-as-a-Service, etc., have become so dominant, our clients often turn to custom integrations as an approach to bridging these internal systems.
What is a Custom Integration?
An integration connects two systems, allowing them to pass critical information between one another to enhance the capabilities and functionalities of each. They typically are bridged with an Application Programming Interface (API) and streamline the complex exchange of data to both improve the user experience and drive a more agile system.
An integration connects two systems, allowing them to pass critical information between one another to enhance the capabilities and functionalities of each. They typically are bridged with an Application Programming Interface (API) and streamline the complex exchange of data to both improve the user experience and drive a more agile system.
Off-the-shelf Integrations
Many existing SaaS products and cloud-based systems have built-in public APIs and partnerships with other systems, empowering users to gain additional functionality easily. As a simple example, consider how Instagram users can connect other social networks, such as Facebook and Twitter, to their accounts. This functionality allows them to share their content across the networks. It eliminates the process of having to copy the text and URL from an Instagram post and switch to new applications to share it. Users can do all of this in one place. Other examples include connecting Salesforce to MailChimp or Google Maps to WordPress.
Custom Integrations
Custom integrations, however, are a bit more complicated. Developers build these to deliver on a unique need for organizations. They are often private and only accessible by a specific set of users through careful permissions and protocols. Custom APIs enable an organization to connect its internal systems, enhancing the productivity of its team members through the collaboration of information between applications.
For example, an organization can integrate its invoice system with its customer management system to automatically track customer billing and send out invoices once a month. This removes the manual burden of checking every account and building invoices for each, saving teams potentially dozens of hours every single month. Or, an association could connect its membership database with its public website. This would allow members to log in and manage their account profiles themselves, empowering the membership coordinator to focus on other priorities.
Depending on the need, developers can build these using Representational State Transfer (REST), Simple Object Access Protocol (SOAP), or Remote Procedure Call (RPC).
Data Structure Considerations
However, you can’t just write some code and go. Development teams need to put thought into how they structure the flow of data from one system to another. You must focus on consistency and build clear definitions for data the systems are sending and receiving.
Focus on an intuitive data structure that works for all potential use cases. You don’t want to have to update your entire API to support minor changes or small user needs. Planning your integrations is key to successful custom integrations! Take some time to map out all potential needs from the API before you get started.
There are several mechanisms you can use for this step. However, the most common option for web-based integrations these days is JavaScript Object Notation (JSON). It’s simple but can represent complex data, making it much easier to manipulate than XML.
Working Together with IT
When workgroups face issues with existing systems they can’t navigate around, they often resort to “Shadow IT.” They adopt off-the-shelf applications or sometimes even build their own systems to accomplish their goals and automate their processes. These systems often fall under the radar of IT and aren’t in compliance with the organization’s IT standards. My team and I often come across this issue during our consulting process.
The better way for workgroups to get the capabilities they need is to work with IT to outline and build custom integrations between their systems. Then they add the functionality they need. This does, however, require collaboration with (and approval from) the often overloaded IT team.
Next Steps
Of course, sometimes IT can see the reasoning and needs behind a pitched custom integration but still cannot schedule time to build it. Why? They’re just too busy.
In this case, finding an external partner to build the integration can serve as the best solution. They’ll have the bandwidth to complete the project on time and within scope while simultaneously offering an outside view. This ensures your organization doesn’t miss any crucial details related to use cases or data needs.
My team and I offer such custom integration development services and often support existing development and IT teams. If you’re looking for a partner, we are happy to discuss your envisioned integration and see if we’re a good fit. Contact us today.
