Introduction
Large organizations are expected to deliver better services every year at lower cost. Most now run shared-service groups for HR, facilities, finance, operations and IT, and each group runs its own specialized software, chosen to meet its own requirements and regulations.
Delivering a service across those groups takes more than moving data between their systems. This paper explains why we think of the problem as service integration rather than data integration, and how the Kinetic Task automation engine does that work at enterprise scale.
Why the old model stopped working
Fortune 500 companies once aligned with a few large vendors whose platforms covered almost every business need. That era is over. Departments now pick specialized systems to meet their own requirements and to follow their own frameworks (ISO, CMMI, ITIL, Six Sigma).
The result is an organization divided into information silos. A single service might involve people, departmental applications and automated systems handling high-volume transactions. Requests arrive by web, phone, mobile app, email and self-service portal. Outside vendors run parts of the process, and more functions (infrastructure, employee services, network management, payroll, security, facility maintenance) are being outsourced every year. The boundary of the enterprise keeps moving, and the integration approach has to move with it.
Service integration versus data integration
Delivering a service means several systems, and several groups of people, working together on one request. Most organizations mix commercial off-the-shelf software with custom applications, on premises and in the cloud. Serving employees and customers well often means extending corporate data to vendor and outsourced systems so they can do their part.
Integrations are usually built one project at a time, around the data that project needs to share. Data sets end up shared in different formats, which creates maintenance and compliance problems. Each new project adds direct connections from one system to another. These point-to-point integrations are hard to maintain, and they put compliance and service continuity at risk.
Take an HR project that needs data from the finance system to fill in a cost field in the CRM. IT connects the CRM to finance. The same project also needs finance connected to an outside vendor’s system. That is two integrations for one project, and when the finance system is upgraded both are likely to break.
The arithmetic makes the problem clear. In a point-to-point model with x systems, the number of possible integration points is:
x(x − 1) / 2
The example project in this paper involves six systems, so:
6(6 − 1) / 2 = 15
That is 15 connections to build and maintain for one project.
If the HR system is upgraded and it connects to five others, every one of those connections has to be rebuilt, tested and redeployed to keep services running. On one project that is manageable. Across an enterprise where systems are upgraded constantly, it never ends.
A service-oriented approach
Systems share data because someone needs a service delivered. Designing integrations around the service, rather than around each data exchange, is what we call service integration. A service-oriented architecture (SOA) lets each department keep its specialized application and contribute its part of the service as a stakeholder in the process. Steps that are still manual can stay manual until they are ready to be automated.
With a central hub for designing services and managing integrations, connections are standardized and managed in one place. The same hub can run approvals, notifications and messages through a workflow engine, and report on services across the enterprise. Integrations become easier to secure and to scale, and governance gets simpler.
Kinetic Task as the service integration hub
Kinetic Task is a service automation engine that automates business processes through configuration. It has an open architecture so organizations can extend it to whatever systems and processes they need, inside and outside the company. Three properties matter most: adaptability, scalability and manageability.
Adaptability
Kinetic Task can connect to any application or database. It works with commercial systems and with any system that communicates through APIs or web services (REST or SOAP), whether that system triggers a process or helps fulfill it.
A library of task handlers lets Kinetic Task interact with those systems and also run approvals, send messages and assign tasks. Where a custom system handles a key function, the engine can be extended to work with it. If a system has a way to talk to other systems, it can take part in a process Kinetic Task manages.
Scalability
Kinetic Task scales horizontally and vertically. Fortune 500 companies and some of the largest U.S. federal agencies use it for processes ranging from two steps to hundreds of automation steps.
Each Kinetic Task engine can be managed independently, with its own policies and security options. That suits regulated organizations such as healthcare providers, insurers and government agencies.
Engines can also be clustered to process high volumes with shared business rules and work queues, for speed and redundancy, while keeping individual control over worker threads and business logic. Exception handling, detailed logging, database interoperability, the ability to pause nodes and processes, and import and export support large deployments.
Manageability
Any application or data source can trigger a Kinetic Task process, so organizations keep using the people, processes and systems they already have.
Services range from simple product requests to complex processes such as employee onboarding. Kinetic Task is built for nontechnical process owners, so service management can be spread across the organization rather than held by specialists.
The Kinetic Task Builder is a drag-and-drop interface where a process owner designs a service from request to fulfillment and improves it over time.
Task handlers are the connectors configured at each step of a task tree. They interact with fulfillment systems, send notifications and apply process rules. Because the architecture is open, task trees can be configured for specialized service functions without custom integration code.
Conclusion
With a service integration strategy built on Kinetic Task, organizations can build, improve and reuse complex services across departments, and stop rebuilding point-to-point connections every time a system changes.