Hello all, We’re in the process of on-boarding our first Citizen Integrator in the SnapLogic Platform. We’ve previously federated the development of production integrations to LOB developers, but the Citizen Integrator has a different set of requirements and I’d like to start a discussion as to how best to accomplish this. Below is the criteria we’re trying to meet: Enable power users of our Marketing team to do simple, low risk, integrations without involving IT Allow the Marketing user to leverage some of our existing shared pipelines and patterns Isolate the resources the Marketing team enough that it will not affect our production integration performance (new users could do some crazy stuff) Allow access to specific sets of production data, but not all shared accounts. They will not have the concept of dev, qa, and production, as digging through production data is their world. We’re considering a few options, each with drawbacks and advantages… We could make a new Project Space, as our current development teams have their own project spaces. This gives the marketing team access to shared assets, but puts them into the same production environment as mission critical integrations. We could perhaps create an entire new org. This would keep them isolated and I think we could assign a node specifically to that node to manage resources. But they’re not able to see shared objects unless we manually move them over. I’m also not sure if there is a cost involved here. I’d love to hear from anyone else that has already gone down this road. What methods did you try? What worked, and what didn’t? Thanks in advance! Brett

My recommendation on this generally depends on how your existing dev/qa/production environments are set up. Shayne is correct - you can separate the processing infrastructure by Project Space, as well as separating access to data. However, it can become complex to manage the development lifecycle if you have some spaces that do need management, some that don’t need management, some that need a little management (and so on) all in the same org. Possible, but complex. It might be just plain simpler to put them in their own org. That will let you keep your citizen integrators completely separate from your fully productionised integrations and minimise the risk of, for example, pushing a integration through your development pipeline that doesn’t meet your standards. It will also give you more power to set up your project spaces so that you can have, again as an example, a structure like this: - Department - Staff Member - Staff Member 2 - Staff Member 3 - Department 2 - etc. etc.

In general, you should be able to keep the new users on the same org; in their project space they can be given their own Snaplex (and only access to that Snaplex). This would probably be the best trade-off between convenience and security. I’ll let others who do this more often chime in. Shayne

One of the clients is trying to enable Citizen Integrations with following constraints : Business users can integrate anything. IT does not want any constraints All outbound data end points should be constantly monitored against an approval list

I think I would prefer the separate Org option. The main burden is then manually moving things you want to share from one place to the other. Given that you are okay with moving things, I guess my next question would be if you foresee other departments requiring access and integration at a future point. If marketing is the only one then standing up one other org and switching from one to the other shouldn’t be too painful. However, you don’t want this to always be a n+1 problem and have org proliferation. People also generally don’t like to touch things once in production and if in the same org, you would need to probably move your Snaplexes from org>shared to org>Production>shared so that marketing would not be able to run pipelines on the production Snaplex for the single-org model. Those are my main thoughts. HTH! -Tim

Thanks for the thought-out responses! Or environment currently consists of 3 Orgs (Dev, QA, Prod) We have 2 SnapPlexes (Cloud and Ground) that are at the Org-Shared level. We have defined Project spaces to align with line-of-business development groups Org Ecommerce Corporate Systems Store Systems etc… Marketing is the first set of users that aren’t purely development groups but will not be the last. This needs to a be a practical and sustainable pattern going forward. Seeing as how Orgs cost money, it won’t be accepted very well for departments with one or two users. The solution we’re leaning toward is to A) create a new project space called Marketing B) create a new SnapPlex called Marketing within the Marketing project space’s share. We have 4 additional nodes pending installation. As far as I know, we should be able to assign one or more of those nodes to the Marketing SnapPlex to isolate the server resources to that group. The problem that remains is keeping the Marketing users from running their pipelines on the Cloud or Ground SnapPlexes. I see two option here. First, as Time mentioned, is to move the existing SnapPlexes down from the org share into a lower level. The problem is that we have many Project Spaces that would all need to have SnapPlexes made. The second option is to remove access from “all users” to the org shared folder. Instead, put every user in a group and grant that group access. Keep marketing left out in their own group that only has access to their Project space. We’d just need to move down common shared objects that we want the the Marketing group into their project space as well. We do have an Integration Success Team in place to facilitate this sort of management within SnapLogic. Side note: Seems a bit strange that a SnapPlex, which is merely a run-time environemnt, is shared along with other pipelines and accounts rather than their own type of entity that can have access granted outside of the project structure.

brettdorsey

New Contributor III

9 years ago

Citizen Integrator Solution?

Hello all,

We’re in the process of on-boarding our first Citizen Integrator in the SnapLogic Platform. We’ve previously federated the development of production integrations to LOB developers, but the Citizen Integrator has a different set of requirements and I’d like to start a discussion as to how best to accomplish this.

Below is the criteria we’re trying to meet:

Enable power users of our Marketing team to do simple, low risk, integrations without involving IT
Allow the Marketing user to leverage some of our existing shared pipelines and patterns
Isolate the resources the Marketing team enough that it will not affect our production integration performance (new users could do some crazy stuff)
Allow access to specific sets of production data, but not all shared accounts.
They will not have the concept of dev, qa, and production, as digging through production data is their world.

