Talking Drupal #537 - Orchestration

Nic: This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 537 orchestration. On today's show, we're talking about integrations into Drupal Automation and Drupal with orchestration with our guest, Jurgen Haas.

We'll also cover CRM as our module of the week. Welcome to Talking Drupal. Our guest today is Juergen Haas. Jurgen started back in 2007 with Drupal 4.6. He founded Lake Drops, a Drupal agency in Germany, and is known as a maintainer of a number of modules like ECA. He's a co maintainer of the gen admin theme, and he is helping move that that into triple core.

His passion for privacy and security got him to contribute to Drupal CMS for those topics. Welcome back to the show and thank you for joining us. Hey, thanks for having me. Great to be back. I'm Nick Laflin, founder at nLightened Development, and today my co-host is John Picozzi, solution Architect at EPAM.

John: Hello.

Nic: And now to talk about our module of the week, let's turn it over to Martin Anderson Includes a principal solutions engineer at awe, and a maintainer of a number of Drupal modules and recipes of his own. Martin, what do you have for us this week? Thanks Nick. Have you ever wanted a Drupal native way to store, manage and interact with people who might not all be registered users?

There's a module for that. It's called CRM, which in this case stands for contact relationship management. And the project was created in April of 2007 by a Mika. But the, but Steve Ayers, AKA Blue Geek nine took over the namespace in 2023. Does have a 1.0 0.0 beta two version available, which works with Drupal 11.1 or newer.

It is actively maintained. In fact, the latest release was just a day ago. It has opted into security coverage, but obviously needs a stable release. It does have test coverage and there are 73 open issues, but all bugs have been marked as fixed. According to drupal.org, it is officially in use by 10 sites currently.

Now, listeners may remember that some mention of the CRM module was in the conversation about the member platform initiative back in episode five 12. As a reminder, something other than standard Drupal user accounts is useful for working with contact information for people where you may not have all the criteria necessary for a Drupal user account, for example, an email address.

Also, a dedicated system can make it easier to model relationships between contacts and provide additional capabilities. It's worth noting that this module defines CRM as contact relationship management, not assuming that the data is associated with customers or constituents as some other systems do At its heart, CRM defines three new entity types, contacts, contact methods, and relationships.

Each of these can have fieldable bundles and provides some default examples. Person, household, and organization for contacts, address, email and telephone for contact methods and head of household, spouse, employee, and member for relationships. Out of the box. CRM includes integrations with other popular modules like Group and Contact, in addition to a variety of Drupal core systems like Views and Search.

As previously mentioned, CRM is intended to be the foundational data layer of the member platform, but is also a key element of the open knowledge distribution meant to allow using Drupal as a collaborative knowledge base and learning platform. So let's talk about CRM.

John: Mean, CRMs are so, so important, right? And, and, and typically we say that and we think of like a customer relationship management system. I can see contact relationship management being important and, and useful. You said a couple of times this could be used in, in lieu of, or in as an additional way to keep track of contacts that, that, that, that don't need user accounts or, or don't have enough information for user accounts.

Do you also have the ability to kind of like associate permissions to these, to these, the entries in the CRM?

Martin: So from what I gather more granular permissions is, is actually one of the sort of key holdouts before this actually gets a stable release. I think the idea is to have, you know, the ability to associate very detailed permissions based on things like, you know what let's say.

Contact bundle, a particular user might be in those kinds of things. So, that's coming, but I, I have a feeling that today it's probably not as robust as it's intended to be.

John: Okay. So then that begs the question, maybe it doesn't, and I'm just an idiot. But I think it begs the question like, how is this different from groups?

Is groups just the organizational structure of the, of the individuals? Is that the idea?

Martin: That's partly it, but I think also groups really is intended to be associated with actual Drupal users, whereas contacts, again, can be. People who may never log into your, your Drupal site.

John: So, so going back to like integration with member platform, right?

Like you could have you know, you could have your, your membership roles for your, your organization built out as contacts as opposed to, as opposed to Drupal users, and then give them kind of the ability to see a dashboard or, or see certain content or something like that within your Drupal site based on contacts can't log in.

Right? But how do they, how do they get role assignments if they, if they don't have logins?

Martin: They don't.

John: Okay.

Martin: I, I would, sorry, Martin, I didn't mean to jump in, but that's my assumption. They, they, they don't, right. It's meant to be like, here's a list of, if you remember from J D's show about member platform.

It's, I think it was for like the, the initial use case was the HOA right. So you can think about it, it's, it's kind of like a robust mailing list almost. And, and track, like you can track, oh, hey, this person got it. Ha has this, they they need some help with X, Y, Z.

Oh, geez.

John: Yeah, no. Okay. Okay. That makes, that makes more sense to me now. So it's, this is basically like an, an administrative tool for organizations to keep track of contacts. Tho those contacts could be associated with a user account that logs them in, that gives them access to online content, but not necessarily to Nick's point.

It could be a, you know, just a, a, a mailing list or call list or something like that. Got it. Okay. Well that makes, that makes a heck of a lot of sense.

Martin: Yeah, I, I will say that the piece that. Ever since jds show, I've been in the, the member the member platform channel. I, I haven't contributed much, but I've been kind of keeping an eye on it because I think it's kind of interesting.

I will say CRM feels like a very fast moving project. I think Steve is doing Steve well, the, the whole member platform team. But Steven in particular, I've been seeing a lot of updates. So I think they're, they're putting a lot of work into it and it's something that I plan on giving it kind of a test run and seeing how it works because it, it's one of those things where I don't think it's really gonna replace Salesforce for a lot of my enterprise clients, at least in the short term.

But it might fill a gap for a lot of the, you know, smaller organizations that need to have something lightweight. They don't, you know, they don't have the infrastructure or support to have a full Salesforce Salesforce implementation, but building that out individually also isn't feasible. So having something like this is great.

I feel like.

John: I feel like you, you're hitting on a show topic here, Nick, because I'm, I'm in my head, I'm kind of like, well, so CRM contact relationship management, how is it different than CRM customer relationship management? Right. And I imagine it's more fields, more ability to kind of maybe make relationships between between, you know, individuals and organizations and that sort of thing.

