The Enterprise Alchemists
The Enterprise Alchemists is a new podcast for Enterprise Architects to have honest and in-depth conversations about what is relevant to our world. Expert guests provide additional context on the topics of the day in Enterprise IT.
Your hosts, Guy Murphy and Dominic Wellington, are Enterprise Architects at SnapLogic, with more decades of experience between them than they care to admit to, and the stories that go with it.
The Enterprise Alchemists
Applying Development Experience and Best Practices in a No-Code World
Brian Green, software architect at SnapLogic, joins Dominic and Guy to explore the fascinating convergence of no-code, low-code, and traditional software development strategies. Discover why even the most user-friendly platforms require a solid grasp of software principles to truly excel, especially in large-scale operations. Brian sheds light on how traditional concepts like configuration management, environmental separation, and documentation are essential in optimizing no-code development environments. With a focus on the balance between ease-of-use and the rigor of traditional development practices, this episode promises to equip you with the insights needed to navigate the challenges of scaling in the digital age.
Join us as we uncover how traditional software techniques, such as linting, can revolutionize SnapLogic pipelines for enhanced robustness and efficiency. Learn about the seamless integration of these techniques with source control and how a center of excellence can bridge the gap between traditional and citizen developers. We delve into the potential of low-code/no-code platforms when the right levels of abstraction are understood. From generating test data with tools like SnapGPT to balancing standard engineering practices with unique platform benefits, this episode is packed with insights to elevate your enterprise strategies.
Find more details and a full transcript on SnapLogic's Integration Nation community site.
Hello and welcome back to the Enterprise Alchemists, a podcast by SnapLogic that is all for enterprise architects and people who want to be enterprise architects. I'm your host, ominic Wellington, and also joined by my colleague, guy, the other host. Hi, guy,
Guy:reetings all
Dominic:, nd this week, continuing a minor theme that we had from the last season, we're joined by someone who is a different sort of architect. So Brian Green is a colleague of ours at SnapLogic. His title is architect, but he's not one of our merry band. Brian, thank you for joining us and could you please explain?
Brian:Hi, I'm Brian Green. I have the ambiguous title at SnapLogic, just architect, and really it's the internal side of things and the product. So I started my career doing web apps, early infrastructure, and moved into data and analytics and then moved into moving these things analytics so and then moved into moving these things, and so you know, having moved app data and having moved data data, um, snaplogic has been a nice, a nice fit in that you know we do all those things, um, so I work on the inside of the product, um, trying to optimize it and look at what is the next generation of things that we're going to do internally to drive new capabilities for the customer.
Dominic:Excellent. So that was actually what we wanted to talk about for the next little while, because one of the conversations that I certainly and I believe, guy, it's the same for you conversation that we frequently end up having with our counterparts on the customer side is, you know, the SnapLogic thing. It might not look like your traditional text-oriented programming tool, but actually there's a whole lot of programming best practices let's say that come from that world that you should keep in mind when you're developing and when you're managing, especially a larger amount of SnapLogic pipelines. And so he wants to talk a little bit about how you could apply some of those traditional software development best practices to the sorts of no-code development that goes on inside of SnapLogic. So we had a great beginning of a conversation and we decided, no, no, no wait, this needs to be a podcast. We need to share this with the world. So do you have an introductory statement, Brian brian, that you want to lay out your position?
Brian:rian man, I think you alluded to it reasonably well. You know this was my, you know my thought when I came to SnapLogic and things I was asking about, kind of on day one.
Brian:A history of no-code, low-code tools does show that they're really they continue to just be abstractions over the computer. Uh, it's a visual abstraction, um, instead of a heavy text-based abstraction. You know it's. It can be a lot easier and more efficient to move a lot more data around, but it doesn't change some of the fundamentals about what we want to think about. You know, environmental separation, how do we do testing, how do we document and do lineage and think about our data and governance. You know these concerns don't go away and you know, I think with a lot of tools you see the same lifecycle, right, like you could name some. You could name some other ones that start with an S ironically, several of them, right.
Brian:And you know you come in and you say, well, it's no code and it's very easy, and we get it moving.
Brian:And then you know you get six months in or a year in and the scale has gone up and the criticality has gone up and all of a sudden you start to have challenges. They're subtle, weird things and a lot of people will ask themselves a lot of questions but why is this hard? Why isn't it working as well as we thought it would? And some of the answer is you're doing software work, but you didn't treat it like software, and that's okay in the beginning and when it's easy, but over time that's okay in the beginning and when it's easy, but over time that's challenging. And so you don't need compilers and green screens, right, we don't have to make this hard. But the lessons learned and the way we do things like configuration management, those are pretty universal and so I think, dragging them into, how do you function with a low code, no code tool at scale, getting the benefits of that? Yet Okay, really we are doing software right, and there's an admission there in the we are doing software that can be challenging sometimes.
Dominic:The first step is you have to admit to yourself that you're perpetrating some software here.
Brian:I've had that conversation with several people in IT management. Right, like we just have to to be a little bit. This is software.
Guy:It's easy and it's fast, but it is software I'll just add to that comment because, um and again I'll come from a different background of with, of integration, data management.
Guy:But even with our larger clients, it's interesting that I've seen in the last 18 months there is a duality across some of our accounts about that approach of the. We started as low-cost citizen developer this is like the net new thing that doesn't need these concepts but then we're seeing accounts with hundreds of developers, thousands and even tens of thousands of pipelines, so obviously integration patterns and components and snaps and potentially custom functions, and not realizing at that point that and not realizing at that point that you that moment of realization that says you need intelligence automation, above and beyond what the UI is giving the end user. So completely agree with everything you're saying. But I have been finding it interesting that in our larger accounts it's not every single one of them has realized this and I think this is also a wave I'm starting to hear about across quite a lot of the medium to large enterprises we're talking to that. Sometimes they kind of miss the elephant in the room when they start talking about strategic management.
Dominic:Yeah, I agree, I'm seeing some of the same in one of my accounts has a couple of thousand monthly acts, active users in the platform developing pipelines, and this was something that's actually a slight aside. This was actually something that surprised me a little. Coming from outside the field, I had an expectation in the back of my mind that data integration would mostly be an occasional thing. You'd set up the pipeline and then the pipeline would run and you'd go do something else, and the rate of change inside these large environments and the never-ending flow of new bright ideas, of things we could do if we could only get access to that bit of information over in that other system, means that there is actually a pretty constant flow of developments. It's not at all a static environment, but I think that's the realization. Also many of those customers are having that they start off not thinking that they need to worry about you know which is the canonical pipeline, and all of them end up with weird names and things like that and suddenly it's two years later and the environment is not the way that they would design it if they knew everything at the time that they have since found out.
Dominic:So a lot of what this podcast is about is about trying to and indeed our whole team's practice is about trying to capture that information and help people avoid getting in trouble. Learning from other people's mistakes rather than from your own is generally a more pleasant experience, and so that's kind of where we are today. So, coming back to the nominal point, why don't we walk through some things, some techniques that come from the more traditional text-oriented development world and how we might apply them in the SnapLogic world? So one that Guy and I were actually just discussing offline was linting, for instance. This is something that's you know in the software development text-oriented, again, software development world. There's all this idea of being able to identify difficult, problematic, suspicious ways of doing things in your code. How would that apply to SnapLogic Pipeline, would you say? Brian?
Brian:I mean, I think it's a similar idea, right, there are static patterns in combinations of snaps or snap configurations that you can analyze for Very.
Brian:You know static patterns in any source code language. It's been fascinating to see linting for snap logic pipelines show up as snap logic pipelines. That was a thing that was an interesting surprise to me. But yeah, I think it's a similar concept and the emergence of that in the last I don't know couple of years in the platform does, uh, I guess a real signal that you know you've developed a bit of a programming language right, like if you can lint it and you know if you can do things with a language that cause problems such that you want to do static analysis to detect those. You know there's you've crossed a boundary into. Okay, you have produced something that looks like a programming language, right, because it's general purpose enough that you can say that there are things that are semantically correct that also you shouldn't do, right, which is why we do linting in, you know, in all languages. So it's an interesting technique and, yes, available.
Dominic:There's probably a convergence there that if the environment is complex enough to need linting, it's also complex enough to support linting, as you just said. You know you can do it as a pipeline in SnapLogic and now we have the ability to call that even from SnapGPT so that you can check your pipelines for best practices. So that's something that you might not think of if you don't come from a programming background, but it's definitely a thing that we're trying to do to make more visible so that people will think of checking and will have the advantage or the benefit of doing that.
Brian:I'm really interesting to see how we get that linting capability integrated with source control right. I mean, that's where we usually see linting and controls. So I think, as we look at you know, talk to product management about how does this fit into the product, how do you get the benefit of these things from the software engineering without talking to people about the complexity of it? Right Like, there's an argument that says I shouldn't need to think about linting, right Like, as a user. Why doesn't the system do that for me? You know, and there's this back and forth iterative conversation, and so, you know, where does it fit into the integration with source control? Do I have to manually turn that on Right Like? If you're telling me that linting is the best practice, then shouldn't I just have to work to turn it off?
Brian:I think there's a bigger you know bigger conversation about how to you know, how does it feature? You know, how does a traditional software engineering feature that developers are used to manually configure, like you know, thinking about? What are we learning from platform engineering and other cross disciplines? Why does the developer have to think about that right Like? From a developer experience standpoint, can't we just make that kind of more transparent?
Brian:And I think we'll get there.
Dominic:I think, yeah, that's the realization that some of the longer standing customers that I work with some of them have a decade of experience with the tool, that sort of thing that they're getting to adding all sorts of checks as part of a multi-stage release and deployment process, and it's one of the big things that we talk about a lot on our team when we're advising SnapLogic users on setting up a center of excellence because, that center of excellence can be staffed by people who have this sort of experience to think about things like CICD, and that is what enables you to have the true citizen developers, people who come from a domain background, domain specialist background, so that they can work on that side of things with their closer understanding of the domain of the problem that they're actually trying to solve, advised and supported by things that are being done at the center of excellence level by people who have that sort of background yeah, absolutely, and I think there's an, there's another, I'm not going to say challenge, but I think the other thing I'm seeing across this comment is, again, we obviously snap logic is a low code, no code environment.
Guy:I think one of the challenges and opportunities for us to consider this moving forward is we also have a lot of environments where you, you do have very different classes of user. So we do have, they are obviously technically orientated, but they, they themselves, are not developers. They're not, they don't live within a defined software lifecycle within their job, they are much more point-orientated. And then, combining that with, we have integration developers that I would say, historically at least, have been closer to the traditional developers because of the nature of the patterns they produced, whereas, again, I see a lot of data users can quite often be a little bit more less engineering, more point solution orientated.
Guy:I think you raise an interesting question about when and should you be giving this information to the end user, if you do or don't understand, if they understand the outcome. Um, in several of the accounts I'm working with, they are using this within the operational life cycle of the pipeline migration rather than the developer life cycle, if that makes sense. But yes, I mean obviously the panacea would be we have something that you literally could, you know the dream would be it's so rich that you just it's on and it almost raises its head only when things are going to go badly. But that's obviously more of a vision today than where we're at with the successful early days that we're at with the current offerings yeah, there's the old joke that the perfect software user interface should just have a single button labeled do what I mean you know, I posted on linkedin somewhat recently.
Brian:Uh know, I know someone. They went to a meeting we met with the business. The customer was very savvy and after about 30 minutes of discussion they said, listen, I need you to just make the software flexible so it can do what I need need. And I mean this was the level of sternness, right. I mean that like she pounded her hand on the tape right, like she was looking us in the eye and like, okay, and you know, we confirmed it. Oh, that's the requirement make it flexible so it does what you need. Yes, you finally get it. Okay, we got it. And then you know the meeting was over and I mean we didn't got it right, like we kind of got it. You know it was data analytics and dashboarding kinds of things, right, and you get into the what's the requirement for the infinitely flexible dashboard? It's that it does what I think.
Dominic:It shows me what I need to know when I need to know it indeed.
Brian:And you know you wish your integration. I integration, I mean I still think there's like a, as we look at Chad GPT, I still think there's vision there, particularly with integration around. Hey, I've got this kind of system and this kind of system connect them together, right Like I still think that there's an easy button there or easier button there.
Dominic:Indeed, but while we still have to operate in this broken world, one of the things that we do have to manage, if you want to set up a full-on continuous integration, continuous deployment model is you have to think about multiple environments that you work with. What do you think people are not doing in SnapLogic that they ought to be doing by and large? What are the sorts of things that you think should be more prevalent out there?
Brian:I actually think this is a thing we do easy. This one, like the use of accounts to abstract the connection details away from a pipeline, is a very straightforward part of the tool and I think anybody almost anybody grasps that abstraction very quickly. Right, and when I think about the, you know the oldest abstraction for this kind of thing, thinking about this podcast before we got on. You know, I started writing software 20, over 20 years ago and in your java application when you wanted a connection to a database, you'd ask for it by name, right like. You wouldn't say, hey, I want, you know, I know the name of the database server and the credentials and all this other madness. Right like, no, you're a piece of software. Why would you even have any of that information? You would ask the thing that has the server connections to give you one and you'd say, hey, I it by name and it would give it back to you by name.
Brian:And then later, when your software ran in a different environment, you know, as long as the administrator had set that up, that just worked. And you know I've seen lots of software that made that problematic and over the years. But you know this is a thing SnapLogic does very well right, like, and I think most people building pipelines and sort of configuring things get to very quickly understanding how that works and you know you can do quite some magic with it if you want. So I don't know, I don't know that this is a very big deficiency I see in pipelines. I think we make it easy enough to do it right.
Dominic:Exactly, exactly. Yeah, because there is always that trade-off. You have a lot of capabilities that you can offer. You can be flexible enough to do what the user wants, but you also there's a sort of magic about when to disclose that, when to force the user to think about something and when to let them get to it in their own time, when they have the need. And that's the trick. In this case, yeah, the multiple environment, multiple user parameter integration is hitting the correct balance. Now I'm wondering what else we should be doing even more of.
Brian:I mean, one of the things that I think is challenging in this space is lineage. You know, lineage is something we've been working on for a while. We've been talking about it. There's some early previews out there In integration and environment. Lineage and observability both ideas that we kind of can take out of software they're really key and I think they've been challenging for our customer and for lots of customers, right Like, lineage is a huge subject across data integration platforms and if you look at how a pipeline is built, if there's any level of dynamic SQL in it or dynamic configuration, you actually can't understand the lineage for the pipeline until it runs.
Dominic:Yeah.
Brian:You know true design time lineage. If you have an engine that gives you that, I make the argument that it's not flexible enough to be super useful. Right, like you'd be mad at it if it could do it. And so the flip is and this is fun to talk to as we've been designing this feature with customers right, because everybody says I want to look at the definition of a pipeline and have you deterministically tell me its lineage and I can't do that. Right, because there's a million things that a pipeline can be dynamic and so you say, well, there are N lineages related to this pipeline.
Brian:Providing insight into that, I do think, is a thing that we can share back to the industry, and I'm excited to see that go forward, because integration is often a black box. Right, I'm the system on one side. I put data in and it didn't get to the other end the way I thought it was going to. Somebody on the other end said it didn't work right the way I thought it was going to. Somebody on the other end said it didn't work right. And now we have this like Spider-Man pointing at each other, where the ERP people point at the pipeline people and the CRM people point at the pipeline people. The pipeline people say, wow, I don't know right, like seeing into that and really being able to deterministically say for a single execution, I can tell you exactly what went where. I think that's a level you know, that's observability, that we get in some high-end software that we're going to see brought into our product and I think will be a huge change.
Dominic:Yeah, because you do get that moment of I don't actually know what happened when it ran, or I can't determine what will happen when it runs at some points in the future, because of these dynamic inputs.
Brian:Well, and this is one of these, like the answer is both true and false simultaneously. Right, because technically you can get the pipeline execution. It's a great big JSON file. It's the same JSON file that I sort of start with, right? So here you can have it and you know. But can't you know how much can you derive from that? How easy is it to derive lineage? That's a completely different conversation, right? And how do you do that at scale? You know, I think moving that up the food chain is going to provide a lot of value, absolutely Quite different topic of question or conversation.
Guy:I'm seeing again the larger accounts. The environmental discussion is not as simple as test dev prod pre-prod we also have. Because of the nature of our architecture we're not a single shared pool environment, so we end up having, in some places we'll have a shared environment for less complex We'll also have something like an ultra environment for obvious reasons, where it's got a very different physical dynamic. Some other accounts actually split, jolt out.
Guy:I have worked with projects where we've also categorically said these other sub-platforms, so think CRM supply chain, will be considered to be mission critical and therefore they should have a separation of concern on resource management and therefore they are their own landscape. What's your thoughts on that? Because at the moment, going back to CICD and automation around this, we don't seem to have a point of view yet of tagging the lifecycle of the platform so that you could easily automate characteristics through the lifecycle of moving from one to an environment to another. There's a lot of human IP would be needed to carry through this pipeline is of a certain characteristic criticality, ownership and the endpoint will be platform A rather than the simple test dev pre-prod that we're all used to. What have you seen and what's your thoughts around that challenge?
Brian:I mean, I think there's another dimension to it as well, which, as a middleware team, you know like some of this is consideration of the sort of the usage by the target customer, right? So if you're using SnapLogic and you're two citizen developers and you've got 40 workflows, that's a very different ecosystem from you. Know, I have 50 developers or 100 and I've got, you know, n environments and you know what you described and you know what's the jumping point for that, I mean in complexity. In a previous role I thought a fair bit about this, right, and I think you one huge inflection point is any decent sized operating company that has bought another one, right, as soon as you do, that, stuff starts to get fun in terms of environmental controls, because now you have a ton of systems that are on different life cycles and, and so you'd love to say dev, test, qa, prod, but the reality is and this was a big surprise to me, right?
Brian:You know, stood up a middleware team and we had four or five environments and then what we figured out was that a lot of our constituent participating systems could not keep up with that level of parity and in many cases it's not worth it, right? So, like it's a small labeling system and they charge you per instance and they don't care if it's DevTest, qa or Prod, it's an equal charge, right, and there's two users and it's really lightweight and you go well. On the other side, by the way, is ERP, and there are eight instances and those folks can snap their fingers and make a new one. Like, people think about ERP as this big burly thing, but a lot of ERPs are insanely good at like being able to fraction off a new instance with data and everything and then start working.
Guy:Right, as you know, I was at SAP. I encountered one of their largest accounts. Just to give you how big big can get, they were running 128 ERP landscapes. Yeah, so not instancesP landscapes. Yeah, so, not instances landscapes. Now, the reason was they were running from the free live environment. They had a five-layer strategy.
Brian:So if you think about instance management, yeah, they were in excess of 600 non-production environments that this whole discussion would actually have to cope with even when you get to like way smaller than that, though, right like, you don't have to get very big before you realize that it's not just instant strategy, but it's how do you use your middleware as an equalizer, right like, how do you use your middleware as a traffic cop? I mean, it got a little weird, but we did a big staged cutover where we used middleware, we used integration as the strategic weapon in large acquisition integrations, you know, bringing new ERP instances in and new data feeds in and new, you know, api endpoints online that are federated across. Whatever's your middleware is your secret weapon there. But it means you think about, you know we would say, hey, listen, at noon we're going to switch over and it's no longer connected to this instance, it's connected to that one. So everybody in the ecosystem knows we've switched and we would play traffic back and forth and we use.
Brian:We had a piece of software with a database in it, with a decent little user interface that we use to manage that and, like, all participants could get in and understand what was connected to where, when, and it was huge. It was a huge sort of enabler, because it's not everybody's going to be able to meet the multi-environment requirements. But you can use your middleware, right like you can use snap logic to have n and then make those like for a given environment. Then you go horizontal right. So in a given environment, which one of the nodes am I supposed to be going to? And that that's your whole ultra versus. You know whatever conversation short of humans, right Like I think you have to set that up per environment or per customer, like that's so customized. I don't know a way to generalize that right.
Dominic:Yeah, it's not going to be portable. It's too specific, although some of the stuff that's happening now can at least help you with doing things like mocking up your test data so that you can maybe postpone that moment of reckoning a little bit into the future. It's one of the things that I like about SnapGPT that you can make me a dozen records that look like the output of System X, so that you can play around and get things right before you even start connecting to the dev environment, and so on and so forth.
Guy:So we've been talking about how standard engineering practices apply to low-code no-code. If you were to approach a platform like SnapLogic, where you've come from a very code-orientated point of view, do you think there are things that you shouldn't be trying to apply to low-code no-code? You could end up risking undermining the value. So bit of a philosophical question, but I'm always a great believer in the sessions of okay and what shouldn't be done as much as what should be done.
Brian:You know I won't name any names, but you know I listened to a recording from a customer prospect that had done a pretty intensive kind of evaluation of SnapLogic for their demands and said you know, we're not, we don't want to do it, we're not, we don't want to use it, and we have very detailed feedback. Why? And I was very interested in it? Right, because I had my own opinions too. And I was very interested in it. Right, because I had my own opinions too. And I think the short answer comes to contemplating the right levels of abstraction. And what do I mean by that? Right, if you want to use SnapLogic to connect your ERP to your CRM and your PLM and file exports and to your EDI providers, right, and there's infinite in and out connections. You know. You want to use SnapLogic to build a data warehouse and move data over and then orchestrate SQL against it All those great use cases. If you want to make pipelines that have for loops with complex, true false conditions and you want to do things that look like try catch exception behavior with complicated retries that you're programmatically controlling, you know there's this thing where and it's I don't know. It's a little Zen to say right, but like, if you let software engineers try to use SnapLogic like software, like try to make pipelines that look like programs, they will not have a good experience and the pipelines will be unpleasant to look at and debug and use.
Brian:Right, like you have to. You have to understand and get your head into the level of abstraction that it presents. And if you've got some complexity or some weirdness to hide sometimes it's okay. Well, go use the APIM product, right, because you want to orchestrate APIs, but some of those have these more complex workflows behind them. Okay, well, let's go stand up some APIs. Let's compartmentalize this thing. Let's make pipelines that are the right level of granularity, right, we're thinking about the right level of abstraction. So if you try to do programming things in a visual programming tool, it'll hurt, right, like, don't do that and that's blurry. I don't. I, that's blurry, but I'm interested if that resonates, right, like dominic's sort of smiling it does.
Guy:So I'll give you one of my prior experiences, but also, uh, we've had one of our previous podcast guests was chris ward from amir's um services team, where we had an account where a one strategic division had chosen us another team that was very traditionally developer orientated and they could not get their heads around the mindset.
Guy:And we put Chris Ward in because, like yourself, he has a massive. His prior history was very classic development around integration and he spent a lot of time almost coaching what you said like the Zen of it how to think about this thing, to get the best out of it, rather than having an argument about parity of mindset. That is exactly what he's saying. He's like I want it this way because this is how these my, my environment and tools and I think about development, and he sort of had to go. You need to go three levels higher because this will do it for you and then you will think about it differently when you want to apply your outcomes, but your outcomes will not be the thing that you've spent 10 years developing there's a pattern-based discussion that you get to have with.
Brian:You know, in any decent ecosystem there's a pattern-based conversation to have with the other party as well. Right, and for us this was really interesting. You know, one of our biggest wins was being able to go to the various ERP teams, because we had several. Right, because you ought to and I mean different technologies too, not just different instances, but you ought to have all of the vendors and multiple instances of all of the vendors. We were able to go to those teams and say, hey, listen, you know, we have this middleware.
Brian:We'd like to develop the two or three standard patterns for how we move data in and out of systems that look like. So now the COEs can interact with each other. Right, and there's this magnifying effect of oh, if I have any erp in the fleet and any crm in the fleet, I actually have patterns and recipes all the way through. And to dominic's point earlier, the big interesting thing about integration is that, you know, some of them do stay still for years. But, like, the integration platform is a very fast moving like, ideally it's a strategic enabler because you can go so fast at making, you know, making changes and rolling them through um, because ultimately the people on both ends are like you're the slow point in many cases right, like if you're not, then you can sort of move both ends along faster.
Guy:And, just to round out, you talked about again the complexity in the UI. In a prior middleware company we had a famous customer that used a Flow UI and for 95% of its use cases it was brilliant. And then they complained about the last five and when we went in and reviewed it to do a translation, they were building integration pipelines that weren't tens or even a hundred. They would have been the equivalent of thousands of snaps and at that point the equivalent of yourself. Sir, basically said get down to the code split and analyze it at the code level, because no human being can look at this thing and actually understand what you're doing. And basically there was a whole interesting. They'd effectively built a gigantic application under the concept of it being an integration.
Dominic:Was this all a cunning plan to get approval to buy gigantic HD monitors for themselves?
Guy:It might not have been, but again, it was just interesting about that mindset of trying to get to the yes, you could, but should you be doing it with a particular type of, as you say, abstraction and tooling? Um, when, when do you start almost getting diminishing returns? And because? Because the diminishing returns from the vendor I was at was, yeah, there were no meta-error statements that you could say somewhere in this 120 steps, something has gone wrong somewhere in here. Drill down to here, of course, what you got was one very little thing went red, but the ability to roll that back to understand really what was going on wasn't correct. But anyway, that's a side piece, indeed.
Dominic:No, this has been a great conversation. Do you have any closing thoughts, Brian? Things that you wish more people knew and thought about and considered in their use of SnapLogic? This one weird trick.
Brian:This one weird trick. No, use source control. You know it sounds funny, but like somebody needs to. A thousand people need to hear that Use source control. If you don't know how to use source control, ask a developer. They'll probably be mean about it, but learn to use source control. That's life-changing.
Dominic:Indeed, and something will happen at some point and you'll be glad you did.
Brian:I swear, if you can reduce most of what you do to text files that you can store in source control, it's solved an inordinate number of problems for me over the years.
Dominic:This is very true, Excellent. So this has been a fantastic and wide-ranging conversation. Thank you so much for taking the time out of your busy schedule to talk to us For the audience. Remember that this is only part of Enterprise Alchemist, what you're listening to right now. If someone sent you this episode, you can subscribe to the whole feed. Wherever good podcasts are downloaded and there is also a whole text-oriented side of things that goes on on the Integration Nation forum. A full transcript gets posted there if you prefer to read rather than listen, or if you want to go back to anything that we discussed, as well as links to anything relevant. I don't think we talked about any external resources in this episode, but when we do, we always link to them from there, as well as from the show notes right in your favorite podcast app. So thank you once again for listening and we hope you subscribe and check out upcoming episodes. Thanks all. See you later.
