Multi-tier support structure for Alteryx workflows on the server in an Enterprise setting

[DeepakTyagi]

Not all support is created equal, so this is true for Alteryx. A traditional support structure in an enterprise is set for application or web development using programming languages like Java, Python, JavaScript, etc. With embedding Alteryx into the fabric of enterprise applications, there comes a natural imbalance in the equation. Support models and structure are different for homegrown and COTS ( Custom off-the-shelf) products. Alteryx brings another dimension to this equation by enabling self-service by the business users, which is rare in typical (web) application development. In those cases, a business user is a true consumer of the functionality while the technology organization takes care of the support.

With Alteryx there are the following stakeholders in the support foodchain:

1. Artisan: Business users who create and publish workflows ( and own them)
2. DevOps (Services Support): Support staff taking care of data sources availability ( DB, feed files, APIs, etc.), file delays, etc.
3. DevOps (Alteryx Support): team making sure Alteryx services are up and running
4. Infrastructure Support: Organization to provide infrastructure to run Alteryx

These stakeholders have different responsibilities and hence disparate vested interests in this ecosystem. This means they need to be altered for different events within this ecosystem, otherwise, they would either not have the necessary information or skills to resolve the issue. The following diagram shows different layers of support with varied events and concerns:

Support events generation for concerned parties

Following are the responsibilities of these stakeholders by event type:

Artisans/Users

1. Workflow failures due to business rules
2. Pre-requisites not met
3. Logic Issues

DevOps (Services Support)

1. Missing or delayed feeds
2. Database, SharePoint, or Network Shared Drive not available
3. API Interfaces unavailability

DevOps (Alteryx Support)

1. Unavailability of Alteryx Services ( Gallery, Controller, or Worker)
2. Slowness of services
3. Error in server logs
4. Patches or Version upgrade

Infrastructure Support

1. Space, CPU, or other server resources unavailability
2. Security Patches or version upgrade
3. LTM/GTM routing not working

In this way depending on the type of events generated in the Alteryx ecosystem, it can be routed to the concerned parties making it easy to support by the concerned parties.

Please comment on how support is structured in your organization.

[Suskil]

Hello Deepak, just confirming, that you are asking your question of the broader community?

[DeepakTyagi]

yes that is correct, I provided my opinion on building support for Alteryx in an enterprise and wanted to see what is the experience of other folks