But I feel like that's probably a, a wider, a wider topic than, than what we have for our module of the week here today.

Martin: I mean, I think the short answer is, is customer relation. You know, the traditional CRM is more about something more transactional. Like a, a company's trying to attract their customers, the customer relationships that they can either assist them better or sell more stuff to them.

Whereas this is just meant to be broader and more inclusive of different types of organizations.

John: I love Nick. Nick because he can never leave a tease unanswered. I can't,

Martin: can't do it. I think it's probably worth adding that. A lot of people in the Drupal space will probably be familiar with CCRM as kind of a open source project that was originally kind of a Drupal module and then sort of, you know, went off and kind of became its own thing that has its own sort of community and ecosystem at this, this point doesn't integrate still with Drupal as well as WordPress and a number of other projects.

But I think really part of the vision for the CRM module here is to have. Eventually a, a similar set of capabilities in terms of like, you know, mailing list integration, a bunch of other things so that you can do very robust things without having the complexity of sort of having two separate hosted systems that, that end up integrating with each other.

John: And sorry, Martin, just to clarify, you, you said that CVI is, is still capable of integrating to Drupal, right? Yes, definitely. Yeah. Okay. Sorry, I thought you said isn't, and I was like, wait a second. I mean, I guess that makes sense in the fact that like CRM contact relationship management, right, is like the, the base of that, of, of most of the, the customer relationship management systems where you're, you're building that profile for that person, right?

And then like, if you wanna integrate into, you know, MailChimp for your email and, you know, a phone system for your phone stuff, and like you, you have that kind of capability. And sure, we're gonna talk about a lot of that stuff on today's show because you know, I would imagine you need a pretty good orchestration layer to make all of those things happen.

We've come full circle.

Martin: Well played my friend. So, sorry, Jurgen, did you have something to add?

Jurgen: Well I just had another use case in mind for CRM, which is what Martin is involved with a lot, which is the event platform. I can imagine that CRM with the event platform can do great deal as well, doesn't it?

Martin: Yeah. In fact JD who was on the show back in episode five 12 has opened an issue on the event platform specifically to sort of, you know, make sure that we have those discussions as the member platform, you know, starts to take shape to make sure that those two should work together. Because you can definitely imagine where, let's say, you know, you've got you know, a regional Drupal users group that wants to have regular meetings that, you know, the member platform could be useful for, but then eventually use that list of users or contacts as people that they want to invite when they go to plan a camp.

At which point the, the event platform, you know, you would want those two things to be able to sort of coexist and play nicely together, if not actually have some synergies together working together on a single.

Awesome. Thank you Martin. As always, an on-topic module or pseudo distribution or whatever you wanna call it, but how can folks connect or suggest a module of the week? We're always happy to talk about present, past, or potentially future modules of the week in the talking Drupal channel of Drupal Slack.

Or you can do as Steve did, and reach out to me directly on all of the Drupal and social platforms as men. Clue.

Nic: Awesome.

Thank you so much, Martin. See

John: you next week. See you then.

Okay.

Nic: Well, Jurgen, thank you for joining us again. Can we start with kind of a high level, you know, what is orchestration?

Jurgen: Yeah. Well, I have to admit, whenever I hear that term, orchestration, my association. Comes up to a conductor very much like, the logo of Composer, a very famous tool that we use every day.

And there are so many similarities that, like, for me, orchestration is really kind of an art or a skill to get multiple independent processes or probably even multiple systems to work together to accomplish a certain goal. So, and that's also like, you know, a lot of people mix and match things like orchestration and automation, whereas I think automation is something which is really focusing on a single task that gets automated that can be accomplished without a human being having to be present and help out and answering questions and interact with the system.

So that's automation itself, but orchestration, in my view, sits on top of that by combining lots of automated tasks and human beings to Cooper cooperate with each other, coordinate their efforts, and make sure that over a long period of time, the workflow, if you like, gets completed and the result is achieved.

John: So, my question was gonna be around the automation as far as like, what's the difference, and I think you just did a great job of, of explaining that, but I wanna see if I can I, I can dive into that a little bit more, but also then kind of, elaborate on your, your orchestra conductor example.

So, would you, would you agree that an orchestration strategy, workflow, however you wanna, however, whatever you wanna call it, we'll just call it an orchestration for right now, right? Would you agree that an orchestration would have would consist of multiple automations, right? Because the automations are kind of just smaller, maybe single, single tasks, Hey, you know, make this file, do this thing, send this data, that sort of thing.

Jurgen: Absolutely. Yeah. So it's, to me it's multiple automations and the orchestrator is kind of organizing them in a way that they can either run in parallel or in the right order. Okay. Which can

John: depend on certain things. Yeah. So going back to that co, going back to that conductor sort of, example, right?

You know, we're, let, imagine, let's imagine our orchestration is like a piece of music and let's imagine each, each instrument as a service or automation, right? Those things are all gonna come together to craft that piece of music. And the, the conductor is going to, you know, orchestrate them in a way that's gonna basically allow them to, to at the end say, oh, that was a lovely piece of music and everything sounded the way that it should and did, did what it should.

Is that like, is that a fair representation?

Jurgen: Absolutely. I like that picture a lot. To me that explains exactly what it is. Fado.

Nic: So it is the, or is orchestration then? Holding information about the services it's connecting to make or making decisions about which service to utilize in a particular situation or, or both?

Jurgen: It can be both actually. I would say. And in particular, if you think about orchestration nowadays, also used in the AI space where they use orchestrations well for the agents to make sure that they can be well orchestrated in a way that they, each of which can do their own job, produce some results, which are probably unpredictable.

And the orchestrator takes those results, makes decisions on itself, and then gets other agents, other tasks, other automations, more instruments. Into the next steps to move forward.

John: So I actually have a point of clarification with Nick's question because Nick, is the question for you in an orchestration, is the, or the orchestration itself determining what services to use?

Is that what you were, you were kind of getting at?

Nic: Yeah, it's more like, so let's say we have a task sure. The task is send an email to a user with Quality X. Sure. Right. I, I guess in, let's say you have connections with both SendGrid and MailChimp for some reason. Right. Okay. So at the ground level, is orchestration just handling the connection to SendGrid and the connection to MailChimp?

