Why a Data-Centric Approach Falls Flat for Businesses Processes
Mike Fitzmaurice, chief evangelist and VP of North America at WEBCON, talks about why a data-centric approach falls flat for business processes. Find out his insights.
Classically-trained developers approach applications from a data-centric point of view. In a change request scenario, for instance, this means they start by creating a data model, then they create CRUD (create, read, update, and delete) forms, and then they figure out what kinds of automated activity should take place once a change is made to the data. While this approach can work well for many business problems, it’s completely backwards for business process problems. Mike Fitzmaurice, chief evangelist and VP of North America at WEBCON, talks about why a data-centric approach falls flat for business processes.
For many organizations, business process automation is a key component (along with collaboration, communication, business intelligence, etc.) of digital transformation. Processes that span boundaries are a popular target for automation and reengineering.
Cross-boundary processes require integration efforts, and it’s best to devise an overall strategy for tackling integration. Not that long ago, the natural next step would involve an enterprise service bus to abstract away a cacophony of different APIs, formats, and connection methods. Over the past few years, though, the industry finally seems to have coalesced around HTTPS, OAuth, REST, XML, JSON, and OData.
Role of APIs in Connector Components
Like any positive development, though, it can have unintended consequences. If every application, platform, and service’s API is laid bare, integrators tend to view those services as a box of LEGO bricks that they’re free to snap together any way they see fit. Some automation platforms go so far as to wrap those APIs in connector components and tout the number of connectors they offer as a competitive advantage.
Many people using integration tools like IFTTT, Zapier, or Power Automate start out (and often remain) integrating assets they own themselves (mail, calendar, contacts, social channels, devices). But that isn’t going to translate well when they apply this approach to corporate assets.
Because each one of those corporate assets has people responsible for curating it. Most of those curators will not take kindly to their charges being randomly accessed by another person’s ad-hoc application. Those hundreds of pre-written connectors are useless when one isn’t authorized to make those connections in the first place.\
See More: API Complexity: How Can Enterprises Tackle It
How Business Processes Configure and Manage Environments
Consider a scenario where a marketing department wants to collect information from individuals visiting a tradeshow booth and log this information into the company’s associated Salesforce environment. One approach might be for a citizen developer to build something and have it use a pre-built script/zap/connector for Salesforce.
The sales operations team might not take kindly to that idea. For one thing, letting the event coordinator write an application that talks directly to the Salesforce API (which is, fundamentally, what they would be doing by using the connector) is akin to letting them rummage through all of their file cabinets. The event team likely has no idea how Salesforce works, and definitely has no idea how sales operations has configured and manages that environment.
Even worse, this connector is now a direct data integration and custom dependency for the sales operations team. And it may be one of many. Make the wrong change to the Salesforce environment, and all of these dependencies break. And we’re not necessarily talking about technical changes; policy and procedural changes, such as adding or changing entities, fields, attributes, labels, validation rules, etc. are all enough to break things.
How Process Automation Works in Salesforce
The curator of Salesforce will need to know what that developer in marketing has in mind. There will need to be negotiations and information sharing. Only then might they allow some access, and it will only be permitted if done the way they’ve prescribed. In other words, if a process is followed. And it’ll work best if that process is automated and exposed for reuse.
In this example, a small workflow process automation could be created to log leads in Salesforce. Since this is about process (logging leads) and not data (a lead from the event), it’s possible to better assess the outcomes and steps beforehand. For example, have we checked to see if the company is known, whether the contact is known, whether prior contact has been made, and what the outcomes from those interactions were? Knowing that information, we can build the process to add/update/flag/route the record accordingly for the desired outcome. Moreover, this same process can be shared with others that need to log leads, broadening the impact beyond a simple script. Finally, as the inevitable changes are made – either to the Salesforce environment or to the process automation – those changes are considered and made once by the person/team that’s responsible for the application.
See More: Low-Code Automation: How Businesses Can Avoid the Pitfalls
Does Process Automation Need To Be a Herculean Task?
That’s not to say that this process automation needs to be a herculean task, or even a difficult one. There are a number of no-code/low-code process automation tools that simplify and speed up development. And thinking of processes as components is a milestone on the way to achieving a culture of digital transformation.
A final point worth making is that asset curators shouldn’t be seen as roadblocks. They’re necessary. It isn’t necessarily a matter of bureaucracy that must be accommodated, but rather a matter of responsibility that should be appreciated, especially if curators take on the mindset of being in the “how to” business as opposed to the “no” business.
Did you find this article helpful? Tell us what you think on LinkedIn, Twitter, or Facebook. We’d be thrilled to hear from you.
