Making IT decisions around introducing an automation and integration platform presents leaders with some tough choices. There are a lot of people at your organization to please – many of whom may have conflicting views about technology. As a business leader, you want to please everyone, but developers have specific needs and wants which may differ from lines of business\u2019 needs and wants. <\/p>\n\n\n\n
The typical developer wants to have the power to make custom integrations and automations, they want to do it themselves, and they want maximum power and extensibility. On the other hand, it\u2019s well-known that excessive centralization is inefficient, and the only way to truly scale is to empower more technical lines of business to work collaboratively with IT. <\/p>\n\n\n\n
When faced with the idea of granting design and deployment capabilities to lines of business on an integration platform, your IT team may counter with security concerns- will these integrations be governable? They also may express concern if you choose a platform that\u2019s less robust, just for the sake of ease-of-use for lines of business. And these concerns are valid. When democratizing business technology, you don\u2019t want to sacrifice robustness or end up with ungovernable \u201cshadow IT\u201d across the enterprise. <\/p>\n\n\n\n
So, is handing the keys to Lines of Business really a viable option? And if so, how can you find a platform that allows for decentralization and democratization without limiting the scope of power for developers (if and when you need them to customize or extend the capabilities of your integration and automation platform)? First, let\u2019s examine what the future of process automation looks like, to anticipate where business technology requirements are going. <\/p>\n\n\n\n
Related: How application integration and data integration differ<\/a><\/em><\/p>\n\n\n\n The major shift to the cloud, away from on-premise computing, has changed enterprise integration and automation needs and best practices. Looking to 2020 and beyond, Gartner<\/a> predicts a shift away from rigid approaches to app provisioning and integration, with an increased emphasis on \u201corchestrating\u201d multiple applications for individual job functions: <\/p>\n\n\n\n The Gartner report states that by 2023, 40% of professional workers will orchestrate their business application experiences and capabilities like they do their music streaming services\u201d, and continues, \u201cin the future, business units or central IT will receive capabilities in building block form, enabling them to create individual \u201cplaylists\u201d of applications customized to specific employee needs and jobs.\u201d <\/p>\n\n\n\n To enable this shift toward customization and the dynamic orchestration and automation of tasks, organizations need a platform that\u2019s agile enough for savvy lines of business, such as App Admins, Ops, and business analysts, to use it to automate and orchestrate their tasks, but extensible so that developers aren\u2019t boxed in.<\/p>\n\n\n\n Ultimately, your enterprise integration and automation platform should be elegant and powerful. Elegance and power seem immediately connotative of a lion or a mustang; elegance and power are also the guiding principles behind Einstein\u2019s e=mc2, celestial orbits, the periodic table, any well-designed oration or code. Elegance without power is like an ornate porcelain vase; though lovely, it provides little functionality and is prone to breaking down under pressure. Power without elegance is like an elephant or a musk ox; though strong, they can only perform tasks slowly and with guidance. Within the category of iPaaS<\/a>, which offers more power than task automation tools, and more agility and ease-of-use than RPA, meets these dual requirements. So what is iPaaS? Gartner<\/a> defines iPaaS (integration-Platform-as-a-Service), as \u201ca suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on premises and cloud-based processes, services, applications and data within individual or across multiple organizations.\u201d However, within this category, there exists a wide range of platforms that offer varying degrees of power for integration and automation, and varying degrees of elegance and agility. In fact, not all iPaaS are cloud-native, and the agility, time-to-deployment, and integration power can vary widely from platform to platform. Most iPaaS require specialists to implement and need to be run by IT. Platforms that can be used by non-specialists are often limited in capacity. However, there are benefits to an integration platform that can be used by non-specialists; that makes it possible for lines of business to work collaboratively with IT in designing and deploying integrations and automations, and all integrations and automations made within the platform are still centrally governable by IT. This makes it easier to scale automation across an enterprise and reduces deployment time. <\/p>\n\n\n\n Related: Everything you need to know about API integration<\/a><\/em><\/p>\n\n\n\n When looking at choices for integration and automation, business leaders and decision-makers may feel that the options are limiting, and divided into either:<\/p>\n\n\n\n 1. A simple platform designed for lines of business that offers inferior integration capabilities, or <\/p>\n\n\n\n 2. A powerful platform for integration that can\u2019t be used by lines of business, and is less agile for creating multi-step workflow automations<\/a>. Cloud-native enterprise automation transcends these dichotomies by offering a strong foundation of iPaaS and a friendly UI that empowers lines of business.<\/p>\n\n\n\n What does this philosophy look like in action?<\/p>\n\n\n\n iPaaS, or integration-Platform-as-a-Service, is part of the broader shift toward cloud computing. Some integration platforms, or iPaaS, run on a containerized architecture that scales elastically, easily. Cloud is key for peak provisioning, because you don\u2019t actually need to provision computational power on-premise. In the cloud, computational supply is virtually limitless. Serverless architecture epitomizes the combined elegance and power of a mustang, or perhaps, a lightning bolt- rapid, beautiful acceleration, from zero to peak power. On-premise deployment, on the other hand, is slow, and requires a laborious deployment process and server provisioning- more like the musk ox than the mustang.<\/p>\n\n\n\n McKinsey & Co.<\/a> cites container-first architectures as one of their top trends for 2020, along with microservice architecture. The report continues, \u201cIn parallel with these trends, the next logical step in application atomization is emerging. It involves the abstraction of compute resources, in which functions become a unit of deployment, or function as a service. This will eliminate the need to provision infrastructure or manage compute resources for these functions.\u201d<\/p>\n\n\n\n The underlying principle of extensibility in software development is to arrive at a cohesive abstraction, with fewer dependencies during development. Changes can be implemented in steps to adapt the system and improve its functionality to meet changing needs. For an integration and automation platform, this means that developers should be able to create custom connectors or code that can be inserted easily into the system to expand its scope and power, resulting in a seamlessly functioning whole. <\/p>\n\n\n\n Some extensibility mechanisms built into an integration platform include the ability to build custom connectors that can integrate new applications and systems into the overarching enterprise automation infrastructure. This could include printers, scanners, SAP, databases- really anything that you can code a connector for, the system can integrate with and be used to create automated processes with. <\/p>\n\n\n\n Related: A guide to process orchestration<\/a><\/em><\/p>\n\n\n\n A custom connector SDK (software development kit) is a powerful tool offered by Workato, an enterprise automation platform, that gives developers the documentation to build connectors to applications or systems that the platform doesn\u2019t support yet. This could be anything from a printer, to an on-premise application, to extending the power of a pre-existing connector for a SaaS application. For example, an implementation consultant may want to extend the capabilities of a connector to meet the needs of one of their clients. They want to perform additional actions or transformations in the integration from their ERP. With the custom connector SDK, developers have the power. Consultants are empowered to meet their clients\u2019 unique needs.<\/p>\n\n\n\n The Connector SDK allows you to create custom connectors using a Ruby-based template. It\u2019s designed so that someone who can do even a relatively simple degree of coding can make a connector. Users can also leverage our open source connector marketplace to pick up on existing connectors that have been built for similar API methods or authentication types. The platform allows them to install those connectors and modify them based on their application endpoints or other requirements. The range of resources available, such as the SDK or the open source community library of automations, mean that developers don\u2019t have to start from scratch. <\/p>\n\n\n\n We spoke with a developer, \u201cDeveloper X\u201d, about the experience of creating a custom connector for Okta using the SDK. <\/p>\n\n\n\n From a technical standpoint, Developer X noted that Okta\u2019s API is well-documented. They assessed the syntax & coding approach, and created the \u201cget Okta user\u201d API call. They tested some things within Postman. Once it was working, they transported it into the Workato connector. Developer X notes that when you create a new Workato connector, there\u2019s a dev interface where you can make, change and test your code until you get the result you want. <\/p>\n\n\n\n Developer X notes that the number 1 challenge in creating a custom connector with the SDK is that they were trained as a Java programmer and had never done anything with Ruby on Rails. So getting up to speed on the syntax was tough, but the Workato engineering team was very helpful and gave examples of code.<\/p>\n\n\n\n Related: The challenges of implementing cloud integration<\/a><\/em><\/p>\n\n\n\n Developer X noted that a lot of it is quite templated. Overall, Developer X described the process as a \u201cvery agile way of creating.\u201d You only code once; you don\u2019t need to redo for each customer. Individual customers aren\u2019t the only ones using that code, which makes it easier for developers.<\/p>\n\n\n\n A benefit of creating the custom connector (for Okta) in the SDK, according to Developer X, is that you just need someone who can code in Ruby, because the Workato SDK is very well documented, and the Okta API is very well documented too. So, you just need someone who can read the documentation and code in that language. You don\u2019t really need to understand customers’ unique needs, because those needs have already been abstracted up one level into the code.<\/p>\n\n\n\n Developer X says that sometimes, in the life of a developer, they get \u201cdeja vu\u201d coding the same integrations in different languages, and that when companies don\u2019t want to share their integration code, developers have to keep starting from scratch. The custom connector SDK ameliorates some of these types of issues. <\/p>\n\n\n\n Related: What you need to know about middleware software<\/a><\/em><\/p>\n\n\n\n Developer X cites speed of delivery and data quality as important measures of success, adding that \u201cdata is paramount; if you get job titles or start dates wrong, it has a cascading negative impact on things downstream. If you incorrectly code how you get someone\u2019s start date, they won\u2019t get access and won\u2019t be able to work on their start date. The data drives really powerful processes like access rights\/ability to enter buildings, etc.\u201d<\/p>\n\n\n\n For another vignette that highlights the power of extensibility, let\u2019s look at how Grab created a printer installation automation using their cloud directory service, Jumpcloud, in tandem with enterprise automation. Grab, an O2O company in Southeast Asia that notably bought out Uber\u2019s operations in the region, provides services ranging from food delivery to ride hailing. Grab created an automation that uses their cloud directory data, wifi connections, and printers. When a user is in a different office than they\u2019re normally in, the automation picks up their user information from Jumpcloud when the user connects to the wifi. Then the automation sets up their laptop with the local printer. <\/p>\n\n\n\n You can connect to IoT<\/a> and virtually anything that has an API, by taking advantage of the extensibility of the integration and automation platform. When you need your developers to custom code things, the SDK makes it that much faster. Custom integrations and automations built in the platform are centrally governable in the platform. <\/p>\n\n\n\n Another aspect of power in an integration platform, in addition to extensibility, is how powerful the underlying integrations are that power the automations.<\/p>\n\n\n\n A major flaw you see in some integration or automation platforms is the idea that it\u2019s okay to decrease the power of the integrations in the process of making the platform simpler and more accessible to less technical business users. However, creating automations without a strong foundation of iPaaS is like building a house on the sand. An integration needs to understand the metadata of the data being pulled from the API in real-time. The API may give duplicate data, and there are semantics around the data and how it\u2019s structured. In order for automation to work effectively and fulfill its goals of improved data accuracy and operational efficiency, it needs to have a powerful base layer of enterprise application integration<\/a>. Additionally, a connector needs to be able to handle a range of processes and transformations for a wide variety of systems, in order to meet the complex requirements of an enterprise. It should be able to handle:<\/p>\n\n\n\n Related: How an iPaaS and ETL tool differ<\/a><\/em><\/p>\n\n\n\n Abstraction makes complex phenomenon easy to understand and use in processes; for example, higher forms of math are abstractions that make it possible to easily conduct processes that would otherwise be laborious, if approached as arithmetic or algebraic processes. <\/p>\n\n\n\n Likewise, a pre-coded connector is an abstraction of code into a simple user interface. The friendly UI of an integration platform makes it possible to easily conduct integration processes without coding each step of the process. So what does this mean for businesses? It means that non-technical business users, like a business analyst or app admin, are empowered to take part in the process of designing and maintaining integrations and automations. When lines of business are empowered to collaborate with IT in the same platform, it\u2019s much easier to scale automated processes across an enterprise. This collaborative process cuts down the time it would otherwise take, to delineate written requirements and submit automation requests to the IT department. <\/p>\n\n\n\n The first steps toward elegantly executing business processes are to reduce or eliminate bottlenecks<\/a>, reduce or eliminate data silos between departments, applications, and systems, and to focus human efforts on tasks that can\u2019t be automated (by automating rote tasks). When human workers are empowered with well-functioning systems (one of the core initiatives of digital transformation) and business data such as Customer 360, they are enabled to offer more personalized service, more efficiently. <\/p>\n\n\n\n Fundbox<\/a>, a company that uses technology to accelerate B2B credit, turned to automation to eliminate bottlenecks in their data flow. Fundbox was originally having their engineering team build custom code to move customer data from their back-end tables into Salesforce, to support the Sales team. As the company scaled up and began to deal with a higher volume of sales, this became a bottleneck; it was draining engineering time that would otherwise be focused on core product innovation, and it wasn\u2019t efficient at their current scale. To address the issue, they introduced an enterprise automation platform that enabled them to create an automated data corridor to securely serve customer insights directly to the sales team in Salesforce, without intervention from engineering. Their new process is lean and efficient, allowing the company to continue to scale effectively, and redirecting their engineering talent toward innovation. <\/p>\n\n\n\n For a solution to be elegant, it should unite your enterprise automation infrastructure in a single system. Even if you\u2019re using many tools in business processes, from AI (artificial intelligence<\/a>) tools like Google Cloud Vision to RPA to a cloud data warehouse, with a range of processes ranging from ETL to workflow automations that deliver approval processes through Slack, your enterprise automation platform should be able to orchestrate these disparate systems together.<\/p>\n\n\n\n An inelegant automation solution is one that only solves fragments of the overarching problem. This approach leads to a patchwork array of integration solutions<\/a> on top of an already fragmented tech stack. <\/p>\n\n\n\nWhy Empower Lines of Business?<\/h2>\n\n\n\n
Setting up your IT infrastructure for success for both IT and Lines of Business<\/h2>\n\n\n\n
<\/p>\n\n\n\nWhat are the options for integration platforms, and does any platform offer both power and ease-of-use? <\/h2>\n\n\n\n
Enterprise automation synthesizes ease-of-use for lines of business with integration power<\/h2>\n\n\n\n
<\/p>\n\n\n\n\n
Serverless architecture<\/h2>\n\n\n\n
Extensibility lets developers expand the integration platform in scope and power<\/h2>\n\n\n\n
Custom Connector SDK gives developers freedom to innovate<\/h3>\n\n\n\n
About the SDK<\/h3>\n\n\n\n
How\u2019s the experience of creating custom connectors for the integration platform with the SDK?<\/h2>\n\n\n\n
What were the main challenges?<\/h4>\n\n\n\n
How long did the process take?<\/h4>\n\n\n\n
What were the big benefits of creating this?<\/h4>\n\n\n\n
How do you measure success (i.e. error reduction, time reduction, cost savings, higher customer satisfaction)?<\/h4>\n\n\n\n
Creative automations with the cloud directory and printer drivers<\/h3>\n\n\n\n
Power: how robust and varied are the processes that the integration platform can perform? <\/h2>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n\n
Simplicity: how abstracting code into an easy UI empowers lines of business to help scale automations across the enterprise<\/h2>\n\n\n\n
Elegance: elegantly executing business processes<\/h2>\n\n\n\n
Fundbox: Snowflake Data Warehouse Automation streamlines data flow<\/h4>\n\n\n\n
<\/p>\n\n\n\nMinimizing the number of platforms involved in the solution<\/h3>\n\n\n\n
Taking steps to implement these values in a concrete way into your enterprise integration and automation strategy<\/h2>\n\n\n\n