Mm-hmm. Or is it also being like, okay, in this particular situation. It's better to use MailChimp for x, y, z reasons. And another situation is better to use the other, like where, where, yeah. Which piece of the logic is it? The orchestration handling.

John: So I, I, I'm gonna, I'm going to share my, my thinking on this, and then Jurgen can correct me where I'm woefully incorrect.

So I mean, like, I don't know. I, I guess if you integrated an AI agent into your orchestration that said, Hey, here's my list of services, right? You know, here, depending on the task, you pick the best service to do this and go just do the thing, right? You, you might get that result, but the way I kind of look at orchestration is you're, you're gonna, you're gonna look at.

Okay, we're doing this task, right? And if it's to send an email, hey, we use SendGrid to send emails. If it's to send a mailing list, we use MailChimp to send a mailing list. So like you're gonna kind of build that orchestration on like, Hey, if somebody does X, then it's gonna fire off this process and this process is gonna go to one of these two services.

Right Now there could be AI in the middle there that says, Hey, craft a nice message to this person based on the fields that they filled out in this form and send them, you know, an automated welcome message. But I don't, I mean, I personally wouldn't set my, or my orchestration to not have like a very clear outcome or, or have an outcome that could be one of three.

Jurgen. Am I wrong in that, that assessment? No,

Jurgen: you are absolutely right. I couldn't agree more. I also have to say that as far as I know, there is no. Descrip definition of what orchestration really is, at least not within the triple space yet. That is something that we're gonna talk about the roadmap later on, but this is something that we're currently working on, like what is it that we wanna accomplish with orchestration in Drupal and each of those pieces that you just mentioned, each of which individually can be seen as an automation piece, and whether that lives somewhere in the ECA space or in ai or in an external tool or is part of orchestration.

To me it doesn't really matter that much.

John: Mm-hmm.

Jurgen: It's one of the building blocks that is part of the whole composition of the picture of, or the workflow. The music as you mentioned before? Mm-hmm.

John: I think so. Like the way I, I think about this and, and I like this is so like, I don't feel like orchestration as a, as an idea is, is new, right?

Because we've had different Yeah. Ways of kind of doing these things and organizing these things, I think, or orchestration in the, in the, the frame of, of Drupal and kind of what, like, as you just said, what it contains is, is new. And that's something that you and Dre are, are kind of like spearheading and, and working on.

But like, the way I always think of it is like. Specifically with what the work that you're doing is it's gonna, you know, my hope is that it ends up being a common language similarly to the AI work that's being done where you can integrate with a bunch of different services or one service that has a bunch of different services that it integrates with, and there's a, there's a standard communication right there that, that Drupal is using to talk to those, those types of services.

Jurgen: Yeah, that's spot on. That's exactly what we just, last couple of weeks we discussed a log, like, wouldn't it be great if we had a schema, like a definition of what can be the tasks, what can be the components, what is the flow and how do they communicate with each other? If we had something like one definition for that, then every single component that we already have in the Drupal world.

Outside of the Drupal world would only have to be connected into that standard. And that would make sure that they all work together in a way that we want it to be. And not only today, but also in the future if there are new participants just showing up.

Nic: So, so it's almost like an internal MCP server, but just for, rather than being for AI models, it's for whatever orchestration tool is being integrated.

Exactly.

John: Yeah.

Nic: So, so let's bring it back to, to Dral. I guess the question is why is orchestration such a focus in the, in the Drupal world right now? Why do you think this is the time that it's it's having its heyday and people are interested in it and you're working with on some requirements and he's testing it and writing about it.

Why, you know, why is it such a big focus right now in the Drupal world?

Jurgen: There are actually a few one of which I would like to start with is that Greece last year, around summertime, started to post about real threats on Drupal agencies. Like, you know, we have a global economic downturn, we have some sort of political pressure or uncertainty.

And then on top of that there is ai, which is another threat to lots of Drupal agencies because, you know, do we still need all the developers and so on and so forth. So he started posting about what happens to those agencies, and if the traditional business model, like creating websites is going to disappear or at least declining.

Is there an opportunity for those agencies within Drupal with the use of their existing experiences and resources to leverage them and create new business models? And orchestration was an idea that this could help them to actually get to new sorts of clients, to sell other services, but utilizing the same tools like Drupal as a framework.

So that is one of the reasons why this came up during 2025. Another one is remember talking Drupal 5, 3 2 when Alexander from Open Social joined us as well, where we talked about Drupal as an application framework rather than content management system. And there are quite a few people in the community really interested in that or even doing business.

That topic for a long period of time. And for them orchestration or coordination or connection with external systems becomes more and more relevant. And we already,

Nic: sorry, just really, really quickly that, that's episode 5 31 I think that we mentioned with Alex. Yeah. Yeah. Okay. Yeah. That's 5 31.

We'll, we'll have a link to that in the show notes as well. Yep.

Jurgen: Good. And the third reason is that we already have in the Drupal Drupal world, a lot of capabilities around automation and orchestration. We have lots of individual connectors to external systems. We have the AI initiative like you mentioned before.

Wouldn't it be nice to get. To like a similar level where we can create a strategy long term and get all the resources around the globe being interested in that topic, working together. And if we think about what's already present in Drupal, what comes to mind? Let's say just the four big ones is maestro, which is around since 2003.

There is ECA. There is the whole AI framework with agents, the automator and even AI orchestration is the thing by now. And then there is flow drop emerging right now, which is probably coming with another automation engine. However that's gonna look like in the future. I dunno exactly what the plans are, but those four alone are doing a lot.

And it would be a shame if each of them is doing just their own thing. I think we can all benefit from, if we get them to work together nicely.

John: So you, you said something interesting and you know, kind of re result referring back to like, you know, DRES talking about the challenges that agencies are having and, and this is a I don't know, a way to use Drupal to, to, to provide kind of these, this connective tissue between these services.

I just wonder, like, do you think that the ease of use of AI and the fact that a lot of services have integrations into other services now have kind of brought this. To the forefront, because like for me, I mean, for the last like five plus years, I've always thought of Drupal as that connective tissue between systems.

