Communicating the Value of Connecting Systems

  |  Code Comments Team  
統合
パートナー

Code Comments • • Communicating the Value of Connecting Systems | Code Comments

Communicating the Value of Connecting Systems | Code Comments

About the episode

Connecting tools and systems yields all sorts of benefits. What can be tricky is knowing exactly what those benefits are-especially emergent ones. Neesha Godbole, a Partner Account Manager with MuleSoft, shares how mapping the benefits of joint projects is about finding more than the sum of the parts. But it doesn’t make a difference if you can’t communicate the value to customers.

Code Comments Team Red Hat original show

購読する

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

トランスクリプト

You can have the best solution in the world, but it won't matter if you can't communicate the value to prospective customers and users. Translating technological capabilities into business value is an important role within any enterprise tech company. And being able to communicate the value of a joint solution, well, you really need to have a firm understanding of the technology and a working understanding of your partner's technology. And with that understanding, you can discover the value for your users and customers. I'm Burr Sutter, and this is Code Comments; an original podcast from Red Hat. In today's episode, I talk to Neesha Godbole at MuleSoft. Neesha began her career in tech as a computer science graduate, starting out in an engineering role, but now she finds herself focused on the business side of MuleSoft as a partner account manager. So many of us are out on this kind of journey in many cases, meaning we maybe start at school where we actually learned a bunch of technologies and we had to go out in the real world and apply them. Can you give me a little bit of background on what kind of journey you've been on? Yeah, absolutely. And thank you for having me. I joined MuleSoft about a year and a half ago, and I was a channel solutions engineer. So, I was working with our partners, which is how I brought myself to this role that I'm in now, which is a partner account manager. But when I was a channel solutions engineer, I was supporting our partners with MuleSoft technology. So, similar to a traditional solution engineer that works in the deal cycle that would support typically an account executive to help a customer or a prospect understand the technology and how it might add value to them. We do a similar role in the channel solutions engineering space. We basically support our partners in doing that same thing, understanding the technology. So, in this case, MuleSoft, which is owned by Salesforce, it's an integration and API management platform helping our partners understand what is MuleSoft, how can it help you? Because integration and API management is not always the easiest thing to understand, but as a partner, for example, Red Hat, how can your customers best make use of MuleSoft so that it can help enable their business transformation needs, their digital transformation and support their business and growth. So, that was the role that I was in up until about a month ago when I transitioned into the role that I'm in now, which is more sales and business-facing as a partner account manager. So, in this role now I'm supporting our partners, but more so owning the relationship that's now the role that I'm in. It's a bit of a change from my previous role and of course my background, but it was a natural transition for me coming from the CSE role or channel solution engineering role to now take this one on because I'm able to blend my technical experience now with more of a sales or business mind. So, it sounds like you have that dual skill set of customer-facing, partner-facing as well as technological skill set? Yeah, and it's funny, I never really thought that I would find myself in this role, but I feel like the arc of my journey is probably similar to many others where you learn the technology at the most basic level, but then really what customers and the market cares about is how can you actually apply that technology? Why does that matter to the business at the end of the day? And so, being able to translate the technology concepts into business language that folks can understand and understand the benefits, I think has been one of those themes throughout my journey and probably others as well, is, "Okay, we have this technology, but what purpose does it serve?" Right? Who's this going to help and why? And then how is the underlying reasons how the technology works, to begin with, but it's the business value that really is going to help drive ROI. Absolutely, and I like what you said there because you definitely are spot on when it comes to the application of technology to a business problem. I think a lot of people do forget about that. We get caught up in the technical bits and bolts and just enjoyed living in that technical world, geeking out in some cases. But at the end of the day, we do have to solve a business problem. Absolutely. Let me ask you this, I'm interested in knowing more about integration. You said integration, you said API management, we know MuleSoft is very famous for that, but I imagine some of our listeners are not yet really tuned into what the integration space looks like. So, can you describe more about what it means to connect A to B and what those different types of systems might be, and types of use cases you might serve? Yeah, absolutely. So, it's interesting, when I joined MuleSoft, I also had no idea what integration looked like or what really was a business case that we were trying to solve. So, it's been quite a learning journey for me over the past year and a half, which I think has been actually one of the best parts about this company and role. But so integration on the whole is connecting various systems. (04:34): So, as a business, you have hundreds or thousands of systems that you need to connect that need to talk to each other in order for you to deliver on experiences or deliver on employee needs, customer mobile apps, things that your customers, partners, employees are going to actually interact with on the daily. Those need to be powered by data, and that data is stored in various different systems. So, that could be Salesforce, that could be an on-premise database, that could be another cloud-based system. There's hundreds, and of course, with the explosion of best-of-breed, that's just going to become even more of a thing. So, those systems need to be able to talk to each other, and the way that they talk to each other is typically through APIs. And so, in order to integrate those systems, you have to develop and design and deploy APIs and integrations, and at MuleSoft, we think of those pretty synonymously. And to do that, you need a technology platform. So, MuleSoft provides that single platform that allows you to design, build, deploy, and then manage your APIs and your integrations so that your systems can talk to each other and so that you can deliver those experiences that your partners customers, employees need at the end of the day, which of course relates back to a business problem, which is driving more efficiency or a new channel of revenue or a new product. All those things are going to require those experiences that's driven by the data that's stored in those systems. So, that's the core of integration. I call these things connectors, right? So, in other words, in many cases, an integration platform is often measured by the connectors that it can maintain or connectors that it has to basically glue one system to another system. What would you say are the most common connectors in use in the MuleSoft universe from customers that you've seen, what are their primary use cases? Are they trying to just take an Oracle database, get data out of it, and actually map that over to a Salesforce or they're trying to go from a message broker out to a rest endpoint? Or what would you say are some of the primary connections? That's a great question. Of course, it's going to depend on the customer and at MuleSoft and at Salesforce, we like to think about it in terms of industry and industry problems that customers are trying to solve. A customer is specifically in an industry and their challenges are all related to that. A lot of the connections were owned by Salesforce or are going to be to Salesforce and Salesforce products. So, for example, Sales Cloud or Service Cloud or all the industry clouds that we have now. So, Manufacturing Cloud, automobile cloud, all of these clouds need to be powered by data that's in these underlying systems. So, that's going to be a common front-end experience, but then also potentially a back-end connector. So, you talked about connectors, MuleSoft maintains 300-plus connectors that are basically out-of-the-box connections to these underlying systems like Salesforce, like SAP, like a database, we just have standard database connectors. It could be Amazon or Redshift, it could be a whole host of things, Workday. All these connectors are maintained by MuleSoft in partnership with these other companies that help us develop them. And then the beauty of that is that when you go to integrate to these systems, you have basically an out-of-the-box configurable, customizable connection to these systems rather than having to build something from scratch. And I think at MuleSoft integration API management's always going to be complex, how can we make it a little bit less complex? By providing some of those out-of-the-box connectivity to these systems that our customers are going to commonly connect to. So, those are just a few examples, and those can drive all sorts of use cases across the board. But those are some of the common ones that we're seeing. Is it pretty common to actually have what I call an aggregated API where, you mentioned earlier, the digital experience where I might have a mobile application and I'm trying to communicate to the back-end set of systems and systems of record and back office systems. So, I might have an aggregate API that's basically facing that mobile application, but back behind there might be 15 other APIs, which might be the database connection. It might be a message broker might be these 15 web services with WSDLs and SOAP, or it might be these rest endpoints with JSON. And I'm assuming you guys are helping the user, helping the developer in this case, aggregate those things, get them into a common format, transform them, and of course, send that request response through that channel. Absolutely. Yep. That's exactly what MuleSoft's focus is, and we provide the tools to be able to do that, right? One of the things that we talk about at MuleSoft is the idea of API-led connectivity. And so, that's really central to the way that we develop and the way that we build integration architectures. And I think that the goes exactly to what you're talking about, this back-end between the core systems of record and then your front-end experiences or whatever it is that you're trying to deliver. And just to elaborate a little bit more about what that means is this concept of breaking down the layers of APIs into what we can think of as layers of a cake. So, at MuleSoft, we think about it in three layers. So, at the bottom, you have what we call system APIs, and those are going to be direct connections to those underlying systems, be it Salesforce, be it a database, be it SAP, and you can expose that data through that API in a common format. So, like you were saying, you're going to have developers working across the space, different developers using different tools potentially, and they're going to come from different backgrounds about how do you present data in a common format so that everyone in the organization can actually make use of it. And that's the idea of this API-led connectivity is where you expose your data from that underlying system in a common format so that other folks at different layers of your APIs can make use of them. And on top of those system APIs is what's called a process API, and that's where you're actually going to aggregate various systems of record and put them into business capabilities that can be made use of by those front-end experiences. So, that could be a customer API that represents all your customer data in a canonical data format, but it might make use of multiple systems under the hood, or maybe it's an order information API or product API. All these are going to be represented at the process layer. And then lastly, you have the experience layer. And so, the experience layer is going to take those processor system APIs and serve them up in a way that's actually consumable by that end experience, so be it Salesforce or a mobile app. So, that's just how we think about it at MuleSoft. Of course, there's going to be various variations on that, and it's not always going to look exactly like a three-layer cake, but that's how we think about it really to break down those layers and make sure that you can enable parallel development through a single source of truth through an API. I do love that layer cake idea that you just described there. That definitely helps I think our audience who's listening to this, from a verbal standpoint, paint that mental picture of how to layer up these things to have those different APIs and those different layers of experience. That is awesome. We are talking a lot these days about how to reduce cognitive load, that's the key phrase you hear a lot in this industry at the moment. How do we reduce cognitive load on that developer so they can think about the business outcome and less about the bits and bytes, let's say, of specifically how to make certain things run. And in the case of a Kubernetes target, being able to ignore that, "Oh, how did I get the Docker file exactly tuned correctly so I can do my docker build, produce that actual image, whether it be with Podman or build or some other tool. Figure out to get it through a CI, contingent integration pipeline into a production environment like an OpenShift or Kubernetes?" That is a lot of work all by itself, just figuring all those things out. So, if you can reduce that cognitive load, so the person can think just about the business logic, the business outcome, and specifically this integration style API-oriented development, I think that's a huge win At MuleSoft, we talk a lot about reusability. Once you've written something once, why not be able to reuse that again in the future rather than having to start from scratch and go through that cognitive process again? To your point. And that's the point of the connectors that we have where it's, we know a million customers have done this before, why don't we leverage what they've already done rather than try to start something from scratch, which is an issue that we see with a lot of other integration platforms, but it's the same for that business transformation. MuleSoft has tools by which once you write that business transformation and that logic, you can actually save that and then reuse it again in a future connection or future integration or API so that you can use it as what we call a reusable building block, basically, in a future project. And the same goes for APIs, once you build that customer API that you've agreed on with other folks in your organization, that this is going to represent the data format for our customer in this context, well now I can use that customer API in the future when I try to develop another mobile app or now I'm looking to develop a web portal. It's that same business logic that can be reused again and again so that you're not starting from scratch, and so that you actually can accelerate future projects instead of starting from ground zero each time. Is it fairly common for people to use the open API specification to determine what that schema is, that definition of what the object is over the wire? Whether that be JSON or something else. Can you describe more about what that looks like? How do I describe my API's inputs and outputs? Yeah. You can use Open API, you can use RAML, you can use a whole host of tools to design your API so that... There's actually an element in MuleSoft called the API designer. And that's where if you're going to develop a new API, where you should start. And it's going to go through iterations because when you're designing an API or you're thinking about a design-first approach, you're going to make sure that the other developers, the other business folks in your organization agree upon that. And so, there can be multiple iterations of that design, but MuleSoft has tools built into the platform that allows you to develop that and write that code and then look at it with other folks in your organization to get that approval before you actually take that design and use it as the basis for your implementation of the API itself. Would that markup language then actually generate a skeleton for me? Is that the next step in the process? Yep, absolutely. Yeah. So, you take that design and using MuleSoft tools, using the IDE, you can actually skeleton out your API based on that RAML or based on that open API specification. Throughout this conversation, I begin to see the world that Neesha works in, thinking about those business outcomes for the technology as distinct from what I do at Red Hat, but as it turns out, we have more in common than I thought. You guys are very focused on the business outcome and the business use case. But at Red Hat, of course with OpenShift, we're very much focused on the more lower level infrastructure and how to make pods run with a nice control plane and things of that nature. How would you say we navigate those two worlds and did you find there was a gap there that you had to work with us on to navigate? I think whenever you have a technical product or a product design for developers, it's sometimes hard to level up the thought process around what is the business outcome that we're looking to enable. Because even with an OpenShift, very technical infrastructure platform, at the end of the day, it's enabling a business transformation, those containers, those pods, those are going to allow you to do faster development, have more efficient cycles, and have more scalable infrastructure that's going to allow you to develop new business capabilities quickly and then also maintain those and upgrade those and scale those as needed. And so, I think throughout the process, even in my time at MuleSoft, that's been a challenge. How do you understand technology at the deepest level that you need to, but then also be able to communicate, "Well, this technology allows you to do this at the end of the day."? Because that's what the customer with the buyer is thinking about in order to enable whatever initiatives that they have. So, I do think as we were partnering together, the Red Hat and the MuleSoft teams on this project, it was a matter of jointly doing that with the solution that we also developed together. So, the solution was MuleSoft Runtime Fabric running on Red Hat OpenShift, and so the ability to basically deploy your MuleSoft APIs into an OpenShift environment from the MuleSoft platforms that you could run your MuleSoft APIs there, but again, what does that mean for the customer? Why would that be valuable to them? And in order to understand that and articulate it, we did have to do some understanding of what is OpenShift and what is the benefits that it provides to the customers? How do you guys over at Red Hat talk about OpenShift to your customers and what are the benefits? So, that was a whole learning process, I think in addition to having to educate myself about what is a container, what's the value of it, and why would people adopt Kubernetes? So, then how now does OpenShift play in that space and what's the value of OpenShift on top of a Kubernetes infrastructure? Well, hopefully, you can see that there are a lot of synergies here, or at least you've discovered that through this process of the partnership. In many cases, when we talk about OpenShift, when we talk about Kubernetes, it's something as low-level as a rolling update or maybe the liveness probe and readiness probe. And again, that's low-level infrastructure thinking, but what it means to the business is that you can deploy now even faster, and I can deploy every five seconds if I need to because the rolling update protects me from a downtime window because it basically rolls over the user never sees that it went down. It basically rolls that traffic over to the next pod that's coming to life kind of thing. So, was that the area you were thinking of, or is that actually lower than where you were thinking at the time we talked about the partnership? No, I mean, I think in order to articulate the value of containers, it's being able to say that, "Right, okay, now I have everything wrapped up, and that makes it easier to develop and easier to have flexible deployments." And now Kubernetes, what does that mean? What's the benefit of Kubernetes and now OpenShift on top of that? What are the benefits of those? I think it builds on itself and then being able to say, "Okay, well now MuleSoft and OpenShift together, what are the benefits jointly that we're going to be able to provide?" So, I think it was almost a mapping exercise of understanding from my Red Hat counterparts, how do you guys talk about your platform, and what are the benefits of it? Because I know at Red Hat there's certain things that you say or articulate in order to express the value. And at MuleSoft, it's the same way, right? It's faster development, faster application development, it's more efficient or resilient operations, it's security built into the platforms that you don't have to think about it, it's future agility. Those are just a few of the things that we talk about at MuleSoft that you're probably hearing on the Red Hat side and saying, "Oh, well, that's actually what OpenShift does too." So, it's being able to articulate those things and pull them out and then say, "Well, where do we see synergies across these two platforms?" And now how's this joint solution going to continue to support those or are there additional benefits that it's providing? Well, I think what you're saying there is that when it comes to the business outcomes, they're actually the same across all the technological vendors that are in this space. They want greater agility, they want a faster time to market, they want greater resiliency, they want to make sure they have a greater security posture, in many cases. I hear those same business benefits or business requests often, every day. So, the business is very much focused on how do I produce new custom applications and custom code, custom-made APIs, and integrations in your cases and ship it ever faster. And that's what I hear often, and that sounds like what you're getting at here. Yeah, absolutely. And it was actually an eye-opening experience when we would sit down with the Red Hat teams and they would say almost word for word what we say. And so, it does bring up this greater conversation around the technology itself, these are what technology today is trying to accomplish, what technology organizations are trying to accomplish, and they just do so via different means. So, Red Hat does it through OpenShift and a Kubernetes platform. MuleSoft does it through one single platform for API and integration development and management. And I think that might be the core theme behind everything we talked about today. At the end of the day, the business outcome is what really matters for the big enterprise, the small business, the person who's just building an application for their small non-profit, they're all trying to achieve the same outcome, which is deliver digital capability, digital APIs and applications ever faster. At least that's how I like to phrase it, and I think that's what you're saying also. Absolutely. Yep. That's exactly what I'm thinking. And I think what our MuleSoft customers are seeing, and the way that it engages with OpenShift is in this environment, customers need flexibility. They need that support and scalability from trusted platforms like OpenShift owned by Red Hat, which is a stellar company, and they want to be able to trust their infrastructure, and MuleSoft has the same benefits, right? So, how can we give these customers the opportunity to build these digital experiences and do so on platforms that they know, they trust, and that they believe will be able to set them up for future success? You mentioned earlier in the conversation the concept of a three-layer cake. Yeah. Well, I can almost envision it now, between the two of us, MuleSoft and Red Hat, there's maybe a six-layer cake, the three layers that are closer to the end user, developer, that business outcome is the three layers you guys are focused on. But we also have our own layers that are going more towards the back-end of the data center where we're talking about things like Kubernetes and those rolling updates to resiliency you get out of having that dynamic separation of the control plane from the data plane, et cetera. Again, a technical level, but it offers that agility, it offers that flexibility. And then of course, maybe into the container world or virtual machine world, the operating system world, those are additional layers down to the actual hardware it all runs on if you will. And so, I can actually see that we actually have that multi-layer of agility, if you will, different layers of agility going all the way up to the very endpoint, which is where the user, maybe on their mobile application, is actually able to interact with that cool API they built with MuleSoft. Absolutely, yeah. It's incredible really to see what is the plumbing or the underlying infrastructure that's actually creating these experiences, like you were saying, all the way from the hardware at the bottom, all the way up through the Kubernetes or containers, through the APIs that are actually processing that data and then serving it up to that front-end experience. We don't think about that when we look at a mobile app and order a new pair of shoes, but really that's happening in the back end, which is really incredible. What would you say is a sweet spot customer for our two solutions to engage, right? In other words, if we actually brought the MuleSoft platform, the Red Hat platform, and we said, "Okay, this is the sweet spot use case, this is the sweet spot customer." What would you say would be that ideal environment? Yeah, I think what I've seen, at least in terms of synergies across our customer base is sort of these large enterprises, like large banks or financial institutions, that because they are trying to change and innovate and become digital-first companies, they need these platforms. They need to be able to accomplish and deliver on these mobile apps, but they're also not always the most digital-first businesses, right? They have mainframes and core applications that are storing our customer data or transaction information. So, how do you tie those two together? You could think of it as old school model of storing data. It's not in the cloud, it's definitely on-premise and you have all these security restrictions, but you still need to stay as a digital company and be a technology-first company. And so, I think our two platforms provide that sort of sweet spot of eliminating the complexity, but still allowing you to do those complex things that you always need to if you have a really disparate environment. I think that's a wonderful summary of what we've been talking about here today, and certainly, a wonderful value proposition when it comes to our joint customers. Neesha, let me say this, I love how you explain these things, and I appreciate the fact that you did educate me here in this session because again, I've been doing this a long time. I'm actually an old-school integration person, meaning I do live in your world, or at least I used to. I actually am a JBoss person, a middleware person, and therefore I do think in terms of what it means to use something like a Camel or MuleSoft or Java EE or whatever other technology it might be to actually bridge multiple systems together and deliver a new common API, a new cool application. But at the end of the day, I get sucked back into the fact that, "Okay, I'm a Linux-oriented person now, I'm a Kubernetes-oriented person. I got to figure out that these containers are running well, is my control plane healthy, are my liveness probes and readiness probes configured correctly, and are all my YAMLs correct? Because of that, I'm often not thinking as much about that higher-level business outcome and business impact that you described so wonderfully here in this session. Oh, well, thank you. And yeah, I could definitely tell have you have some experience in this space because you touched on a million of the things that I think we are already thinking about. So, great conversation. I used to spend a lot of time in this world, this integration thing. I really did. I helped... You can read more about Red Hat's partnership with MuleSoft at redhat.com/codecommentspodcast. Many thanks to Neesha Godbole for being our guest, and thanks to all of you for joining us today. This episode was produced by Brent Simoneaux and Caroline Creaghead, and our sound designer is Christian Prohom. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Johann Philippine, Kim Wong, Nick Burns, Aaron Williamson, Karen King, Jared Oats, Rachel Ertel, Devin Pope, Matias Faundez, Mike Compton, Ocean Matthews, Alex Traboulsi, and Victoria Lawton. I'm Burr Sutter, and this is Code Comments; an original podcast from Red Hat.

More about partners

Discover the ways we build partnerships with trusted companies, creating a powerful ecosystem designed for innovation.

ブログ記事

Kernel Module Management Operator を活用してハードウェア・アクセラレーターを有効にする

2024年 5月 7日  |  

...

パートナー

ブログ記事

Red Hat、Asia Pacific Partner Awardの受賞者を発表

2024年 1月 4日  |  

...

パートナー

About the show

Code Comments

On Code Comments, we speak with experienced professionals on the challenges along the way from whiteboard to deployment.