How to Move from Task Automation to Service Orchestration

Good day, and welcome to the IEEE Computer Society's presentation on top twenty twenty one IT automation trends, Moving from Task Automation to Service Orchestration. This webinar is proudly sponsored by Stonebranch. Now I would like to introduce our speakers. Colin Cocksedge is Director of Product Management at Stonebranch. Colin joined Stonebranch in 2000. Since then, he has held various positions within the company's technical organization from the presales and technical services departments to product management. Today, he is responsible for directing product strategy with a strong focus on maximizing business value of the Stonebranch software portfolio in the field of workload automation. Scott Davis is Vice President of Global Marketing at Stonebranch with nineteen years of experience in software technology industry. Scott's tour of duty has included such well known global technology brands as SAP and Clario. At Stonebranch, Scott is responsible for the Stonebranch global brand, product marketing, corporate communications and demand generation. Scott is a thought leader on the topics of marketing technology, BI analytics, and IT automation, and has been invited to speak at various industry events, including SiriusDecisions Technology Exchange. Ladies and gentlemen, Scott Davis. Thanks a lot, Amir. And I'll just give a welcome to everybody out there. We really appreciate you joining. We've got a fairly global audience. So I'm excited to get started. For today, we're going to really start off with sort of an overall market view, that will include the evolution that's happening and we're sort of in the middle of right now, as well as identifying a number of trends as they relate to IT automation and in larger category of IT orchestration. Then we're gonna dive into, exactly what a service orchestration automation platform is, which will be a big part of the presentation, upon which we will then go into very specific, use cases that are evolving and are being adopted by enterprises, that are using service orchestration automation platforms today. So with that said, I say we dive in, and talk about the market evolution. There's a number of trends here that, are worth mentioning. I won't read each bullet, but in general, the shift to the cloud is one of the biggest drivers, and we'll talk more about it on the next slide as well. But in essence, you know, a lot of companies, many of the people that are on this this call today are trying to operate in a what we call a hybrid environment, which has a mix of on prem, whether it's mainframe or distributed servers, and then cloud platforms and cloud applications. And so this creates an enormous amount of complexity that enterprises are having to deal with today. There's a huge demand for new functionality in automation. This includes containers. This includes, deeper analytics to help be predictive or go deeper into root causing issues. And there's a number of, audiences that have joined the automation world in terms of what they need to get their jobs done. One of those is is DevOps, and DevOps in particular is putting a lot of pressure on IT ops teams. The next few are are important, but I'm gonna fly through them a little bit quicker. There's a need to centralize the automation, of course, because of the shift across hybrid environments. There are new business users that are demanding, you know, increased access and faster speeds, which all line back to automation. And then, of course, there's an aging workforce. People who have written scripts or worked on the mainframe or older distributed servers that that are getting ready to retire. And so enterprises are trying to figure out how do we keep those things going, without having to try to find people that, write legacy code or work on these legacy applications. So when you think about it, these these things that I just talked about, these trends, can kind of be broken up into two main market shifts. The first, of course, is the on prem to cloud shift, and it's, you know, even more aptly named, you know, that infrastructure shift. And the second is automation across the business. And if I think about sort of yesterday and even today for many businesses, the tools were were all on prem, you know, these automation tools. They were used on mainframe, distributed environments. They were used by IT ops people, to do IT ops things, right, to to make their lives easier. And the the terms you would hear talked about related to yesterday were traditionally job scheduling or workload automation, and it was very much a tool based approach. This shift that's happening that that companies that have moved to more of a broader use of IT automation and orchestration is it's happening because of this cloud piece and because of the the user focus. So, you know, outside of mainframe and distributed applications, people are using cloud, people are using edge. They're trying to orchestrate, you know, complex workflows that run across both or all three. And, you know, they're adding in, analytics and insights that they've, you know, candidly never had before. And if you look at sort of the bottom line of both categories here, yesterday was all about IT ops. Today and going forward, it's a whole new source of users, people who need automation. In addition to IT ops, it's DevOps, it's DataOps, it's PlatformOps, it's cloud architects. And, you know, outside of those users, it's business users, it's people that, you know, need access to automation to get their jobs done. So those two main market shifts can sort of be looked at on a graph like this. In the seventies, you know, all of the automation was batch processing. It was single file. You know, we look at that as the first wave of automation. As distributed moved into the limelight, it sort of transitioned them into what they call job scheduling. It was there there are many structured databases. You could move, on one system or automate another. And then we entered this virtualized environment in wave three, which, you know, that's really where workload automation came in. It was, you know, twenty fifteen ish. You know, there's some debate over the actual dates. But you start getting into unstructured data, structured data. You're doing most of your stuff still on premise, but cloud starts to be introduced. You start having some integrations with some major cloud providers, and, it's it's really where we've been for the last at least five years. Now, none of these things have gone away. People still do batch processing, still people still do job scheduling, and people still do workload automation. Sometimes they're all within one mega application or sometimes they're, individual applications on individual servers or individual areas. And so the bigger shift that's just happening now is this sort of hybrid IT environment and the introduction of service orchestration automation. So I'll talk a lot about hybrid IT and service orchestration automation platforms in particular over the next couple of slides, But the shift right now is is all about the cloud and the things we talked about just a few minutes ago. So in this wave four, let's unpack it a little bit. So there's a lot of definitions out there related to hybrid IT, or you'll hear hybrid cloud or you'll hear multi cloud. For the purpose of Stonebranch and working with us and and maybe even just putting a nice definition in place, this is where we'd like. So hybrid environment is made up of a mix of different infrastructure options. So you can have your on prem stuff like your mainframe or distributed servers. You can have a private cloud that's virtualized, and you can have a public cloud. You can have multiple public clouds, which would consist of a multi cloud environment. And then the one that gets confused the most is hybrid cloud versus hybrid IT. Hybrid IT is the is the environment. It's the methodology. It's the the strategy you take. Hybrid cloud is connecting, you know, your private cloud to your public cloud. You know, that's sort of the difference in the in the way that that, we think about it. And so, you know, this is incredibly important for all the reasons we talked about earlier. Enterprises have shifted. They're using a hybrid IT environment now, and that creates an enormous amount of complexity. And there's a real requirement to try to centralize the automation and really orchestrate it across all of these environments, whether it's on the platform that these environments or platforms within these environments or the applications that are running them. And that sort of takes us to SOAP. So service orchestration automation platforms. I'll be the first to say that I think SOAP as an acronym is confusing because it can be confused with other acronyms of the same thing that relate to other technologies, but it's something that Gartner coined. And I love the name of it when you spell it out. So service orchestration automation platforms really does well describe, what's going on. And so I think the most notable thing about SOAP is what Gartner says in this quote here. So I'm just gonna read it out loud. Through twenty twenty four, eighty percent of organizations using workload automation tools will switch to service orchestration automation platforms to orchestrate cloud workloads. It's a big number, in a market that's already really big. So Gartner came out with this report in, well, just about a year ago, April of twenty twenty. And it's the first time that they've created this category. And the way they would describe it would be to say, this is not a new market. This isn't a direct evolution from workload automation. So if you flip back, in your mind and think about the the graph that I showed that had all the circles on it, service orchestration encompasses workload automation as part of it, just like job scheduling is part of it, just like batch is part of it. And so largely driven by this this evolution of the cloud and everything we everything we talked about. The other thing about, SOAPs is that, a lot of the technologies that predated SOAP were time based. And the service orchestration automation platforms hinge on this concept of real time automation. So time based would be where, you set up a job or a batch to happen on Monday night so that it doesn't disrupt, computing power during the day, and you, you know, have a bunch of little tasks that all trigger at the same time. Real time is all done by events or system events. And so the second something happens in a file, it automatically updates someplace else. And so it's this idea of doing the automation as it needs to be done, not all batched up into one giant, you know, time based load. So, this gets you a lot closer to, delivering data in the moment. It gets you a lot closer to, having data you know, updated and rapidly available for business users and whoever else needs it. So within SOAP or service orchestration automation platforms, there's a number of, you know, hexagons that you can see here. I'm gonna talk through these on the next slide, and just try to explain what each one of them kind of represent. So in workflow orchestration, this is where you're actually creating, you know, the automation and orchestrating workloads across complex workloads, across multiple applications or platforms. And these application platforms can reside on premise or in the cloud. So what you'll find in a traditional SOAP application or SOAP platform is, you know, visual drag and drop capabilities, the ability to connect and integrate with lots of different solutions or applications out there. And, and this is where you're actually designing the way that the data flows or the way that the automation happens. Next on the list is this, event driven automation. This directly relates back to the real time aspect that I was mentioning on the previous slide. So, you're using event triggers that happen in real time, and you're delivering data or doing this automation when it needs to happen, not on a weekly basis. Next on the list is scheduling, monitoring, visibility, learning. And the way that Gartner talks about this is it's all about, adding great dashboards and reporting and predictive capabilities in the effort to improve SLAs. Self-service automation is really about empowering the business user or the developer or the data ops person. It's helping others outside of IT to have access to automation that can help them orchestrate their own job. And this takes a number of forms, some of which are very interesting and that we'll talk about as as we get in the Collins portion of the presentation today. Next on the list is resource provisioning. So this is really where you're managing on premise or cloud based compute network and storage resources. So as an example, in the cloud world, you might have something like an infrastructure as code where you're able to control spinning up a cloud instance and then taking it back down when the person is done. And so you can do that with modern STOP applications, and you can do it based on events or time or however you want to as part of your overall workflow. And then finally on this list, but certainly not the least important, maybe one of the more important pieces as we're moving into, you know, modern cloud applications and everything else, is this idea of managing data workflows. So, this is largely based off of file transfer. File transfer is by no means a new application or new to the world, but integrating file transfer, managed file transfer, into larger workflows like you would have seen with workload automation in order to orchestrate maybe a data pipeline and do that across, you know, your hybrid or your cloud or your on prem areas is, is a huge part of what we see in the market and what people are being interested in. So we kind of have the definitions around the areas of STOP. Let's be more specific. So workload automation has been around for, you know, five years. Jobs scheduling has been around longer. Batch has been running longer. So what we thought we'd do is we just try to create a real clear comparison between workload and service orchestration automation because it's easy to say, well, isn't this just a new name for something? And really, it's not. Right? It it's a true evolution in a product category. So starting at the top, workload automation really was around, it was primarily designed for efficient efficiency gains and and cost saving. You know, somebody who's selling or using, workload automation might be looking mostly at the cost savings, right, in time and and funding. Service orchestration, on the other hand, is more about driving digital innovation. You're gonna get your cost savings. You're gonna get some efficiency gains, of course, the same ones that you would have gotten with workload automation, only you're able to do a heck of a lot more with it. So this digital innovation, this business agility, and, ultimately, you're creating new revenue streams, is is where we see a lot of our customers and a lot of the enterprises going. Next on the list is workload automation. We talked about how it was traditionally focused on mainframe distributed, so now it's really for cloud native infrastructures. There was some cloud thrown in with workload automation as you got some integrations, but a true service orchestration automation engine is able to integrate with and connect to any application within your within your business. Next on the list is a focus on automating jobs, and I'll be very specific here. There is a difference between automating and moving over to the right where you're looking at orchestration. Automation is, you know, you're you're doing a number of repetitive tasks on your own. Orchestration is doing those same tasks, but across, five different places or ten different places. You're you're creating a workflow that has, if then statements and, requires much more complexity. And, of course, again, goes across your entire environment, not just one mainframe or one distributed set of servers or whatever. Right? So, next on the list, we have this end user concept. We like to think of workload automation as the, you know, the IT ops people were using for end users in workload. Really, what you're seeing now is what we're calling citizen automators. So you're seeing people across the business, all the lines of business I talked about, all the business users taking automation and orchestrating their own jobs and own workflows with service orchestration automation. Workload automation is filled with basic reporting, some basic monitoring, some system alerts when something goes wrong. Service orchestration gives you forward looking analytics, and it helps you find problems before they happen. And, ultimately, it also goes into more in-depth ROI reporting. So you can go back to your boss or your boss's boss and say, see all this automation and orchestration we just did? Here's how much it saved us, this year or this month or this week. Right? And so it has more real time analytic capabilities that allow you to drill in and get rich information that can be used to drive decisions across the business. And, finally, on this list, in workload automation, you're really focused on IT op, and there's some DevOps adoption. Right? Some developers are going in and using it. Developers oftentimes are using it to help the IT ops people create workflows, and maybe some DevOps people have access. But in service orchestration and automation platforms, the platform itself is used as a way to bridge the gap between IT ops and developers to help create and mature a full DevOps methodology. And so what you see on the left and the right are are very different things. Right? And, much more capability in a service orchestration automation solution, much more adoption across the rest of the business. At this point, I'm gonna turn it over to Colin. He'll have a good, more in-depth technical conversation with you now that we've gone through sort of the history and the evolution. So Colin, why don't you jump in? Great. Thanks, Scott. That's a nice overview of, what I think, everyone's witnessing in the market. So what I'm going to talk about now is more of a deep dive into the needs and attributes for an orchestration strategy to to help manage the environments as they're evolving. All of these different services and platforms that we're now seeing, you know, spread across all the different environments that we have. And we'll find that service orchestration platforms have many attributes and capabilities, and and Scott's talked at a high level about some of those. But one of the key needs, I think, for service orchestration is the ability for your automation to integrate. So so kinda let's start with that. If we take a look at the different areas where service orchestration plays, effectively, what we're looking at is all of the components of today's hybrid IT landscape. You know? So your applications, they're no longer pinned to your on premise infrastructure, And many of those are deployed in the cloud. And more and more business applications are consumed as a service. You know, it's something that we're seeing across across the whole business. And when we look at, you know, the the cloud and and how you're deployed there, I mean, who has just one service provider for their cloud? Multi cloud strategies are very much the norm these days. And then we look at business intelligence, big data analytics processes, which are very key IT services that help drive innovation, competitive advantage for the businesses that that you support. And also DevOps, it's it's ubiquitous strategy now for fostering faster delivery of applications and services. And a lot of people are dipping their toes into robotic process automation, which really allows the automation of of many manual human actions, which increases or helps increase the reach of automation too. And also then lastly, much of our infrastructure has become an on demand resource. When we look at containerization and so on, it's encapsulated as code, it's very transient in nature. So we also have to be able to be cognizant and manage that. But the point here is that each one of these areas is not a single application or entity that can be simply automated and managed. In a large part, they're they're nearly always a collection of tools, technologies, and services that are often managed by their own discrete teams. And the other dynamic here is that many of these discrete tools and services offer their own automation capabilities. And those teams that are responsible for managing their configuration operation usually are far more comfortable using the native capabilities for automation. But this leads to a siloed approach to operations that can defeat the benefits that some of these technologies help to bring to bear. So hence, the emergence of the service orchestration automation platform, which is there not only to deliver the capabilities direct to directly automate these applications, tools, services, etcetera, but can also orchestrate any built in automation capabilities that those tools and services may have. But why why is that important? So kind of let's talk talk that through. If we don't consider automation as a strategy for the whole, we tend towards what what we've seen termed as random acts of automation that only have benefits for the parts. Orchestration really is where you bring together an order and cohesiveness to that randomness. So in order to successfully orchestrate, job one for SOAP, I think, is to integrate with the whole, hybrid IT landscape. And if we look across all of the different things that we have in jobs and workloads, cloud, and infrastructure as a service, and DevOps, You see some examples here of some of the different tools that are out there. And in each one of these buckets, companies are not just using one tool to manage the whole. They're using groups of these tools that they put together in tool chains to manage those environments. And this is really what service orchestration needs to do. It needs to be able to manage all of these different tools and applications. So so far, I've stressed the importance of downstream integrations. In other words, those integrations, what we're managing downstream from the service orchestration platform. But there's another flavor of integration that's actually just as critical for a service orchestration strategy, and that's upstream integrations. There's very much a shift towards decentralized access to automation capabilities as a consequence of the broader movement of democratization of IT. Democratization has created a new breed of, as Scott mentioned, citizen automators who are developers, data analysts, business users, and the like whose productivity is increased by getting direct access to technology, technical capabilities, the bit and this benefits the business by leveraging business domain knowledge that they have and allowing the users to create and execute on their own ideas. In fact, a recent survey that we've seen from enterprise management associates shows that some forty percent of organizations have a decentralized automation function versus other organizations then who manage all or most of their automation centrally. So it's definitely a growing trend there. And what the downstream integrations give you is quite simply or the upstream integrations is quite simply exposing automation services to the citizen automators within applications they may already be using, such as service catalogs, team chat applications, Slack, Teams, ServiceNow would be another example of that. And that really allows them to basically, within tools that they're already using to do their job, to get access to the automation. And you can build approval processes into that. It could be as simple as just having simple kicking off workflows, getting results and analytics back. The integrations can be as deep as you need them to be. So the application and possibilities of service orchestration automation platforms are pretty much endless, but we can take a quick look at a couple of specific examples about how these technologies are being leveraged in the real world. So when we look at big data and the data ops processing, it involves a series of steps and the steps subtly different from application to application, but in a broad sense, the categories of collecting data, ingesting that data, preparing that data, computing that data, presenting that data from the diverse sources to support the business intelligence and analytics tools that the business needs to get their results out of it. And of course, as with all of these different areas, there are many different commercial and open source tools that are being widely used and leveraged at each stage at this type of processing. So if the pipeline isn't orchestrated from end to end, then you're going to run into problems with things like problem diagnosis and resolution, which becomes time consuming, fraught with those finger pointing meetings where, well, it's not my problem. My part of the application went through. So basically, the deal is that what the service orchestration gives you is a top level view of all of the different processes, parts of this process, and all of the different tools underneath that process, which gives you basically the proactive alerting, quick root cause analysis, better governance, and accuracy of processing. And to illustrate that need, we can look at a real world workflow of a data pipeline. And you can kind of see all of the different activities involved in sourcing that data from the different sorts, whether it's databases, whether it's applications, whether they're just coming as files, whatever, through to then doing the ingestion preparation computation and pushing that data out at the end to the applications that the business is using for their decision support there. And you can build things into this like manual approvals if that's what's needed or they can be automated through that. But the point here is that as you work through this workflow, if you get delays or errors or problems, they're highlighted and you know which part of the application has caused the problem, you know which team has to be involved to solve the issue. It's not a case of, well, the business didn't get their data, so we then have to track back where does that data come from, what was the previous step, and so on and so forth. So this hopefully illustrates the power of service orchestration to really bring that all together. And it also illustrates the fact that the service orchestration tools need to have the integrations to whatever application it is that you need to do to run your business. And even within the same business for similar processes, you'll find that teams are using different tools based on preference or availability of what they need to do that task. So similarly, it's really very much similar with the DevOps CICD tool chains. They can be just as complex and, again, involve a mix of open source and commercial tools. And in fact, from my personal experience, I find that even within the same organization, different teams have subtly different practices and tool sets involved around their DevOps process. But basically, DevOps processes also the concepts also tightly link the infrastructure in terms of infrastructure as code, that concept to delivery of applications at each point in the life cycle. And with the democratization of IT, the developer citizen automators are concerned with delivering updates to their application automation along with the application updates themselves. I mean there is that they're more and more responsible, not just for the application code, but for all of the pieces around it, such as the automation for the various components you're using to automate or even the service orchestration itself in terms of looking at that. So basically, the service orchestration platform needs to expose its own capabilities as code so that those can be incorporated into the DevOps life cycle. And this is referred to as a jobs as code, similar to infrastructure as code, jobs as code. Right? So where my application runs, how it runs, how I automate it are all pieces that are part of the application code set that are managed through that CICD tool chain. So despite our best efforts to modernize applications to take advantage of technological advances such as cloud and microservice, there is and may always be legacy applications that remain mission critical. And as we move to the world of hybrid IT, a key challenge that organizations that we've dealt with are facing that they need to overcome is managing the seamless and automatic integration of data between increasingly diverse environments. This is presenting new challenges for the businesses that can be solved with service orchestration technologies, connecting and managing on premise and cloud platforms and applications, securely sending data between on premise and cloud environments and between different cloud providers. And bear in mind, we're now sending data that used to live solely on premise to and from cloud resources that are outside of the data center. So we need to make sure that we're not compromising on security in those cases as well. And of course, we need to perform these actions in real time while maintaining control and visibility of the increasingly diverse mix of platforms and solutions that they have deployed. And often cloud resources are containerized or transient in nature, so traditional static scheduling definitions are not very suitable to service orchestration needs as we need to recognize and dynamically adapt to the infrastructure as it's scaled up or scaled down. Kind of as an example on that, as an early adopter of hybrid IT, the AXA organization, AXA Insurance Global, were also an early adopter of service orchestration automation to help them quickly adapt, roll out, scale their hybrid IT operations. And AXA should need no introduction. They're the second largest insurance concern on the planet, operating in some fifty seven different countries with a very diverse portfolio of insurance services. AXA partnered with StoneBranch very early in the design phases for their hybrid IT adoption. And by taking this proactive approach of making orchestration automation of this new landscape a priority for delivering their world beating insurance services, they've been able to realize the cost savings much more quickly of modernizing their applications and moving to that hybrid IT approach and consolidating their platform approach. They have a global strategy for orchestrating and automating this new environment. And they've solved a lot of significant issues they had early on with managing their data pipeline across on premise cloud platforms and applications with robust and secure solutions for legacy and cloud data integration with a single solution across your IBM mainframes, on premise legacy Linux, Amazon Web Services and Azure cloud environments. And a lot of their work is also running in the Red Hat OpenShift container management where they get their Kubernetes environment that they're using to manage all of that spinning up and spinning down of resources on demand. And as we wrap up today's presentation, just a couple of slides on the solutions here StoneBranch, and then we'll get into a of a summary and a Q and A. So in a nutshell, the Universal Automation Center platform hopefully does what it says on the tin. Right? Provides the key capabilities to orchestrate all of your IT processes from on premise to private cloud, public cloud, multi cloud, hybrid cloud, hybrid IT, etcetera. So, you know, the the components are the workflow orchestration engine, which provides the visual design where you just drag and drop elements you need to connect the dots between the different applications and platforms. Once designed, the orchestration workflows can be tied to any number of different types of dynamic event triggers. We'll talk a little bit more about those as we go through. And your citizen automators get to be able to manage their own orchestration needs via the upstream integrations, self -service capabilities, or, you know, if they're developers, they may just wanna call APIs to do that. And let's not forget the infrastructure. That needs to be orchestrated too, you know, with support for creating, starting, stopping, decommissioning, monitoring, all of the different infrastructure components, whichever cloud vendor you're using, whatever flavor of container management you're using in terms of being able to support all of those things. And for data pipelines, we mentioned this is a lot about file transfer. We're not necessarily new and exciting technology, but you do need secure, reliable governance around that file transfer technology. And it's there providing a complement to the workflow orchestration capabilities so that you can manage those data pipeline workflows as well. And, of course, you know, a command center for monitoring, analysis, alerting, and service level management. And within that platform, there are a number of key solution areas for jobs and workloads, encapsulating all of the automation tasks you need for joining the dots with workflows that allow seamless automation across the hybrid IT environments. Cloud, a key decision factor for for many companies is the ability to manage all of the flavors of hybrid IT from a single console. DevOps automating the CI/CD pipeline. But within UAC and your broader ops, DevOps tool chain, being able to make use of all the third party source control systems, jobs as code, etcetera, etcetera. Right? So the big data centralizing and automating the jobs required to support your end to end data processes and the hybrid file transfer combining, basically allowing you to use event trigger based approach for all of that transient infrastructure, make sure the data gets moved in and out as and when it's needed based on its dynamic nature. File transfer plays a key role in supporting an evolution to the cloud and keeping data in sync between disparate systems. So with that said, let's open up for questions. Scott, I think you have some information to share here. Yeah. Thanks, Colin. Appreciate it. And please do feel free to ask any questions in the chat. I'll read through them, and Colin will answer them, and I'll jump in where I can. At the same time, a few special notes. So, you know, we talked a lot about service orchestration automation platforms. There's a market guide that Gartner released last year, and that market guide is available via download in your resource center. So feel free to grab it, read it over. It goes even deeper than what we talked about here, and you can get a real, flavor for where it fits in your business. Also, there is a survey link in the in the resource center as well. We'd love to hear from you. Tell us if this was helpful, how we can improve, and, you know, any any feedback is much appreciated. So as we get started on the q and a, Colin, I see the questions lining up here. I'm gonna start with with one here. This is from Debbie, and she says, give me a sec. You talked about event based triggers for real time automation. Can you give some examples of what these are and how they should be used? So, yeah, I talked about the the event versus time based. Colin, can you give us a few examples of what an event based trigger might be? Sure. Sure. You know, as Scott said, you know, traditional scheduling is very much time based. You set up schedules and, you know, dependencies and all that good stuff. You know, event based really can be anything. So, you know, some simple examples would be the availability of data. So, you know, files coming in from business partners perhaps or, data that's changing in a database or, an application that's issuing a message or maybe the service orchestration is subscribing to a message queue from, you know, some kind of message broker, and is taking that information to to do something, from that point of view. So it's really any kind of event you have in the system. It could be that, the event is that a specific Kubernetes pod has been spun up. In other words, an application's, you know, been scaled up and we've got some extra resources available that in itself could be an event. And that could either trigger some activity maybe to provision some data or, you know, it it triggers the SOAP in order to be aware of those extra resources in terms of planning its resource load across an application that's been containerized. There are probably some other examples I haven't covered there, but maybe that gives you a broad example of the kind of things that we can talk about. Okay, great. Thanks, Colin. I have a question from Swamy, and he's asking I'll just read it. So the automation argument's very clear. How does SOAP handle constraints, consistency across the different parts of the organization? And he says, e. G, governance related criteria that apply globally. Well, constraints, consistency and governance could mean a lot of different things there. So inherently the is going to give you some form of governance, right? Because a, it provides a central audit trail for everything that's running. It provides a central security model for exposing those services to, if we're looking at system automated community from that point of view. When you get into consistency, if we're talking about things like where things run, how things run, that's potentially application specific, may be defined into the workflow in terms of that. So I've kind of tried to approach that question from two different sides and hopefully answered some of the question partially there. Great, thanks. And if you have a follow-up question, Swamy, just go ahead and ask, and I'll see if I can get to it. Okay? Next one is from John. He says or asks, are the managed file transfer integrations mentioned for internal transfers among different systems, or can they also host connections for external transfers as well? Yes and yes. So, I mean, when we're talking about, you know, managed file transfer and the need for for data pipeline, you know, the sources destinations can be anywhere, right? Internal to the data center within your private cloud, public cloud, but also your business partners, your trading partners, etcetera, that you have. So the solution certainly in terms of what you need to look at needs to be able to cater for all of the above based on your needs. And the protocols that are used will very much depend on who we're talking to, whether we're going over private networks, public networks, and so on and so forth. I mean, there are solutions within our solution for managing all of those as well as streaming data between different cloud providers and HDFS file systems, external partners using a number of different protocols, including some of the sort of industry specific protocols like AS2 and OFTP and so on, but as well as supporting the standard SFTP, etcetera. We also have some file transfer protocols that are based on our agent technology, which provide a very reliable, secure method for transferring that data. Generally, that's used internally but can be used externally. It just requires our software at both ends. So you have the choice of open protocols or proprietary protocols depending on your needs. Great. Thanks, Colin. It was a very long wait to say yes, wasn't it? But I think it answered the question, right? So next on the list is from Len. Len asks, It would seem to introduce a lot of risk if not done correctly. Have you compiled any best practices to move in that direction? And, Colin, I would just add here that I think this has a lot to do with our business services, right? Sure. I mean, this comes down to what services are you exposing. I would say with citizen automators, you're generally not giving them a soap tool and saying, have at it. Okay? You have some some predefined services depending on, you know, the users, you know, in the development world, you know, you've got, so we say, little more advanced users. They're gonna do more stuff. But, the tools have security in them to allow you to restrict who can do what. And in terms of the citizen automators, it's really they have certain tasks that they need to do. You give them access to do that on demand. It's secured. You can build approvals into that process if you need to. It's really about thinking about what the goals are and who the users are because even within citizen automators, there are different, I would say, classes of users. Probably the best practice is to start small and then build it up. And also make some decisions early on about how you're going to expose these services. Do you give them the SOAP tool interface itself? Do you take some upstream integrations? Do you have your own service catalog where, okay, we're going to build something using some APIs in order to get that stuff into there? I think it's like anything in terms of giving stuff out. I'm not sure it necessarily induces a lot of risk, but you do need to think about it and take it step by step. Great. And Glenn, I would also just take a moment to point you to recorded on demand webcast we did with United Fire Group during Stone Branch online, which was our big, virtual user event last year. They had a whole session about this topic and how they approached, using the business services or the pieces to make automation for any number of businesses within their organization. So they had people all the way at the business user level, like finance and HR using it, all the way through developers and and more complex people, and, you know, gave them different access rights across the across the path. Len, if you care to just follow-up, and we'll be happy to share that out to you. Let me see here. Me look at the questions, make sure I get the ones that people care about most. There's a more commercial question here that I have from Praveen. Could you please explain the license model, and does this support migration of scheduling definitions from other tools like IBM workload scheduler control maps? So I can take part of that, Colin, if you wanna jump on, feel free to. So, we have very flexible license model. We do task based, which is, you know, sort of consumption based. We do a subscription based, and, we even have, you know, other models that fit in between. Right? So, first part of that is flexibility. Right? The second part is the conversion piece. So, you know, this this whole market really is based on conversion. I talked about eighty percent of people going from workload to SOAP and even from workload to workload over the decades here. And, the answer is yes, absolutely. We have automated tools to help move schedules and workflows and definitions over, and we do that with the tools that you asked about every day. So, Colin, anything to add there? No. I think that covers it. I have an interesting question that I think I have an answer for, but I'll let you take a crack at it, Colin. This one's from Lars. He said, how can a startup start with SOAP? I can take a crack at it if You take a crack at it when I think about Lars, A lot of times you see enterprises gravitating towards the SOAP, but we have customers that are small businesses, and they needed the kind of automation and orchestration that we do because they're business dependent on it. Right? And in those cases, typically, they'll lean more towards, you know, if you think back to the commercial discussion we had a moment ago, more towards the task based side of things. It makes more sense for them to be task based. They can start small and grow into what they need to as they continue to grow. So the answer is yes. Absolutely. Give us a call if if you wanna check it out, and we can see if we can work something out that makes sense for you. Alright? I guess the only thing to add to that, and and that's actually a good answer is is that, you know, one of the services we offer is offering this as a service. Right? So effectively, you know, depending, you know, start up implies that you may not have a a large sort of, you know, automation IT team. It depends on the kind of start up. Right? So effectively then, you know, we we run the service for you. I mean, you configure your automation, you run your automation. But as far as the application itself goes, it's basically just software as a service. So that might be an option that kind of helps with that. You don't have to have an infrastructure in place to run and manage the tool itself. Got it. Yeah. Thanks. Quick quick answer to a quick question. You know, will we share the copy of the deck along? And, absolutely, this will come out. It sounds like the maybe the icon in the resources tab isn't working, is what, Michael has shared with me. So for anybody that's on, this will come out on demand as well as this soap Gartner paper tomorrow, I think, is what what computer hour told me, in an email, you can download it there. Or it's available on our website, whichever you'd like to do. And maybe my colleagues from computer dot org can just drop a quick link in in chat or something like that to push it out to you guys if, if it's not work or if they can get it to work. Let me just read this here. Okay. I got a longer one. Gotta see if I can skip through it, but this one's from Robert. And, Colin, this will be for you for sure. But where do tools like this come into play when it comes to determining where to run the workload? Are you making the best decision based on cost resource, running the cloud one day, on prem in the next? He says we're seeing an increased demand for this to control costs. Right. And that's a very, very good question. When people always say that's a very, very good question when they don't have a very, very good answer. Right? But we'll take a crack at it. So yeah, that's a big and up and coming issue, which I don't think any of the vendors have really solved as such. However, there are some techniques around within the automation center, Universal Automation Center, can help with that. So if your applications are being spun up in the cloud or on premise based on criteria that you're managing elsewhere, we just take advantage of that, which means that the workload runs. So particularly if you're looking at containerized applications, right, in terms of where they're being running based on cost and resource, we're just aware that the containerized application is there. We actually don't care or potentially don't even need to know whether it's running on premise in the cloud or which flavor of cloud vendor it's running on. We're just aware that it's a resource that we can use from that point of view. So there is there are some steps towards direction. But in terms of what I think you're really asking for, I don't think you'll find a good solution out there in today's market. But it is something that all the vendors are very conscious of. I know it's kind of the next holy grail that we need to get to because obviously cloud's great, but if you don't manage it properly, it can be really expensive. And that's something that needs to be managed. Yeah, so you're talking to the right guy. Colin's the guy that would invent that stuff. So sounds like it's on his mind, and he'll be working towards it as part of our larger roadmap. You overestimate me, Scott. I'd just tell someone else to invent it. Yeah. Alright. So the next one is kind of a layup. This is from Mark. He says, I understand you offer this as a SaaS on AWS. Do you offer this on Microsoft Azure? And I actually don't know the answer from a technical standpoint. So maybe, Colin, you can can help out there. So the answer to that is in terms of the the SaaS that we do, where where we fully manage end to end, we do not currently. There's been some discussions, but no no decisions at this point. However, it runs in whichever cloud environment you have. It's just that the managed service that we have is currently only offered in in AWS. A number of reasons for that, you know, in terms of the overhead and infrastructure we have surrounding that to help us manage and automate that environment. Whether we would in the future, undecided at this point, but currently the answer is no. So we don't do the we we we won't put it up and run it for them, but we can give it to somebody just like they would do in a on prem It can be deployed. Yeah. Absolutely. They can deploy it in in a Azure environment. Yeah. So cloud provider is completely irrelevant to us from that point of view. Yeah. So we can install anywhere. Alright. Let me see here. Got that one. I'm kinda skipping around. I've got a bunch of questions. Here's one. Gardner talks about hyperautomation. How does SOAP fit into hyperautomation if it does at all? Good question. We didn't mention hyperautomation at all during the presentation. It's one of the big trends, I think, of twenty twenty one and beyond. So what hyperautomation is, it's a philosophy or a strategy around automating anything that can be automated. But it's not really just an IT centric thing. It covers the whole business. And to be honest with hyperautomation is where a lot of the RPA, robotic process automation, is being touted and coming in. That's only part of the story. But SOAPs are also part of the story. It basically says that hyperautomation, if you're doing manual stuff in your business that could be automated, you're broken, you're doing it wrong. So we are not hyperautomation. We can't solve all of your hyperautomation problems, but we and SOAP technology are part of a hyperautomation strategy in terms of helping you tie some of those other disparate automation things together. So it fits, but it's not hyperautomation. Hyperautomation is bigger. Yeah. There is no hyperautomation tool, so to speak. It's a combination of different people trying to pull them together in something that makes sense. That's like taking our service orchestration, even it's the orchestration aspect on steroids. I have a question from Jan, and I think I can take this one. So he says there are some competitors in the market of work with automation. Why choose Stonebranch? Well, I think this this presentation was a big part of of helping to, answer that question. But, you know, from my point of view, one of the biggest things that we do that others don't do well is the hybrid IT aspect. So there's a lot of companies that will say that they're they're they have SOAP capabilities. There's a number of companies that are listed as, potential SOAP vendors on the market guide that you can download. What I would say is, you know, we'll take the Pepsi challenge against anybody that, you know, wants to illustrate in a POC or anything else that we can automate true workloads and create workflows across, you know, the categories we've talked about on prem, cloud, and and containerized microservices. So that's that's a big aspect of what we do where we have, you know, great great capabilities. There's a number of others as well, but that I don't wanna bore everybody with a sales pitch. But thanks for the question. I I actually don't know the answer to this one either, Colin, so I'll throw one at you that I don't even know if you know, but I'm gonna I'm gonna ask it because I'm curious. I have David, and he said, can the platform integrate with blockchain layer? I e, one, execute smart contracts for transferring data or two, having decentralized data repositories so data is more secure? And I imagine the answer is something around the lines of if it has an API, yes, but maybe there's something else. So it's yeah, I'm like you, it's not a technology I'm super familiar with. I'm aware of part of the thing with blockchain is the use cases that apply to what we do. And this sounds like an interesting one. I'd actually love to have a conversation with you, David, in terms of that. My answer would be similar to Scott's is I don't have anything out of the box today, but I have the tools and capabilities to make it happen relatively painlessly, again, if there are APIs available, which I would imagine they have to be. But I'd love to explore that use case in a little more detail. Great. Thanks, Colin. And thanks for everybody, who answered questions or asked questions. I know I still have some to get to. Sorry, we couldn't get to them live here, but we're out of time. I'd like to just thank everybody for coming out. We have a really good audience still on listening to the questions and answers. I'll remind you to go ahead and download the service orchestration automation platform guide. If you can't get it on the platform that we're using here, for the web seminar, you'll get an email tomorrow that has a link to it that you can get it. And then please, again, if you can take a few minutes to answer the survey, many feedbacks very much appreciated. We wanna continue to get better and improve the information we share with, you know, audiences like yourself who who really care and have a passion for this topic. So with that said, I'm gonna turn it back over to And, maybe we can close this out. Yes. Thank you very much, Scott and Colin. We have run out of time, but I want to thank the both of you guys for a very informative presentation. A special thank you to our sponsors, Stone Branch, to the IEEE Computer Society and most of all, to the audience. Thank you guys for attending live or for on demand as you can view this at a later date. There were a ton of questions, and we will try to get those answered to our best ability and get those answers out to you guys. As Scott did mention, I will reiterate about the resource tab for you to receive that information and to please go ahead and fill out that survey. Thank you very much. Everyone, have a wonderful day. Stay safe and see you again. Thank you.