And I've always, I've always, you know, five, five plus years ago, right, it was APIs, oh, we can just connect APIs and we can share data back and forth between Drupal and other systems. Or, hey, there's a module that connects Drupal to you know, this service or that service to kind of share that data. Like, I guess like my question here is like,

why, why is there this, this like focus now to try to make it, to try to make it easier and more streamlined? Is it because the internet around us is becoming easier and more accessible to the average person?

Jurgen: Well, it's more services, that's for sure, and that makes it more complicated and more complex. So there are many more things that you wanna connect to and that makes it more challenging and leaving that to the individual to find out what's the best way to integrate into system X, Y, or C is what probably worked out in the past to a certain extent.

But it's now time to coordinate those efforts and to lay out a road on which we can all accelerate a lot and streamline the whole thing. Hopefully to the extent that we can even come up with a standard, which not only coordinates stuff today, but is also the groundwork for stuff that comes up in the future.

I think that's

John: very important. I see. So like five plus years ago, there weren't a ton of services that people were necessarily integrating with. Now everybody's got an API and instead of having to connect with every single API, you'd connect to like 50 of them, you'd waste a bunch of time. It's a lot easier to streamline that and, and, and, you know, work with one set of, of rules to be able to say like, Hey, we're gonna use orchestration framework and everybody's gonna connect, connect to that.

That makes a lot of sense to me. Okay. So based on that kind of, that, that principle, right, of like streamlining and allowing, you know, Drupal to connect to an orchestration provider framework and then have that framework connect to all of your other, other services and provide kind of bi-directional information flow and, and that sort of thing can you tell us a little bit about.

The orchestration module in Drupal. This is like obviously a relatively new module, but like where, where does it stand right now? And then what, what you know, we'll talk about the future and, and the roadmap in a little bit, but like, what, what's the goal there? Is it really just to provide that connective, connective tissue between Drupal and those, those orchestration services?

Jurgen: I would like to start answering that question. Why does it even exist? So what is the purpose? Why did we think that we need something like an orchestration, what your and I was asking myself like, you know, like, yeah, we already agreed we need connectors in Drupal. We wanna talk to all those systems out there in the world to offer better services.

Now there are hundreds of them, if not even a thousand, right? And the question is, are we going to. Modules for each of them hundreds or even a thousand, or should we leverage existing platforms like N eight NS, active pieces and all the others to just use what they already have developed and continue to maintain?

I don't have the final answer to that question. You know, is it better to develop stuff in the Drupal ecosystem or let that be done by others? But put that aside for now, because the second part is that we also have those internal automation platforms that we mentioned before, like ECA, Maestro AI Flow Drop, and others.

Now, if we look into our potential customer base, there are probably 10 external platforms and four internal ones. We should assume that every now and then there is the need for each of the possible combinations between those 14 tools or platforms, which would mean that we have to develop and maintain 44 O integrations between each of them.

Well, who wants to do that, right? Yeah. So the idea was if we could come up with a gateway or a proxy, and that's what the orchestration module should be, so that wants to sit in the middle of it and just coordinate the communication between the four team participants, 10 external and four internal platforms.

And that means we can reduce the number of integrations that we need to make them all work together from 40 to 14. And that is. Achievable that can be done. That means that well, our instinct reaction, if we wanna get maestro work with N eight N, what we usually did was create a module for just that integration, and that is pretty straightforward.

It can be done very quickly, and it happened in the past a lot. Now, doing that through an obstruction layer, like the orchestration module, that requires a little bit more design upfront to actually think about how can we get things done in a way that we don't have to think about who is the other platform listening to me over there, I just wanna submit task somewhere.

Being confident that orchestration makes sure that the right recipient is getting it. Controlling that it actually does the job and then responds with the result. And that is the whole purpose of orchestration module.

John: And I mean, that's like, there's a piece there that I don't, I don't know that it's a very small piece, but I don't know that a lot of people realize is that once you abstract it right to that level, you can then say, well, you know, service X didn't really work out for us or doesn't do these key things that we needed to do.

Let's switch it with service y. And now you're really just connecting a new service in that place and maybe adjusting a few of your orchestrations to say like, okay, now Service Now service Y is in place. And like, let's see how that one runs. Right. Exactly. Yeah. De it definitely, definitely removes that kind of layer of complexity.

It, it also,

Nic: it, it also helps I think with things like major version upgrades or rollouts because, you know, it's one of the problems that the community is running is running into now is Drupal 12 is around the corner and still the tail of modules that haven't been updated for Drupal 11 is fairly high.

John: Hmm.

Nic: Right. And especially when you have these type of integration modules right there, there's some that get created by the company and then they decide they're not gonna maintain it anymore. There's some that are created by people and then there on a different project. Now, so if you, if you have five, six, you know, most projects don't have more than five or six integrations, you know, at all.

But if you have five or six, you know, chances are one or two might be abandoned. But if you can route them all through kind of a single point, it, it, you get the web form effect. Right. You get the ability to. Consolidate a lot of the effort in one place. Everybody can build on each other's work. And you're, it's more collaborative rather than competitive.

The, the truth is, and it has to be a community driven effort, right? Because like, T-M-G-M-T-I think is a good middle ground of these two, right? T-M-G-M-T provides a single point of integration and then individual services then integrate with T-M-G-M-T. So you get a fairly consistent viewpoint, but that still runs into the same, the same problem.

That translation management something dashboard.

John: It just stands for translation management.

Nic: Is is, is that it? Okay. I, I didn't remember which, but like,

John: which the acronym confuses me every time. 'cause I'm like translation manage. Yeah. But anyway, I,

Nic: I was, I, I called the Teenage Moon Ninja Turtles module.

'cause that's sort of, that's fair. But the, the nice thing is about it is that if I decide to switch from one provider to another, aside from Lingo Tech because they did their own thing you know, you just add the other provider. You can test it on a couple. If it works, it works great. You know, it, it's the same.

We have the same problem with the AI world right now, right? They, they've been working on fixing this, but right now ai, they've abstracted a lot of it, but still the prompt is tied to a particular field in config and swapping that out. Yes, it's easy to add an additional, you know, you can add another, the provider and then you can update something and test it.

But if you're using it on five or 10 entities, once you wanna roll that out, you have to edit five or 10 entities and push that out. But make sure you didn't miss one. And you know, I think things like orchestration really streamline that process and really have an opportunity to make the developer and end user experience a lot, lot better.