We’re considering a few options, each with drawbacks and advantages…

We could make a new Project Space, as our current development teams have their own project spaces. This gives the marketing team access to shared assets, but puts them into the same production environment as mission critical integrations.

We could perhaps create an entire new org. This would keep them isolated and I think we could assign a node specifically to that node to manage resources. But they’re not able to see shared objects unless we manually move them over. I’m also not sure if there is a cost involved here.

I’d love to hear from anyone else that has already gone down this road. What methods did you try? What worked, and what didn’t?

Thanks in advance!
Brett

11 Replies

ncrouch
Former Employee
9 years ago
My recommendation on this generally depends on how your existing dev/qa/production environments are set up.

Shayne is correct - you can separate the processing infrastructure by Project Space, as well as separating access to data. However, it can become complex to manage the development lifecycle if you have some spaces that do need management, some that don’t need management, some that need a little management (and so on) all in the same org. Possible, but complex.

It might be just plain simpler to put them in their own org. That will let you keep your citizen integrators completely separate from your fully productionised integrations and minimise the risk of, for example, pushing a integration through your development pipeline that doesn’t meet your standards. It will also give you more power to set up your project spaces so that you can have, again as an example, a structure like this:

- Department - Staff Member - Staff Member 2 - Staff Member 3 - Department 2 - etc. etc.
shodge
Former Employee
9 years ago
In general, you should be able to keep the new users on the same org; in their project space they can be given their own Snaplex (and only access to that Snaplex). This would probably be the best trade-off between convenience and security. I’ll let others who do this more often chime in.

Shayne
vthatikonda
Former Employee
9 years ago
One of the clients is trying to enable Citizen Integrations with following constraints :

Business users can integrate anything. IT does not want any constraints

All outbound data end points should be constantly monitored against an approval list
tlui
Former Employee
9 years ago
I think I would prefer the separate Org option. The main burden is then manually moving things you want to share from one place to the other. Given that you are okay with moving things, I guess my next question would be if you foresee other departments requiring access and integration at a future point. If marketing is the only one then standing up one other org and switching from one to the other shouldn’t be too painful. However, you don’t want this to always be a n+1 problem and have org proliferation.

People also generally don’t like to touch things once in production and if in the same org, you would need to probably move your Snaplexes from org>shared to org>Production>shared so that marketing would not be able to run pipelines on the production Snaplex for the single-org model.

Those are my main thoughts. HTH!
-Tim
- brettdorsey
  New Contributor III
  9 years ago
  Thanks for the thought-out responses!
  
  Or environment currently consists of 3 Orgs (Dev, QA, Prod)
  We have 2 SnapPlexes (Cloud and Ground) that are at the Org-Shared level.
  We have defined Project spaces to align with line-of-business development groups
  
  Org
  
  Ecommerce
  Corporate Systems
  Store Systems
  etc…
  
  Marketing is the first set of users that aren’t purely development groups but will not be the last. This needs to a be a practical and sustainable pattern going forward. Seeing as how Orgs cost money, it won’t be accepted very well for departments with one or two users.
  
  The solution we’re leaning toward is to
  A) create a new project space called Marketing
  B) create a new SnapPlex called Marketing within the Marketing project space’s share.
  
  We have 4 additional nodes pending installation. As far as I know, we should be able to assign one or more of those nodes to the Marketing SnapPlex to isolate the server resources to that group. The problem that remains is keeping the Marketing users from running their pipelines on the Cloud or Ground SnapPlexes. I see two option here. First, as Time mentioned, is to move the existing SnapPlexes down from the org share into a lower level. The problem is that we have many Project Spaces that would all need to have SnapPlexes made. The second option is to remove access from “all users” to the org shared folder. Instead, put every user in a group and grant that group access. Keep marketing left out in their own group that only has access to their Project space. We’d just need to move down common shared objects that we want the the Marketing group into their project space as well.
  
  We do have an Integration Success Team in place to facilitate this sort of management within SnapLogic.
  
  Side note: Seems a bit strange that a SnapPlex, which is merely a run-time environemnt, is shared along with other pipelines and accounts rather than their own type of entity that can have access granted outside of the project structure.
  - shodge
    Former Employee
    9 years ago
    
    brettdorsey:
    
    Side note: Seems a bit strange that a SnapPlex, which is merely a run-time environemnt, is shared along with other pipelines and accounts rather than their own type of entity that can have access granted outside of the project structure.
    
    @tlui and I were talking about this the other day. We’re certainly open to suggestions to make the workflow more logical; FWIW, I’m with you on this one, but if we’re going to separate it out we want to make sure the redesign is actually a better user experience, so feedback is very welcome.
    
    Shayne
hema_rangaswamy
New Contributor II
7 years ago
We are facing a similar dilemma. I see this was discussed last year but did not see any updates after that. Anyone have further insight?

Forum Discussion

Citizen Integrator Solution?

11 Replies

Recent Discussions

Google Sheets Subscribe questions

Basic string transformations not working

Can we generate XML file in pretty print format using native snapLogic snaps?

Multipart Reader failure - 'content-type' was not found

Unable to write sldb file to file system