Jurgen: And also in the solution space. I would like to emphasize what used John said before, like replacing one platform for the other. Imagine, you know, we wanna help Drupal agencies to come up with business models or solutions or products. Imagine somebody develop something that incorporates lots of external platforms and their first client is using N eight N so they can use all their development that they have inside Drupal, get it to work for that client with N eight N very quickly.

But then they come to the next client and they already have s in place. Do they wanna convince them to switch to NAN? They don't even wanna try. So having a platform that allows them to replace one for the other makes their own product more generic. It's probably not really like plug and play, but it's much, much easier to replace one for the other.

Yeah. And we just have to be open-minded what people are using out there. It's not our choice.

Nic: Yeah. That, that's

that's a huge point. Yeah. I, I think that's very helpful. S speaking of Zapier what do services, like active pieces or Zapier provide, or NAN you know, what do they provide for orchestration?

Jurgen: Well, just the number of integrations they provide. If you ask them, they call themselves an orchestration platform and they would like to be that conductor, the unit that makes sure that all those pieces work together.

And yeah, I agreed they can do that. But Drupal wants to be the conductor in certain spaces itself. So in that environment, those platforms are just a collection of connectors to other systems. And that's the value for us. But we should be prepared that in certain use cases, SAP is probably the conductor and Drupal is just one of those pieces that delivers certain tasks for the whole orchestration.

John: So, so that's interesting. So in one, in one scenario, right? They, they, those services could just be integration catalogs, right? Basically like, Hey, flip through and find all the integrations that we have. And then you can, based on the integration, the service you're integrating with, you have like this list of things you can do, right?

So it's like, it's a bit like a, basically like a catalog of, of integrations, which is awesome, right? That's a, that's a great, a great thing. But in the, in some cases it may actually be the, the orchestration or the conductor of that orchestration, meaning you're building that orchestration in that, in that tool.

So couple of questions on that point. I can understand. So, let me dial it back to Orca. The orchestration module in Drupal first is the point of the orchestration module in Drupal to. Retain the control as the conductor when integrating with these services, or from what you said, it kind of sounds like it depends on which service you're integrating with.

Jurgen: Yeah. We don't wanna make assumptions here. We wanna provide capabilities so that people can do what they need to do without having to adjust themselves to our system. Our system should be flexible enough to allow them to do what they wanna do. Of course, we like to see Drupal to be the controller, the conduct, the, the unit that controls the other systems, but we don't always have that power.

Mm-hmm. Or users have a need to do it just the other way around. And then Drupal and the orchestration module makes that possible. Drupal is just one of those pieces. That the other platform integrates with.

John: So that's interesting to me because I, I, I think that, I think that flexibility and, and leaving it up to the architect or the developer or the organization to choose where that action happens is super important.

Right. Like Drupal could come in, like we could come in and say, oh, orchestration, if you're using the orchestration module, we're gonna be opinionated and you have to do all your orchestration in, in, in Drupal, right? But going into an organization that maybe has used it, used Zapier for five years or 10 years, right.

They probably don't wanna retrain staff on how to, like, re, re or reuse a new tool, right. Unless there's a really good reason. So I see, like, I see that approach as being, as being like the best of both worlds because I can, I can see, I can see a side where. You know, organizations use Drupal as the, as the, the conductor and build their orchestrations in Drupal.

And, and those other, those catalogs you know, the, those services just act as catalogs where you pull in an integration and build it and, and they go and they facilitate that, which is great. But then I also see organizations that are like, we use Zapier and like Zapier, like our non-technical users use Zapier, and they're still able to get content auto Drupal and, and do what they wanna do in their orchestration orchestrations within Zapier.

And like, that's, that's the way they go. So like, that feels, that feels like a really great approach to me. And it, it, it seems to make sense, but with that being said, it feels like it puts a little bit more onus on the architects, the developers, the people that are building the Drupal systems to say, okay, if we're rolling this out, if we're in, we're adding this functionality, we need to talk about a few things as to how we do it.

Jurgen: Yeah, absolutely right. With flexibility or with power comes responsibility. So yeah, you have to make decisions and to be able to make them, you have to do some research, some you know, discussions, and then decide what's the best way forward.

John: It's always interesting to me how often we quote Uncle Ben in, in the, in the, just the development and, and Drupal Industries, you know, with great power comes great responsibility.

Yes. Yep, a hundred percent.

Nic: I, I get, well, I guess one question that comes to mind for that though too is do you see this as facilitating a way to solely migrate some that logic, right? So if, if an organization is deeply embedded with Zapier, it sounds like orchestration is a good way to just let Drupal kind of add onto that, but not take over.

I imagine you can, as new features come in, you can connect with, use orchestration and connect to those, and then you can slowly move the Zapier stuff into Drupal. Oh, that so de decoupling is, is easier at some point. Oh, Nick, if you need to, we don't need

John: to take over everything. It's okay for Zapier to do its thing.

If we take it over, we then take on the maintenance and the, and the, the, all the the other stuff that comes along with it. The technical debt, if you'll, well,

Jurgen: it's probably not taking over the code to connect to other platforms, but to take over the orchestration piece.

Nic: Yes.

Jurgen: Like be becoming this conductor more and more.

And I think that's really an interesting one because once people realize that, for example, data ownership. Or being in control of your own destiny, like you wanna really own your orchestration. What's better than having that in Drupal rather than on a third party platform? Yeah. Which could shut down next week for whatever reason,

Nic: or, or increase their cost by 400% or have some other issue.

And, and so I think that's, for a lot of these organizations, I think that's where the value is. Be like, Hey, look, we're not gonna get rid of Zapier. They're currently, I think they're considered number one in the business for this thing, but we're going to reduce our dependence on them. So if something happens, our relationship sours, that cost becomes too much, or we decide we wanna maintain it ourselves.

We have the ability to switch. Because the truth is, I have many, many, many clients where they're using a service because getting out of that service would cost them millions and millions of dollars, not because they're happy with that service. I think this can be a tool that can be like, Hey, we can, we can reduce some of our dependence on third party while still leveraging the parts that we like, and then if we wanna test something else and see if something else is better, like N eight N or Active pieces or, or even just evaluative, ZA is still solving the problems that it should be solving.

You can do that. Whereas if all the business logic and all the orchestration and all the. Are in Zapier, you have no way to test that. You have no way to extract yourself.

John: Mm-hmm. All right. All right. I, I see your point, Nick, I guess as a, as an alternative or a backup or, or, or a you know, a belt and suspenders sort of, of method or way to orchestration that makes sense.

I just, you know, the, the doom and gloom scenario was, was concerning to me. But yeah, I mean, I think that what you're saying makes a lot of sense. And I, and I think you highlighted a really interesting point there, or an important point there too, Nick, is like, for some folks, like just the cost of moving from one to the other would be, would be a, a deal breaker, right?

You, you mentioned active pieces and we've mentioned active pieces a few times since we started talking kind of about orchestration frameworks and providers and that sort of thing. Juergen, I'm wondering it seems like active pieces was the first provider, or is the first provider that orchestration integrates with.

Why was that? Why was active pieces chosen?

Jurgen: That was a very simple reason. Drees, as an angel investor in that business, he exposed that information in the DRIs note in Vienna just came to me and asked if we could just have a look to integrate Drupal and active pieces, and only as part of that integration work, the whole idea of a more abstract orchestration approach evolved.

So that wasn't the original approach. The original approach was just integrating with active pieces. Now we realized. There is probably a bigger opportunity there. Mm. And the reason why DRIs was going for active Pieces and not one of the others, is that active pieces is an open source platform where all the others are not.

So that's much closer to our values and it now turns out that it's actually really helpful. We have people who are now interested in doing similar things for N eight and and za.

John: Mm-hmm.

Jurgen: And we can just give them the integration that exists for active pieces and ask them to use that as a blueprint and do their work on other platforms in a similar way, because we believe that the design that we came up with is actually not too bad.

And it would be great to have kind of similar levels of integrations from N eight and into Drupal, like from.

John: Or from, sorry, I'm not familiar with N eight. And that is not an open source orchestration.

Jurgen: They have a fantastic marketing department. You know, they made the whole public believe that they are open source as well.

John: Interesting. Okay.

Jurgen: And it isn't, A few people had really bad wake up calls, like as an agency. Just to give you an example, their license agreement doesn't allow an agency to pay for an NAN installation and then distribute that to their clients. Like, you know, they could say, look, I have an NAN server. I pay for that once and you are kind of tenants on my platform.

I can't allowed to do that for no money in the world, so you can't even pay a higher license fee

John: to

Jurgen: make that and then control who is using their platform. So every single user has to sign up a contract with them and not through an agency. Interesting.

John: Okay. And then Zapier, I mean, Zapier's been around forever.

They're a, they're, you know, a for pro for-profit company sort of, sort of deal. Yeah. So like, I kind of knew they weren't, they weren't open source. Interesting. So, okay, so active pieces is open source. What does that, I mean, what does that look like if it's open source? Like I know that they have pricing plans and things like that.

Like what whatcha paying for if, if it's an open source service, are you paying for like a hosted version of it?

Jurgen: That is mainly what it amounts to. Yes. What they do do as well is within their software, there are certain features that are disabled by default and if you want to use them as well you get a label that says, please contact our sales department.

Mm-hmm. So they would like to talk to you then and just increase the price a bit if you wanna use more features.

John: Mm-hmm.

Jurgen: Personally, I think it feels a bit like it's a very new company and they are not finally settled on that business plan yet. That's, that's my impression that I have. And I really hope that they get to the point where the software itself will be really open source to.

So if somebody goes through the hassle to host themselves, they should not be limited with regard to features that they can use. And then they should just pro, well just forget about that term, like they should provide hosting services, which, well, they are the experts. They know how to do that. They know how to install everything so that it scales with high demand and everything.

And lots of customers are happy to pay for that instead of doing all that work themselves. Sure there have been lots of businesses really growing on that business model and everything that makes it a bit more shady is probably not doing so well in the long term, at

John: least in my experience.

I imagine though that like, like. For me, I'm kind of like, okay, it's open source software. I can see your code. If I wanna run this on my own, I could do it. But like, I don't really wanna do that, I don't wanna have to deal with that, that I, I also see maybe in a, in a future iteration, them selling integration packages, right?

Because the nice thing about this is that like, you're an orchestrator, so you connect to a bunch of different services. So like, maybe there's a basic set that allows me to connect to 10 services and there's a more advanced set. Like, I don't know. I feel like there are different ways you could, you could monetize this in a, in an equitable way for everybody.

But the fact that you can go look at their code and you can implement this yourself is, is is nice because, you know, that might also help other people like understand how to integrate into these services a little bit better. Mm-hmm. So, I, I definitely see a value there.

Nic: I, I, I can see there being a few different levels there, right?

The, the number of connections, the volume of those connections, and then the complexity of those connections, right? Mm-hmm. Things, things like Facebook's API, you know, they, they, you have to update those. Social media APIs have to be updated frequently to work, right? And so they take more effort. It makes sense for something like that to cost a little bit more.

But let's, let's kind of change gears here for a second because we've been talking about NAN and I'm not sure if our listeners are aware, but there was a the last week or so, I think there was some, some very severe security issues that were released by NAN. I think there were three in total.

Two of them were 10.0 critical score which is. As I understand it, the highest it can be. They were also very serious 'cause they were you know, a remote code, execution and arbitrary file. Right. Errors or gaps. So when when somebody is thinking about adding and not orchestration itself, let's be clear, like this is about what you're orchestrating with more than it is orchestration directly.

When you're thinking about adding a layer to orchestration, like NAN or Active Pieces or Zapier what are the security considerations, Jurgen, do you think that you would recommend people take? Like how do you approach that versus a, you know, a standard module or evaluation or something?

Jurgen: Well. I think the main thing that needs to be done in general, not only in the orchestration space, is to create awareness.

Awareness of the attack vector that we're all facing, knowingly or unintentionally. The latter probably more often than we like. I think in general we are more and more living in a world where systems are working in a collaborative way. And as soon as I give other systems access to my own, and with orchestration, we give external platforms access to a Drupal site.

And the Drupal site can contain sensitive data. So first of all, users of the orchestration module need to be aware that this is happening and they need to understand what is the access level. The external platform has on the Drupal data, and for what we've done with active pieces is that we base that on a user authentication.

So in the Drupal site, you can create a user account, which is just there for the external platform. And then you can assign roles and permissions to that active pieces user if you like, and you can make sure this is the only thing that they can do if they access your Drupal site. That doesn't mean that other stuff that you probably configured on the active pieces side or the innate end side are not at risk.

But that has nothing to do with our orchestration part in Drupal. Yeah. So I think we need to make. People aware that yes, it comes with a risk if you let systems talk to each other. I think people are currently learning that in the AI space currently a lot that AI agents do have permissions and a lot of that is currently trust based.

That's if you have a, let's say, cloud code running on your desktop, then it doesn't actually read all your private files that lie somewhere around and share the content with somebody else. We don't think they do that, but we don't know. Yeah, and the same thing now happens with integrated systems. We have to make sure that we have guardrails to, to be able to control what those other systems can and cannot do.

John: So I'm gonna ask the question. I think I already know the answer, but I'm gonna ask it anyway. And, and I guess I'll ask both of you this, but I mean, do you think that a closed source system in this regard, at least for orchestration, might be, might be a more secure or better, easier to secure than an open source?

Nic: 100000%? No. Like absolutely not. Security is not obscurity, is not security.

John: Okay.

Nic: The truth is we've seen over and over and over again that closed source systems are incentivized to cover things up rather than fix them. Open source systems, you know, transparency. One of the reasons why I love Drupal is the security team and the fact that it's open, it's open about the process, right?

That things could be improved always. But the fact that I can look at the code myself, somebody else can look at the code, that there's a security team. Hundred percent better than.

John: So, before you get too, too far up on your, your rightfully so soapbox I guess my point was more like, does having the ability to have anybody look at the code and, and incentives aside, like, obviously companies don't wanna say like, oh, I have a security problem, right?

Like, but like, does having the integrations be so widely available pose an enhanced or more of a security risk?

Nic: Well, before we answer that, let, let's give Jurgen a chance to answer the first question, right? Is, is having something closed source more inherently secure? Right.

Jurgen: No, I couldn't agree more to what to what you said, whether it's a thousand or 2000%.

No, it's not. It's funny to see how still CIOs seem to have confidence in proprietary software because they pay for it and therefore by definition they assume it's secure, but it isn't. And we all know that. Yeah. And I really wanna, you know, shout out to the security team in Drupal like you did before.

We do have an exceptional concept and the team on how to handle things like that. And we more and more get shout outs from the outside Drupal world as well, where analysts are looking at our processes and saying, this is an. Way on how software products and communities are doing this and lots of, or more and more people wish that we Drupal become an example for others to follow and do it similar way.

Nic: And to, to answer your other question, John, I think Jurgen's earlier point is one of those things like you, you can, if you have cloud code running on your machine, right? He, he said you don't know if they're looking at other files. You can, you can try to test that directly, right? You can try to see if something's being read.

You can try to see what's being sent. But if you have the, if it's open source, if you have the source code, you can just look at what they're doing, right? You can look at how, you know, how do they determine if, like maybe it's not even intentional, maybe they are reading other files that they're not supposed to be, maybe it's not even intentional.

Maybe just their scanning tool is too aggressive or there's an update right? If there's if there's transparency, you have the opportunity to audit yourself. Again, not everybody does. And, and even a case like Drupal, like Drupal's too big of a project to audit every single piece of it. Right. And yes, there is some risk because it's open source.

That means bad actors can scan it themselves and find zero days. Right. But every day I will put more trust in an open source project. Being pa that's the other thing too. If you, if there happens to be a security hole and it doesn't get fixed by the project, it's open source, guess what? You can clone it, you can fix it, and you can start a fork.

Right?

John: Right.

Nic: If it's closed source, you can't, you, I mean, you just can't, you, you have no opportunity to close the security hole yourself.

John: Yeah. I, I mean, like, I don't. I don't disagree with any of that. And I, I value the open source, you know, community and the fact that that that open source, you know, especially Drupal has a security team.

But I guess my point was more looking at the fact that like, all of these integrations are essentially somebody else's code base, right? And if they're open, right, then a bad actor can go look at them and go, oh, all right, let me try to figure out how to, how to infiltrate this. Right. I don't know. I don't know if, if I, I guess that's, that's, you know, if a bad actor can go look at it and figure out how to infiltrate it, maybe a, maybe a, a a good actor is doing the exact same and, and will develop a, a fix or, or, or some sort of enhanced integration to, to prevent, to prevent a bad actor.

But anyway,

Jurgen: I was just curious. I would, I would like to add that I, there is an important component that we put trust into contributors to software developers, but that's the same in open source as it is with proprietary software.

John: Mm-hmm.

Jurgen: And all the big software companies, one of their biggest challenges in that regard is to determine if one of their employees who has access to the code and can commit is actually.

The, that they and their clients put into them, the risk for them is just as big as it's for open source project.

John: Mm-hmm. Yeah, that's a great point. Okay, the last two questions here as we get ready to wrap this show up focus back on the orchestration module itself. It's new, it's, you know, actively being, being worked on and thought about.

I'm wondering what is currently on the roadmap? Like what is the next, I don't know, three to six months look like for orchestration? If I only could tell,

Jurgen: to be very honest, you know, we do not yet have a strategy for that initiative, which is not an official association here. Like we mentioned the AI initiative before.

Which has done a great deal in consolidating all the individual efforts into a consolidated and coordinated effort with funding, with a team, with project managers, product owners, and so on and so forth. We don't have that for orchestration yet. We're in a very early phase where we wanna find out what are the use cases, or in other words, what is the need that potential users of orchestration actually have.

What we're talking about today is more or less assumptions and or our own experience.

And that's what we are working on. Finding out what is the real problem space and write it down, and then find ways on how we can address that and how we can move forward in the best possible way. And the outcome of that will then be a roadmap. Then we can lay out what needs to be done to get there.

Nic: Yeah.

Jurgen: But we are still in that phase where we need that specification, the discussions, the research on what do users actually need and put the user in the center of it. Not what can we do, but what do the users that potentially pay for that actually need.

John: So two, two questions on that. One. Are you in contact?

You know, I'm, I'm assuming that theres, knows people at Active Pieces being a, being a, you know, an investor. So are, are people, are you talking to people at Active Pieces and Zapier and N eight n to, to kind of understand what their users are looking for and how their users are kind of interacting with their, their web, web products?

Jurgen: I'm not aware of such discussions, to be honest. I'm not having them myself. I'm sure Greece does. What we are actually focusing more on, it's not like technology providers, which we ourselves are technology providers as well. We would rather like to talk to the existing or potential clients that are Drupal agencies are having.

What would they wanna be doing if they only could, and we assume that we get more out of them, rather than just replicating what others like active pieces or NANN have already done.

John: Okay. I, I, I don't know. I, we could, we could, we could debate that, I think, but like, I don't know, Zapier Zapier's made a pretty good, pretty good business on, on building out orchestration frameworks, so I imagine they have a pretty good idea of what people are, are looking for. And I know we wanna kind of focus it more on what Drupal people are looking for.

But I don't know. It feel this feels like a good way, the good way we could get off the island and, and learn from folks outside of, outside of our space. Yeah, absolutely.

Jurgen: I, I didn't wanna mean, I didn't wanna say that we shouldn't learn from experience that others have already made, but personally, I also think there is no point in Drupal trying to compete with either of them.

Sure. Yeah. So I think it's, it's worth thinking about is there a unique. That we as a Drupal community and project have, that we can combine existing things and be creative and invent new opportunities to actually create new business models for lots of people. I, I don't think becoming the next SPI is a hard Yeah.

Hard deal. Right? That's not what we want.

John: Yeah. I mean, I don't, I don't think that that, that I agree with you there. That does not make sense. Right, because like, that's not, that's not. Are, are, that's not where we're, what we're good at, right? But I do think from, like from an enterprise standpoint, if we look past the Drupal agencies and like, and like go up to the enterprise, right?

Enterprise is integrating into a bunch of different systems, right? Enterprise wants an easy way to get data out of Drupal and integrate it into other, other, other services, other systems, right? Mm-hmm. So, you know, for me, orchestration makes a ton of sense. I don't know that we necessarily, as a community, need to focus.

Hyper focus on like unique use cases. I think it, it makes more sense for us to focus on a lot of what we talked about here today, right? And making that as seamless as possible and giving people the flexibility to choose who's doing the orchestration and then bring that back to what Nick's, Nick's point was that like, Hey, maybe you wanna back up or, or move your, your, your orchestration to a, to an open source sort of way.

So, I mean, yeah, I think like I, I think like were probably saying a lot of the same things just in different ways. The second question I had was, you referenced the AI initiative and the fact that you know, maybe folks don't know this, but the AI initiative has AI makers, they have, funding there, putting out RFPs.

Is your goal to kind of make orchestration follow that same sort of of template? Do you think it'll get to the point where there are orchestration, you know, makers and, and, and sponsorship and that sort of

Jurgen: sort thing? I would hope that we could get to that point. Yes. What we need for that is make us like, you know, it feels like since threes announced the orchestration idea in Vienna, there is a lot of excitement around and we had great discussions like the one we just have here on talking Drupal, but we're not yet at the point where people come up and say, well, that's great.

I would like to allocate, three full-time engineers to that project and make it move forward and faster. But we would like to get there, but we don't feel the pressure to actually push hard to get that, you know, established by, let's say, March 26. We feel very comfortable in the idea to say, look, this is, we feel that this is an opportunity and we would like to get the engagement from as many people as possible.

And then together find out how we wanna turn that into an initiative, which is like what AI has already accomplished.

John: Okay. Interesting.

Nic: So if people are interested in helping with a lot of these. Sub pieces of the orchestration initiative, they wanna maybe help build out the use cases. They maybe wanna just assist with reso, you know, developer resources, something else.

What's the best way people can get involved and, and help?

Jurgen: Well, if people just wanna talk, ask questions, or bring up ideas, I'm always happy to answer direct messages on Slack or any of the other channels. If there is something you would like to discuss in a team there is this orchestration channel on Drupal Slack, and if somebody is more interested in actually getting their hands on with this stuff on a technical basis than there is the issue queue for the orchestration module where we already have a handful of issues where integrations can be started with other platforms that we haven't done yet.

And some of the integrations are already underway, so those maintainers are certainly happy to get some help as well. Or if you have new ideas, just open new issues there and get the ball rolling.

Nic: Awesome. Well, Jurgen, thank you for joining us. It's always a pleasure to have you on to talk about all the things you're working on.

Jurgen: Yeah, great. I enjoyed it a lot.

John: Thanks

Jurgen: for it.

John: Do you have questions or feedback? Reach out to talking Drupal on the socials with the handle Talking Drupal or by email with [email protected].

You can connect with our hosts and other listeners on Drupal Slack in the Talking Drupal channel.

Nic: If you want to be a guest on Talking Drupal or a new show, TD Cafe, you can click on the guest request button in cyber at talking drupal do com.

John: You can promote your Drupal community event on Talking Drupal.

Learn [email protected] slash td promo.

Nic: And you can get the Talking Drupal newsletter. To learn more about our guest host, show news, upcoming shows, and much more, I sign up for the [email protected] slash newsletter.

John: And thank you patrons for supporting talking Drupal. Your support is greatly appreciated.

You can learn more about becoming a [email protected] and choosing to become a patron button in the sidebar.

Nic: Alright, Jurgen, if Fire the listeners wanted to get in touch with you, what's the best way for them to do that?

Jurgen: You can find me on drupal org or Drupal Slack, or most of the social platforms that are free like Mastodon with the handle.

Jurgen has J-U-R-G-N-H double A S.

Nic: And John,

John: how about you? You can find me personally at picozzi.com on all of the socials and drupal.org at John Picozzi. And you can find out about epam at epam.com

Nic: And you can find me online pretty much everywhere at Nicxvan NI cx VAN.

John: And if you've enjoyed listening,

Nic: we've enjoyed

John: talking.

I'm gonna keep trying. Have a good one. Everyone.

Nic: Have a good one. See you next week.