Category: Uncategorized

How Did You Become An Architect? [00:46]

Michael Stiefel: Welcome to the Architects Podcast, where we discuss what it means to be an architect and how architects actually do their job. Today’s guest is Bernd Ruecker, who is the founder and chief technologist at Camunda, a company involved with process orchestration. It now has about 500 people, and your clients include banks, insurance companies, and telcos. Bernd has contributed to various open source workflow engines over the past 20 years and has written three books, and is writing a fourth. And I’ve written two books, and I know how time-consuming book writing is. It’s great to have you here on the podcast, and I’d like to start out by asking you, were you trained as an architect? How’d you become an architect? Because it’s not something you decided one morning, you woke up and said, “Today I’m going to be an architect”.

Bernd Ruecker: Yes. Thanks for having me, Michael. No, it’s probably not like that. For me, honestly, I mean, I have probably a very typical thing that I started to do things like programming with a computer super early on, when I was like 13 or 14 or whatever. And then I think one of the key moments for me was really when a friend of mine during high school basically started to start his own business. He was selling a kind of modded graphic card, it’s a very specific thing back then, but over the internet. And he had a lot of trouble because he got successful with that, and he had a lot of piles of everything, piles of hardware lying there, piles of emails lying there, piles of invoices lying there, piles of stuff lying everywhere, and basically asked me if I could help him.

And I started to, naive as I was, I basically, from the perspective I have now, I would say I started to write an ERP system for that, and that was really by accident. And I dived into that, and that was kind of coexisting with, let’s say, my interest about a kind of software architecture in a way. I tried to get books around that. I tried to understand how to structure a system, and I could try that out. And I got into Enterprise JavaBeans back then. I got into how to structure different components, how to build them that I can run them, and I wrote a system that is, really weird, still up-and-running today, to some extent.

And that taught me a lot of things about, and also taught me that I find it more interesting to understand that kind of bigger picture around that system instead of diving into one thing very, very deep, and I think that was kind of the roots of it. And I did study computer science. I did a master’s degree for software engineering, so I really focused on that in my university, as well, but I got started, I would say, even earlier than that.

Michael Stiefel: So, in other words, it was sort of an accidental discovery of necessity that got you into architecture?

Bernd Ruecker: Probably, yes. Yes.

Michael Stiefel: In other words, the mess it is and you figured out how I’m going to organize this mess that I’m in, and that led you to sort of architecture. And then you somehow, you mentioned that you were working on essentially an ERP system. Was that sort of what got you thinking about orchestration?

Bernd Ruecker: Oh yes. 100%. So I mean, part of what the system has to do is basically looking at the data address, kind of what orders do I have, what hardware do I have lying around and stuff? But at the same time, you also have to look at the processes, and that’s where we started, like the workflows, like the order fulfillment, like the returns good handling. These were basically the problems where we started, like how can we manage that process that it runs efficiently?

And also back then I started to look into that, I found it fascinating, and probably we can discuss that later on, as well, but I’m a big fan of visuals. I also was always a big fan of UML Class diagrams, for example, for structuring, and I looked into visuals for workflows. And back then that was not yet very well-developed, I would say. There were a couple of weird things happening. There was BPEL-

Michael Stiefel: I remember BPEL.

Bernd Ruecker: Okay, yes. Hopefully a lot of people forgot about that. But there was not really a good solution for these kinds of workflows, and that got me hooked into the whole question, but there should be. And even back then, there were two options I found. The one was going with super expensive enterprise software on a really complex tech stack, which was obviously not an option for that at all. And I looked at open source projects, and there were not many back then and they were super technical. But I looked into one, I got a contributor there, and I worked with that, actually, to implement the workflow within that system, basically auto-fulfillment and returns good handling. And that got me into the whole process orchestration thing, first of all, thinking about it, also in the community. Then I started giving a talk about that. That brought me into freelancing around workflow engines. And in a way that’s also the story how I co-founded a company that does process orchestration as a product. I stumbled into that, as well, if you will.

What is Process Orchestration? [05:40]

Michael Stiefel: Well, look, life, sometimes some people know where they’re going from day one and some people just stumble their way to success. But you said two things that were kind of interesting, and I want to sort of focus in on them. You mentioned process orchestration, and process orchestration is a type of distributed system, and distributed systems are becoming increasingly common in our world. We see them all over the place, but people still really do not understand when people are involved in the distributed system. And process orchestration is all about that. And why do you think people have so much trouble dealing with process orchestration?

Bernd Ruecker: It’s a very good question. To be honest-

Michael Stiefel: And you might want to define, just for our listeners who are not familiar with this, you might want to also define what process orchestration is.

Bernd Ruecker: Probably that’s a good first step. So process orchestration is basically getting order in certain steps you have to do. So you orchestrate those steps, you coordinate those steps, that’s kind of the wording behind that. And normally, then you have technology that can do that. And the way it works is you define models, like nowadays, it’s BPMN. I’m a big fan of BPMN, business process model and notation. It’s a graphical model. You define where you say, “I have those, for example, three steps I have to do in a sequence”. So I do the first step first. When that’s done, the next step is happening. And then you can run such a workflow engine or process orchestrator that can interpret those models and can run instances of that, like the orders I talked about.

And then they run through basically all those steps. And then the workflow engine makes sure that, if there are decisions on the way, there are complex patterns, like if you are waiting for too long, you should do something else or push something to a human and whatever. So that’s one thing, process orchestrators can interpret those models so you get a visual. And the second big thing is it’s also about long-running processes. So the process orchestrator can wait for things to happen, that’s very often a human, but it might also be an asynchronous answer from a system that takes longer or a response from a customer. So there are a lot of things where you might need to wait, and that’s what a process orchestrator can do. And then it’s normally like persisted and you have all the tooling around that, where you can see what’s currently happening, where are you waiting, and so on and so forth.

What Is So Difficult About Understanding Orchestration? [08:01]

Michael Stiefel: So what do people find so difficult about this?

Bernd Ruecker: That’s the question that also puzzles me for a decade now, I think. I think that there are a couple of perceptions around that. It’s a lot about perception, I think, because I started with visual models, for example. If you ask developers about visual models, very often you get a negative feeling around that. That’s true for UML Class diagrams, I never understood that. That’s also true for process models. And I make the case with UML first, because that’s probably what most people out there know, and a lot of people probably learned that in university and it’s a drawing, it’s like dead paper. Or you even had model-driven architecture quite a while back, where we tried to generate software out of these models, which never worked very well.

But I also recall when I started there was a tool, which was actually super great that where you wrote Java code and then you could just look at the code you wrote as an UML diagram, because it knows if I have a collection typed of that type, I can just make two boxes in the right arrow. So it was kind of a automatically documenting things, it was live documentation, and it worked the other way around, as well. You could add attributes there and it was adding that to the code. I found that so helpful to get an overview of what I was doing, and the same is true for these process models. They are so helpful at their executable code, so they are not a wishful thinking document, they are executable code, but they are readable by every human. And that does not actually have to be a computer scientist, it can be a business person, as well, it can be whatever. And that’s so valuable, but somehow developers are scared of these process models. That’s the first perception I see everywhere.

Michael Stiefel: I mean, some of that is sort of historical. After all, the original idea behind COBOL was that even a manager could program. I don’t know if you remember COBOL, but that was one of the first computer languages developed, and of course, that was an utter failure, from that point of view. I mean, COBOL is used all over the place from the idea that that would be obvious. I think some of the fear programmers have, and I remember from when I used some of those visual tools, is sort of the paradox of programming.

Normal engineers, or a civil engineer, can essentially spend their entire career conceptually building the same bridge over and over again. But in software, if we want to build something new, we reprogram it all from scratch, because if you want another copy of Microsoft Word, you just copy the bits and you’re done. You only undertake a programming project if there’s something new to do. But the technology that we’ve automated is based on what we knew in the past. So there’s a disconnect between what we could automate in the past, but the fact that we’re doing something new that we never did before and that the tools are not capable of doing that. And that’s the frustration I had when I used some of those visual modeling tools.

Bernd Ruecker: Yes. But I would look at it from a different lens. For me, it’s really a little bit of a different view on the same thing. I mean, you can write code in whatever, Java, Node, or C#, it’s also an abstraction. You don’t write it on whatever assembler level anymore, right? And the same is for BPMN, for example. It’s a language that’s defined exactly how it should behave, and then you express problems with that language on a different abstraction level, but it’s still general purpose. You can model whatever you want to model there. And the other thing people forget then very often is you’re not, especially if you could use good tooling, that’s probably, again, something a lot of vendors did pretty bad in the past, but if that’s flexible enough or developer-friendly enough, you can say, “There is an SPI, there is a hook where it can hook in code, if I don’t get any further with BPMN, then I simply just code it”.

But there are certain elements in BPMN which are great for expressing long-running problems, and I simply should use them because that’s what I see on a weekly basis, at least. Otherwise, people start implementing their own homegrown, bespoke workflow engines without knowing it. It’s the, “Oh, we just need that order status column in that table over there”, but we have to monitor that. We write a small schedule looking at that every day and then we do this and that, and they start to build workflow engines. I see that so often, and it always starts with, “Oh, we don’t want to have the complexity of an additional component”, but you have the complexity of that mess you wrote.

Michael Stiefel: Plus, you’re rethinking something from scratch and not getting the benefit of other people’s experience. So that raised something also interesting that makes me think about the low-code movement. So in other words, when you use a system such as this, you’re trying to minimize the amount of code that a developer has to write, which is generally a good thing.

However, when you’re trying to figure out why the system is not working, do these orchestration engines, or whatever you want to call them, get in the way of understanding what’s happening? Are they too much of a black box?

Bernd Ruecker: Let’s say the core engine itself should be a black box. I mean, even if you have the source available, you could look into that, nobody wants to do that. I mean, I recall times when I debugged into Hibernate, that’s nothing you ever want to do just because you can.

Michael Stiefel: Yes, I’ve done that. Yes.

Bernd Ruecker: So I would say overall, that it should a black box, and that’s good as it is. But it’s, again, very general purpose, so if you have a good product there, the core should work and it’s not… I mean, it’s still complex to get that right, especially at scale, for example. But what it does, from looking at it from the outside, is not that complicated. So it basically triggers certain activities, and that’s either connector, which is code, or it’s your code, so it’s normally not that big of a problem. So you still have the possibility to debug into things, for example, that you just don’t debug into the core engine, you debug into what you made out of that, basically the activities you put into the process. You have the possibility to write automated unit tests, for example. So that’s not gone because you used such an orchestrator.

Michael Stiefel: I guess what you’re sort of saying is that we write stuff on top of the operating system, and we don’t step into the operating system.

Bernd Ruecker: Yes. Yes. Yes, you’re right.

Michael Stiefel: And there are bugs in the operating system, but I guess what you’re saying is we look at them sort of as a, this system is supposed to X, it doesn’t do X. We have to call up the vendor and understand why that is the case.

Bernd Ruecker: And I mean, overall, it’s a bit like also the cloud discussion, “Oh, we can’t put that in the cloud. Is that secure?” I’m 100% sure it’s more secure than what most companies do at home.

Michael Stiefel: Yes, yes, yes. The only interesting thing about the cloud, just as a side issue, as you mentioned it, it just builds a more tempting target for someone to hack.

Bernd Ruecker: Probably, yes. Yes.

Michael Stiefel: Yes. Willie Sutton, who was a very famous bank robber, and he was asked why he robbed banks and he said, “Well, that’s where the money is”.

Bernd Ruecker: True, it makes sense. But at the same time, if you compare using a product that’s built for that-

Michael Stiefel: Obviously. Yes, yes, yes.

Bernd Ruecker: And used in a lot of organizations, it’s probably better than just code it yourself. Yes.

Michael Stiefel: Yes, yes. But again, when you’re dealing with human fear-

Orchestration vs. Event-Driven Architectures [15:44]

Bernd Ruecker: Yes. But honestly, the typical objections are not about, “Ooh, is my software still stable?” It’s very often about, “I don’t need that component”. It’s still that belief, because it’s so simple, my problem is so simple. It’s not. And probably because people are not really looking into, let’s say, the full scope of process orchestration, like on an enterprise level, that’s a different topic we should probably look into. And the one thing, and that kept me actually busy for a couple of years, discussing orchestration versus choreography, basically. The whole thing, do I want to control what’s happening, or do I want to let it evolve by pushing events around, for example?

And there was a belief for quite a while, I think it changed at that moment, but there was a belief that event-driven is so much easier to do. It’s so much more decoupled. It’s better, or probably more beautiful or modern or whatever you want to call it, architecture. And that led a lot of projects into we don’t need orchestration. Orchestration is kind of bad. They brought that together with, oh, centralized bottlenecks and whatever, and that’s 100% not true. And that’s another perception we saw there where people deliberately didn’t want to go into the orchestration route, especially out of IT, which is kind of weird.

Michael Stiefel: Yes, it is. But you’re not arguing against event-driven architectures altogether?

Bernd Ruecker: No. No. So my point is there is a place for event-driven and there is a place for orchestration. Basically, both are typically about different components or services communicating their way back to the distributed system. Because in my whatever, order fulfillment process, I need to talk to the CRM system, to the ERP system, to the stock, to the whatever, logistic system, so I need to get all those pieces together. So the question is how do those components interoperate? And with orchestration, basically I have one component that has the duty, the responsibility, of orchestrating the end-to-end process and saying, “Okay, the first thing I have to do is, for example, getting the stuff from stock or retrieving the payment”, and so on and so forth. It can control that, to some extent. With event-driven, with the choreography, you basically distribute that responsibility, saying, “There’s an event, the order just came in”, and then some component knows, okay, then I have to collect money.

And that’s an architecture question, actually, one of the core architecture questions, how do you want to distribute responsibilities amongst the components? And that’s a design choice you can make. And there are sometimes good arguments where you want to be event-driven, and there are sometimes good arguments where you want to be orchestrated. And especially if I look at these typical business processes, like order fulfillment or whatever, I want to get a new bank account, I want to get a claim settled or all these kind of business processes, then you very often, from a business perspective, you want to have somebody responsible for the end-to-end, because the customer is only happy if the parcel arrives at my door. It doesn’t look at how beautiful my events are flowing within, just if I get my stuff here or if I get my money paid out or whatever, then the customer is happy. So there is a big emphasis on the end-to-end and understanding certain KPIs (Key Performance Indicators) and bottlenecks and everything on the end-to-end level.

And because of that you want to have one owner, and because of that you should have also on the IT side probably one personal, one component being responsible for that. And if you want to help that component responsible for something, it needs to control certain aspects, like the sequence of things for example, or the SLA. What happens if the logistic provider doesn’t talk back to me within two hours? Is that okay or not? And deciding all these kind of factors, that’s an architectural decision, and that’s… To make a very long answer short, it depends on how you want to lay out the system, and in most bigger systems I see a coexistence of both event-driven and orchestration.

Michael Stiefel: Where do you see, ideally speaking, event-driven should predominate in your architecture choice?

Bernd Ruecker: Every time when the component that triggers something is not really responsible for doing it. I’ll give you one example, I like examples. I find that much easier to understand, and it’s actually one thing I discussed with Sam Newman regularly. He wrote these microservices books, and he has an example also of an account opening in his book and I have an account opening in my book, so that’s a good collision of examples. And basically, what I look at from an orchestration perspective is the whole the customer applies to the bank account, for example, is opened because that’s a responsibility of one component, one microservice, if you will, or however you want to implement that, and that should be orchestrated.

He looks at, okay, the customer needs to be put into the loyalty points bank, he needs an account there, he probably needs a whatever letter, and certain things that are not in the responsibility of that core opening process. And then events are great because then you could just push an event on the bus saying, “Hey, the customer is created”. And then it could build different components reacting to that saying, “Okay, then we do this, but if we don’t do that, nothing happens”. The bank account is still open. Your COO will not come to you basically asking you, “Why is it not on the loyalty points bank?” It’s a different responsibility, and this kind of trade-off, I think, is very important to think about.

The Real Problem Is Most Systems Are Architectural Spaghetti [21:19]

Michael Stiefel: So, if I could summarize what you said in sort of a sentence or two, and tell me what I’ve got it right about, it’s basically, from a business perspective, where the responsibility lies?

Bernd Ruecker: Yes. Interesting side note here, while this is one of the things, I think, on a conference level I discussed the most over the last years, it’s still, when I look into our customer base, it’s not the predominant problem. It might be discussed, but the predominant problem is that they have an integration spaghetti there, where systems are talking to each other in a totally uncontrolled manner and you have no way of really extracting the end-to-end business process. It’s already hard to understand it, which makes it almost impossible to adjust it, and that’s a big, big problem at the moment because there is so much change. You might want to drive customer experience, you might want to add new services, you might want to infuse AI everywhere, and they have mostly no idea how the process is currently running and they can’t touch it. And I think that’s a much bigger problem at the moment, to be honest.

The Public Does Not Understand How Fragile These Systems Are [22:26]

Michael Stiefel: Yes. Well, it’s also a big problem from the public’s point of view because they don’t understand how fragile these software systems actually are. I don’t know if you’re familiar, for example, in the United States there was this, the security vendor for some Microsoft systems had a bug, and this caused tremendous outages in the airlines and, especially Delta, took days to recover, and there’s all kinds of finger pointing going back and forth. But the public really doesn’t understand how hodgepodge or fragile these software systems are, and you seem to, when you talk about this from the IT perspective, I don’t think upper management sometimes realizes how fragile these systems are. Do you have any feeling about this one way or the other, how to explain this to people, whether upper management or the public?

Bernd Ruecker: But I think that’s, honestly, one of the, let’s say, core areas where we also look at when we talk about business processes and process orchestration, because it’s exactly that connection between business and IT. The IT side is implementing the process, okay, but the business side needs to understand the end-to-end process. And if I talk to the business, they have different language. They talk about whatever business model canvas, customer journeys, value streams, and these kind of things. We can get also the business to level where we talk about an end-to-end business process and probably business capabilities. And then we want to link that to implementation, and the process, for me, is one of the key elements to do that because that’s also what a business person understands. And then as soon as you have that running, you can even link data to that, yes.

The Architect is the Translator Between Business and IT [24:12]

Michael Stiefel: You hit on one of what I think is a key role of an architect, because the architect is the person who can talk to the business people about business and the technical people about technology. They’re sort of the interpreter of the two different worlds.

Bernd Ruecker: Yes, 100%. When you ask about architecture, what always comes to my mind first is I think there are still different levels to an architect. So I started, I would say, as a solution architect, looking at a single solution only, which is a bit different to looking on an enterprise architect or in the business architecture level. But I totally agree, especially the latter two should be able to, I like the Gregor Hohpe metaphor, actually, of the architect elevator, that you have to ride the elevator up and down, from the engine to the penthouse and you have to be able to talk to all of them.

Michael Stiefel: Which means that one of the skills of an architect is, even if because of their generalization they lose some of their technical chops, they still have to keep their intuition about what is technically right and wrong.

Bernd Ruecker: I agree, and I’ am still a big fan, I mean, I also do a lot of discussions nowadays about business value, for example, express business value, and I understand why it’s so important to do that, right? At the same time, I try to program, probably not on a daily basis anymore, but at least a weekly basis. I need to touch code very regularly to, exactly, keep that feeling what you’re talking about, so yes, 100%

Michael Stiefel: Yes, yes. Good. So you mentioned about processes in the enterprise and you wanted to get back to that. Is there anything that comes to mind when you think about that?

Bernd Ruecker: I think I touched on that briefly. So what we are currently seeing is a lot of change in organizations. That’s probably not news. AI or agentic AI, or whatever the buzzword of the day is, puts a lot of pressure, and we see organizations struggle with that. And what we also see them doing, if you look at it from an enterprise perspective, very often they try to optimize things in local areas, like in that one application or I use a, whatever, robotic process automation bot over here, I want to use that AI tool over here. But very often that’s local because that’s how the teams are siloed in that organization, very often the business teams. And then they start to do projects which, on a local level, might make sense because they have an ROI, oh, we automated that, we saved manual labor, there’s a ROI.

But zooming out, and that’s what a lot of companies miss, zooming out, looking at these end-to-end processes, it doesn’t have to be necessarily good what they are doing. Either it doesn’t have any influence on the overall end-to-end process, it can even cement certain bad behaviors, bad patterns, like making it harder to change that overall process, and it definitely not looks at improving it end-to-end. There are tons of examples. So we have seen, for example, AI to do support requests you could save if you make the overall application process much smoother, for example. And then, of course, you should invest there and not making the support better, even if that looks good on an isolated basis.

And all these kind of local optimizations, I think, are a huge problem. So we need to elevate that discussion to understand that value stream and the business process, and for me, process orchestration is kind of the key element to make that happen because it can actually look at the process and make the connection to really executable software and then orchestrate different pieces, different tasks, together. And that’s super powerful if you look at that on an enterprise level. So not so much in my local project, how can I orchestrate the process better? We have that, as well, but really look at it more holistically. And that’s what we are currently doing with quite a couple of customers, which is super interesting.

Michael Stiefel: I don’t know if you’re aware of this or not, but this is actually a broad economic phenomenon. I don’t know if you’re familiar with something called Pareto optimization, but the argument there is very much the one that you mentioned, is that if you want to optimize something and you can’t do local optimizations, you generally have to reoptimize the whole system to get an incremental optimization. And what you’re describing actually fits into a larger economic system, and you seem to say that process orchestration is a way of forcing that issue to the front.

Bernd Ruecker: Yes. And it’s a way of probably solving the riddle, at least to some extent. I mean, that’s not the only piece, but I think it’s a centerpiece. And it’s something, again, which you can make a CIO or a CEO or a COO understand because business process is not-

Michael Stiefel: A foreign language.

Bernd Ruecker: I think that’s one problem of the microservice community, for example, it’s discussed in IT, IT only. If I go to a business process, business capability level, I can talk to business, as well. And that’s a different thing because you need them. I mean, that’s actually why the business exists, so you need them, and that’s saying me as kind of an engineer by heart, you need them, of course, on board to make transformation happen.

The Technology Is Fun Trap [29:24]

Michael Stiefel: I think, in my career, I’ve had the same experience, that it’s amazing how many of the technology people think in terms only of technology and don’t understand the business reason for doing something. After all, it’s the business that’s paying, it’s the business that’s driven. I mean, yes, I’m fascinated with technology, too, but the idea is in service of a goal.

Bernd Ruecker: Yes. I totally agree. I thought about that quite a bit, as well, because for me it was kind of a transformation, a journey, I would say, personally because I was super nerdy and enthusiastic about technology for a long time.

Michael Stiefel: It’s fun. Technology is fun.

Bernd Ruecker: It is, and I loved it. I mean, we did a cross-orchestration engine that can scale on geographically-distributed data centers without adding latency, but we still have the same throughput, for example, so that’s obviously awesome and exciting.

Michael Stiefel: But you tell that to a business person and they go, “Duh”.

Bernd Ruecker: Yes, it’s like, “Duh”.

Michael Stiefel: Right.

Bernd Ruecker: On georedundancy, they might understand, but not how we did it.

Michael Stiefel: Right.

Bernd Ruecker: But I still had that progression, I would say, to understand why business value is important, and then also starting to understand how you can explain that better. Because very often it’s an indirect story you have to tell why this technology enables this, what it can do in a software application, and that will basically increase whatever customer experience, and then you can talk to them. And that’s so important, and probably, I would say, it’s a typical journey a lot of people run through, and I think it’s probably a good thing. I want to keep all those enthusiastic 20-years-old people that love technology. They are awesome, and we need them.

Architecture and Development are Two Equal Roles [31:05]

Michael Stiefel: And maybe some of them will stay that way for 40 years.

Bernd Ruecker: Yes, it’s also fine. Yes, yes, yes, true.

Michael Stiefel: I think it’s a mistake to think that everybody has to become an architect. To be a super developer is great, too.

Bernd Ruecker: It is. It is. And for me, for example, I did a very conscious decision not to go into people management. And for me, that architect, for example, is also a path you could take where you say, “I don’t want a people manage, but I want to get to a broader view”, and have kind of whatever, probably making bigger decisions, if you will.

Michael Stiefel: That must be tough running a company.

Bernd Ruecker: You have to find the right co-founder. Again, a piece of luck I had in my life.

Michael Stiefel: But also, it’s important to explain that story to the technology people, why they can’t fall in love with this piece of technology, and they have to do it maybe the old-fashioned way because that’s better for the business.

Bernd Ruecker: Yes. It’s not always easy. You probably know that there’s a blog post called Choose Boring Technology, or something like that, and that’s what it’s very often about.

How Do You Train Developers? [32:06]

Michael Stiefel: Yes. So two questions that sort of come to mind, and they’re separate questions, but I think they’re things that you’ve touched on that are important, how do you train developers? If developers have trouble understanding when to use events and choreograph and when to orchestrate and distributed systems and asynchronous systems, how do you train new developers to understand this?

Bernd Ruecker: There is, as always, nuance to that. So there are things where I just think people have to be made aware just by trying things out, and that’s, I would say, for the smaller problems, for example, mastering asynchronous communication, having probably consistency problem, like transactional problems, long-running things, those you can occasionally train by doing examples, probably let them writing things, probably review stuff, so that-

Michael Stiefel: And wonder why their system’s hanging.

Bernd Ruecker: Yes. I even personally learned the trouble of two-phase commit early on in my life in a real-life scenario. I mean, that’s something that sticks with you afterwards. So that’s okay. I would say the bit more architectural questions, the bigger, hairy ones like event-driven or orchestration, which might influence not only one communication link, but probably how you lay out the whole architecture, that’s probably not for a newbie. That’s probably something where it’s good to have some experienced people on board. We very often do coachings, but when I talk to people, it’s very often architects that already have seen something, otherwise it might be hairy.

Michael Stiefel: So sort of what you’re saying is that gradual exposure to increasingly more complex situations is basically the way people learn?

Bernd Ruecker: Yes, probably. I would say so.

The Importance of Visual Tools [33:51]

Michael Stiefel: And the other thing you talked about is sort of your love, if that’s too strong a word, but your appreciation of visual communication and visual tools.

Bernd Ruecker: Oh, I would say love is a good word.

Michael Stiefel: Okay. I think, given that people very often don’t appreciate this, and I know from the work that I’ve done with workflow and the little work that I’ve done with process orchestration, visuals are very, very important, especially with long-running processes that you can’t necessarily get in your head completely.

Bernd Ruecker: Yes. It’s even a problem that you can express very well with visuals. It’s a flow of activities, probably some different path, then there are events happening where you go somewhere else, so it’s a problem that fits well on a visual. And to be honest, I don’t get it why people are so against it. And every time, when I discuss a process with people that don’t like visuals, what they do first is take a whiteboard and draw it.

Michael Stiefel: Yes.

Bernd Ruecker: It’s like, because otherwise you can’t follow. So I personally don’t get it. And then sometimes get arguments like, “But how can I do diffing?” Yes, you can do visual diffing. I’m not sure if that’s the most important question, but you could do it. So no, I just don’t get it.

Michael Stiefel: There’s a limit to the amount of complexity the human mind can conceive of, and they’re not linear processes, necessarily, and there’s feedback. It seems almost perfect for a diagram.

Bernd Ruecker: Yes, I agree. And same thing, and probably you need different levels of abstractions, for example, you can do subprocesses or certain things that might happen you might want to handle in a different process or some things you might still want to handle in code, so you can play with that. It’s one tool in your tool belt, and if it fits, it simply should be used.

The Architect’s Questionnaire [35:39]

Michael Stiefel: Yes. So one of the things I like to do to ask all the architects that appear on the podcast is the architect’s questionnaire, which gets into the more human side of being an architect. So what’s your favorite part of being an architect?

Bernd Ruecker: I think I said that relatively in the beginning, seeing the big picture. Not going super deep in one element, but understanding the different pieces and how they are connected. Probably also how they are connected to business strategy, how they are connected to the technical implementation, so I think that’s my favorite part, I would say.

Michael Stiefel: So what is your least favorite part of being an architect?

Bernd Ruecker: To some extent, that’s probably also connected to my current role, which means I’m very often talking to a lot of companies, but always as an external. And I think that’s also true for architects in organizations, so you’re not part of the team typically. You’re very often an outsider, which I can live with, but it’s probably the one my least favorite thing of it.

Michael Stiefel: Is there anything creatively, spiritually, or emotionally about architecture or being an architect?

Bernd Ruecker: I love that question. I mean, the creativity part, I think it’s clear. I think it’s super creative. You have to very often find elegant solutions for very complex problems and make or communicate them in a way that they’re easy to understand. That’s very creative, and I love doing that. It always makes you a little bit happy if you see that this seems to be understood and works. And the spiritual or emotional element, it’s probably harder to answer, but for me it’s, again, I would say happy is kind of the thing. If you see that it’s working out, if you see that people are understanding it, if you see that whatever you draw helps people understand things or implement that, it’s just a good feeling.

Michael Stiefel: The world is a little better off incrementally. What turns you off about architecture or being an architect?

Bernd Ruecker: I would say it’s the, there is a typical perception around architects also being kind of the naysayers, the no-sayers, the governance entity, the police, if you will, which I think is not true, at least not for good architects at all, but it’s kind of the one thing very often I hear.

Michael Stiefel: Do you have any favorite technologies?

Bernd Ruecker: That’s easy. Of course, BPMN. Of course, Camunda. I contributed to a couple of other workflow engines in the past, as well. So there it’s great technology. Otherwise, I would say simply also programming. So I am a Java person, I started with Java and I like Java. I like the type languages, to be honest. I like the dependency management, I like the tooling, the ecosystems, the open source around it.

Michael Stiefel: What about architecture do you love?

Bernd Ruecker: Probably repetition. I would say breaking things down into manageable pieces, solving a complex problem. I would say that’s more or less it.

Michael Stiefel: And what about architecture do you hate?

Bernd Ruecker: Discussions. Too long discussions, too many discussions, not fruitful discussions. I know it’s part of the thing, and to some extent I like it and it makes things better, but at some point in time it’s too much.

Michael Stiefel: What profession, other than being an architect, would you like to attempt?

Bernd Ruecker: I haven’t found any so far. I mean, co-founding the company, I had a couple of roles in the past, but it always was architecture related, to be honest. I think my absolute favorite was kind of what we now call a solution engineer doing proof of concepts, like flying into the customer three days, get something to work in their environment, and leave. You don’t have to finish it, but you can draw the boxes to sketch the idea and prove that it really works, so that was always my favorite.

Michael Stiefel: Do you ever see yourself as not being an architect anymore?

Bernd Ruecker: Probably, let’s see. I mean, what I said early on, what I experienced at the moment is that I had that phase of my life that, I would say 10 years, where I was so into enthusiastic about technology. When I was at a conference I picked up something, some keyword I had to Google that, I could try it out. I was sitting in the evening in the hotel room hacking something to understand it. To some extent, that changed a little bit, probably also with family and kids and whatever, not so much time, and seeing that generation is still there doing that, probably now with AI and stuff. So I kind of foresee to probably do more mentoring than architecture actively myself, but not yet.

Michael Stiefel: And when a project is done, what do you like to hear from the clients or your team?

Bernd Ruecker: When I read the question, my first thought was, it’s not really an answer, but my first thought was, don’t make any more projects. Go into the product thinking world, that’s where you should be, actually. So a product is never done. If you do software, it should be kind of a product, it should be maintained, it should be a life cycle, it should keep doing things. So that’s one thing. But I totally get the question.

So the other thing, and that’s probably, again, because of my time in my life I’m currently, I would like to hear from them what’s the value of what we just did? What’s the story that connects it to the business value? What could we tell everybody in the company why we did what we just did, and why is this great? I think if they achieve that, for me, that would be even better than, quote unquote, just having a great technical solution.

Michael Stiefel: Well, thank you very much. I found this conversation fascinating, and I think you’ve illuminated many dark corners for people about both orchestration and how to think about architecture, so thank you very much.

Bernd Ruecker: Thanks for having me, Michael.

Mentioned:

SG Americas Securities LLC decreased its position in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 44.2% during the 3rd quarter, according to its most recent filing with the Securities and Exchange Commission (SEC). The fund owned 2,501 shares of the company’s stock after selling 1,985 shares during the quarter. SG Americas Securities LLC’s holdings in MongoDB were worth $676,000 as of its most recent SEC filing.

Several other hedge funds and other institutional investors have also bought and sold shares of the company. Transcendent Capital Group LLC bought a new position in shares of MongoDB in the fourth quarter valued at $25,000. MFA Wealth Advisors LLC bought a new position in shares of MongoDB in the second quarter valued at $25,000. Sunbelt Securities Inc. boosted its position in MongoDB by 155.1% during the first quarter. Sunbelt Securities Inc. now owns 125 shares of the company’s stock worth $45,000 after purchasing an additional 76 shares during the period. J.Safra Asset Management Corp boosted its position in MongoDB by 682.4% during the second quarter. J.Safra Asset Management Corp now owns 133 shares of the company’s stock worth $33,000 after purchasing an additional 116 shares during the period. Finally, Quarry LP boosted its position in MongoDB by 2,580.0% during the second quarter. Quarry LP now owns 134 shares of the company’s stock worth $33,000 after purchasing an additional 129 shares during the period. Institutional investors own 89.29% of the company’s stock.

Insider Buying and Selling

In other news, CRO Cedric Pech sold 302 shares of MongoDB stock in a transaction on Wednesday, October 2nd. The stock was sold at an average price of $256.25, for a total value of $77,387.50. Following the completion of the transaction, the executive now directly owns 33,440 shares in the company, valued at approximately $8,569,000. The trade was a 0.00 % decrease in their ownership of the stock. The sale was disclosed in a document filed with the Securities & Exchange Commission, which can be accessed through the SEC website. In related news, CRO Cedric Pech sold 302 shares of the business’s stock in a transaction dated Wednesday, October 2nd. The stock was sold at an average price of $256.25, for a total transaction of $77,387.50. Following the completion of the transaction, the executive now directly owns 33,440 shares in the company, valued at $8,569,000. The trade was a 0.00 % decrease in their ownership of the stock. The transaction was disclosed in a filing with the Securities & Exchange Commission, which is available through this hyperlink. Also, Director Dwight A. Merriman sold 3,000 shares of the company’s stock in a transaction dated Tuesday, September 3rd. The stock was sold at an average price of $290.79, for a total value of $872,370.00. Following the completion of the transaction, the director now owns 1,135,006 shares of the company’s stock, valued at $330,048,394.74. The trade was a 0.00 % decrease in their ownership of the stock. The disclosure for this sale can be found here. Over the last three months, insiders have sold 15,896 shares of company stock worth $4,187,260. 3.60% of the stock is owned by company insiders.

MongoDB Stock Down 0.4 %

Shares of MongoDB stock traded down $1.12 on Monday, hitting $291.74. The company had a trading volume of 55,119 shares, compared to its average volume of 1,448,723. MongoDB, Inc. has a 1 year low of $212.74 and a 1 year high of $509.62. The company has a debt-to-equity ratio of 0.84, a quick ratio of 5.03 and a current ratio of 5.03. The stock has a 50 day moving average of $265.14 and a 200-day moving average of $287.15. The stock has a market capitalization of $21.40 billion, a price-to-earnings ratio of -104.22 and a beta of 1.15.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its earnings results on Thursday, August 29th. The company reported $0.70 earnings per share for the quarter, beating analysts’ consensus estimates of $0.49 by $0.21. The company had revenue of $478.11 million for the quarter, compared to analyst estimates of $465.03 million. MongoDB had a negative return on equity of 15.06% and a negative net margin of 12.08%. The company’s revenue for the quarter was up 12.8% on a year-over-year basis. During the same quarter last year, the company earned ($0.63) earnings per share. As a group, sell-side analysts forecast that MongoDB, Inc. will post -2.44 earnings per share for the current year.

Wall Street Analysts Forecast Growth

A number of equities analysts have commented on MDB shares. Tigress Financial reduced their price objective on shares of MongoDB from $500.00 to $400.00 and set a “buy” rating for the company in a research report on Thursday, July 11th. Wells Fargo & Company boosted their price target on MongoDB from $300.00 to $350.00 and gave the company an “overweight” rating in a research note on Friday, August 30th. UBS Group boosted their price target on MongoDB from $250.00 to $275.00 and gave the company a “neutral” rating in a research note on Friday, August 30th. Scotiabank boosted their target price on MongoDB from $250.00 to $295.00 and gave the stock a “sector perform” rating in a research note on Friday, August 30th. Finally, Needham & Company LLC boosted their target price on MongoDB from $290.00 to $335.00 and gave the stock a “buy” rating in a research note on Friday, August 30th. One equities research analyst has rated the stock with a sell rating, five have assigned a hold rating and twenty have issued a buy rating to the stock. According to MarketBeat, the stock has a consensus rating of “Moderate Buy” and a consensus price target of $337.96.

Read Our Latest Report on MDB

MongoDB Profile

(Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Read More

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a “Moderate Buy” rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

Which stocks are likely to thrive in today’s challenging market? Click the link below and we’ll send you MarketBeat’s list of ten stocks that will drive in any economic environment.

Get This Free Report

Like this article? Share it with a colleague.

Link copied to clipboard.

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I’m sitting down with Adam Kentosh. Adam is a field CTO of digital AI and, Adam, a good starting point is who is Adam?

Introductions [01:03]

Adam Kentosh: Thanks for having me, Shane. Really, really appreciate the opportunity to be here. And just in regards to who I am. I’m a technologist at heart. I’ve spent over 20 some odd years, or close to 20 some odd years in technology, really cut my teeth on Hadoop, large scale Hadoop clusters, managing those with automation and purpose built for custom search algorithms. From there, went into the consulting business and had an opportunity to work with some Fortune 20 companies around the area, especially as they were transitioning from things like VM based architectures into cloud, containerization, Kubernetes, et cetera. From there, I went into HashiCorp. I was able to join HashiCorp very early on and got to experience just the really exciting growth that happened at that organization.

And now I’m at Digital.ai as a field CTO, and I’m helping to bridge the gap between the field teams and the product and marketing teams, making sure that I’m taking back anything that I’ve learned in the field to the product teams for potential enhancements or improvements, and then also back to the marketing team as we’re thinking about how we can have messaging that resonates with our customers.

Shane Hastie: We’re talking about shift lift and DevSecOps and so forth. Isn’t this an old, tired topic that’s dealt with already?

DevOps is a well understood approach, but still not implemented in most organisations [02:27]

Adam Kentosh: It does feel that way. We’ve been talking about this, I think, for quite a while. Even back in 2009 when I was still fairly young, I was doing work and we had conversations around Agile and what does DevOps mean to us? And at a point in time in my career, DevOps was essentially me sitting next to a developer as an operations person. Certainly not probably what we would think DevOps is, but just the fact that they moved us into the same room, they thought, “Yes, we’ve done it”. So I think we have seen obviously good evolution here. Just one interesting thing that I find fascinating though is I was reading the state of DevOps report in 2023 and they mentioned that 80% of companies are still in mid-transformation. And I just find that really interesting. I mean, I think we started talking about this 2009, 2010 timeframe, and a lot of companies really kicked off those initiatives between probably 2010 and 2012.

We’re now 10 to 12 years in on DevOps transformation and we’re still talking about it. So I think that just begs the question, why are we still talking about it? And for me, that’s a very complex, I’d say, question and complex problem. I think we’ve seen DevOps transformation happen at the team level, but I think that sort of enterprise-wide transformation is still very elusive to a lot of customers. And I’d probably pin the reason on technology changes and disruption. If we think about what’s happened over the last 10 to 12 years, not only did DevOps come around, but we also had really the just maturity of cloud. And then we’ve also had mobile devices become the number one way for customers to interact with applications these days. And so in that situation, I think that we offered up some autonomy to teams and we said, “Hey, go pick your tools. Figure out how to take advantage of cloud. Go pick your tools, figure out how to create a mobile application”.

And with that, we gave them what we would consider a DevOps team, and we paired dev teams with operations teams and we said, “Go forth and conquer on the technology that you choose”. And I think that was great for a time. It really did help people pivot. It helped people accelerate and have kind of speed to market and get better velocity. However, as you think about trying to scale that across the organization, well now you’re very challenged. It works for maybe five to 10, 20 teams. But when you start talking about hundreds of teams, we have to figure out where we standardize, right? Do we standardize at the tooling level? Are there processes that we can standardize around? Is there team makeup or structure that we can standardize around? So I think we’ve just had a compounding problem that was getting worse simply by, I’d say, the introduction of new technologies over time.

Shane Hastie: How much standardization is enough? As a developer who was given this freedom, now you’re taking it away. How do I come to terms with that?

The balance of standardisation vs team autonomy [05:35]

Adam Kentosh: I see two options, and I’ve seen this in practice at a lot of organizations and done it personally at a few. But number one, you don’t. And you build a interface layer on top of that and you’ve got something that basically integrates with all of these different technologies. Because really when we start thinking about standardization, it’s not so much that we necessarily care about what tool they’re using, it’s that we care about the metrics that we can view of that. How are my teams performing? Are they delivering at the rate that we would anticipate? Are they having more or less bugs than other teams? So I think the thing that really matters for me is sort of the metrics that can be driven out of that platform and then being able to level teams up, “Well, if we have a bit of an underperforming team, how do we take them from a two to maybe a five?”, for instance.

And I think DORA has done a great job of setting a framework and a context for us to have a level up type methodology. And so we’ve got four or five metrics. We can take a look at how that performance is across all our organization, and then we can focus in on specific areas. So I think the first approach is you don’t bother with standardization and you just care about the metrics and you figure out a way to gather those metrics and then help your teams perform better. I think the second approach is probably what we’re seeing materialize, is something like platform engineering where, “Hey, let’s create developer-oriented tooling. Let’s create standard interfaces and APIs that can be leveraged so that we can obviously make things either more productive or we can reduce just some toil from a developer standpoint”.

I feel like either one of those are viable options in many cases, though certainly I think as a business there’s probably more viability in getting some level of tool standardization. They still have to operate as a business, they have contracts that they have to worry about. There’s a lot of negotiation and renewals and things that happen to enable those contracts. So from their perspective, if we can get it down to a reasonable amount of pool set that does get the job done, I think there’s probably usefulness in that.

Shane Hastie: So finding that quite difficult balance. The other thing that certainly you and I mentioned in our conversation earlier, but also I’ve seen a lot is as we have done the shift lift, we are seeing more and more cognitive load on developers today.

The impact of cognitive load on developers [08:04]

Adam Kentosh: Definitely. It’s very interesting. There’s been a couple of reports that have come out. GitLab has published a report just around global DevSecOps and GitHub has done a lot around developer experience and what that means today. And in both cases, the numbers were somewhere between a quarter to 32% of developers time is spent actually writing code and time is spent elsewhere now in terms of maybe improving existing code or doing administrative tasks or meetings or testing or securing your application. So I think as we think about shift left, what we’re really doing is we’re putting a lot of strain and stress on a developer community and we’re asking them not only to write code, but understand how to test that code and then understand how to secure that code and then understand how to go release it and also maintain the operations of that code over time.

So for me, it puts a lot of pressure on the development teams, and I think that’s why developer experience is becoming so important these days. I’ve heard a ton of just conversations around developer experience. We work with customers that now have titles for the VP of developer experience and their initiatives is to go make sure that their developer community is productive, that they have good impact and that they’re satisfied. So I think a lot of the reason that we’re seeing developer experience sort of come around today is simply because we are putting a lot of strain and stress and pressure on the team as we continue to progress through these shift left motions.

Shane Hastie: How do we reduce that but still get the benefit?

Adam Kentosh: That is a very good question. I’d say ways that I’ve seen it be reduced and probably the most effective means of reducing it, is truly having more of a product centric approach. So we’ve seen two things, I’d say, happen over the last few years. Number one, we asked the developer to do everything, and that obviously breeds challenges. Number two, we continue to have isolated silos for testing and for security. And that again, causes challenges. Maybe we see a reduction in velocity because now I have a handoff between development to testing and then there’s a handoff between testing and security. So depending on which way you go, you’re having issues no matter what.

And I truly feel that we probably need more of a product-oriented approach, meaning that the product teams have to have these capabilities on the team themselves. We still need testing, we still need security, we still need development, but I don’t think one person needs to do all of those things. And if we can get them closer working together, more collaborative, I think we’re going to be in a much better situation.

And if you look at some of those surveys that I mentioned, it was really interesting because a lot of what the developers were asking for was better collaboration. And I think this would breed not only better collaboration, but probably a more productive product team.

Shane Hastie: But haven’t we known that collaborative cross-functional teams are the way to do things, since 2001 at least?

Adam Kentosh: We have definitely known that. I would totally agree with you there. I still feel the challenge is the organizational structure is matching the team structure, and so we’re seeing a dedicated testing organization or we’re seeing a dedicated security organization, and now we run into the people process aspect of our challenge where people don’t want to maybe give up control of the teams that they’re working with. And so the idea of blending teams means that we have organizational changes that must take place, and that, I think, is probably what’s restricting or limiting, I think, this type of approach. Inevitably we get in a situation where, like I said earlier, we either fully shift left and we have developers owning more of that delivery or we just continue to deal with our silos because it’s almost easier than trying to reorganize a large enterprise.

Shane Hastie: What are the small nudges we can make that move us to a better developer experience?

Small nudges for better developer experience [12:22]

Adam Kentosh: The best thing that I’ve seen work for nudges is really still the idea of trials, targeted use cases, where we can actually take a product-centric approach to a team and let them go be successful. And if they can be successful and we can validate that their numbers are what we would anticipate, that they’ve got great cycle time, that their bugs in code are not there or they’re infrequent, I think that gives us justification then to say, “You know what? This is a working model. This is an opportunity to work together better, and it’s a way that we can improve our overall performance as an organization”.

So for me, it’s always in doing. I think, in getting out there and actually trying out new models and then making sure that it’s a model that can scale. So come up with some best practices and actually be able to take that back to the organization and show real results and real numbers behind it. I feel like that’s probably the best way that I think we can continue to nudge, otherwise you’re in a position where you’re trying to nudge at an executive level, and that can be maybe far more challenging.

Shane Hastie: We’ve known this. As an industry, we’ve figured this out. We’ve seen organizations that have done this well, and yet 80% are still mid-transformation. We’re still facing a lot of the same problems that all of our methodology changes and everything that we’ve tried to do over the last couple of decades. Why don’t we learn?

Finding the optimum delivery frequency [13:58]

Adam Kentosh: Well, first off, I’m racking my brain to say, “Have I seen an organization that’s done it well?” And I suppose that the flagship examples are maybe your FAANG or MAANG companies, I guess now, but to me they’re operating at a different level and they also seem to be producing a lot of this content around some of the more progressive types of development approaches. So if I think about that, and I’m getting off-topic a little bit, but we’ll get back around to it, but I think about that, they’re pushing and asking for continuous delivery. Let’s just be able to deliver on a continuous basis, small incremental chunks. And I think for the vast majority of organizations that I work with in terms of financial services, insurance companies, even some level of gaming, definitely airline, I mean, those companies don’t necessarily care about delivery frequency.

They’re purposefully pumping the brakes on delivery because they want to make sure that they’re compliant, they want to make sure that they’re secure, and they want to make sure that they’re not introducing a poor customer experience with the next release that’s going out the door.

So in reality, I’d say there are companies I suppose, that do it well, but there are other companies that just maybe don’t need to do some of this. And so being pragmatic about what is useful and what will resonate with your organization, and truly at the end of the day, what outcomes you care about. If you care about new features and keeping pace, then certainly maybe continuous delivery makes sense for you. But if you care about stability, well, maybe it doesn’t. Maybe there’s the better way. And I’m not advocating that people go back to a completely waterfall style of delivery and that we take six months to get a release out the door. That’s certainly not, I think the case here, but I think technology has enabled us to take a more, let’s call it reasonable approach to delivery, and then also still be able to get better quality, more secure applications that can go out the door.

So I know that was sort of a little bit of a segue or a long way away from what your question was, but just something I was thinking about as you mentioned that. Now back to what you were asking, “Why don’t we learn?” I think that the challenge is from a developer standpoint, and you’ll see this too, if you talk to any developer, one of the things that they really enjoy is just the opportunity to learn new things. And so when you go to a developer and you say, “Hey, we want you to take on testing”. “Well, hey, that’s interesting. I’ll go learn that new thing for a little while”. Or, “We want you to take on release pipelines”. “Oh, interesting. I’ll go take on that new thing for a little while”. So I don’t think they’re shy about saying, “No”, or I guess they’re happy to say, “Yes”, rather and say, “Yes, I want to go learn new things”.

So for me, I’m not going to pin it all on the developers. It’s certainly not all their fault, but we’re asking them to do the more, we’re giving them an opportunity to learn new things. That means professional development, it means new skills. That’s something that they’re always after, so they’re just going to go do it and they’re going to solve a problem. And I find that true for most engineers. I talk to my wife and she always wants to just kind of talk at me, but I always want to solve the problem that she’s talking about. And so it’s hard for me to stop trying to solve a problem, and sometimes I have to recognize I just need to listen. But I think that’s just an engineering mindset. You’re always looking to solve a problem. So maybe we run into a situation where the problem’s been identified and nobody’s doing anything about it and they just go fix it.

So why don’t we learn? I think that’s probably the biggest reason from an individual standpoint. From an organizational standpoint, to me, this could be controversial, but I just feel that maybe organizational structure has not evolved the way that we need it to evolve to support IT. And I know IT is supposed to support the business, and we’re supposed to ultimately support the outcomes for our customers. And I definitely recognize that. But internally to the CIO on down who owns testing security and other things, maybe there has to be an evolution there that helps support better collaboration and maybe a more product oriented or product focused approach.

Shane Hastie: One of the things that struck me when you were talking about the contrast is those companies that are held up as doing this well, they have a product mindset and they were built from the ground up with the product mindset. So are we asking our “traditional” organizations, these banks, insurance companies, airlines and so forth to fundamentally shift their business model?

The challenge for non-product focused organisations [18:50]

Adam Kentosh: It sort of feels that way. Now, you can say that those companies are obviously wildly successful, so maybe it makes sense for them to try to shift their business model. But to your point, when you’re not built that way from the ground up, there is organizational structure, of course, organizational politics that are going to come into play, there is certainly a level of skill from a just perspective of people that are working there that you have to take into consideration. And so with that, I think that we might be asking companies to act in an unnatural way. And so if we’re asking them to act in an unnatural way, I think that’s where you get… And we’ve seen people get into the situation, as I’ve mentioned, where shift left is now the term, and DevSecOps is definitely still a term in trying to get everybody to work together in a meaningful way without actually maybe changing who they report to or putting them on the same team, truly together.

So the way that they’re trying to evolve is maybe not necessarily conducive to the way that some of these organizations just grew up from the ground up.

Shane Hastie: Adam, there’s a lot we’ve delved into here. What have I not asked you that you would like to get on the table?

Software engineering intelligence [20:07]

Adam Kentosh: I’d probably say, what is the role of something like platform engineering or DevSecOps and how important is Velocity truly to companies and organizations? And I think Velocity has ruled for the last 10, 15 years. Everything was about getting code out the door faster. And in reality, I think taking a deliberate approach to software development is probably more meaningful. And let’s focus not so much on Velocity, but let’s continue to focus on the outcomes that we want to deliver for our customers. And again, that kind of goes back to, what is my end goal? Is it a stable customer environment or is it a stable application environment for my customers to operate into? And if so, well then let’s just be maybe thoughtful about how we deliver software. And then from a platform engineering standpoint, I think there’s value in the idea of platform engineering, but I actually think there’s probably almost more value. I shouldn’t say more. There’s equal value in the idea of something like a software engineering intelligence platform.

And Gartner coined this term back in March, and it’s kind of interesting as we start to think about it. But if you look at software development, you’ve got to plan what you’re going to build. You’ve got to code it, you’ve got to test and secure it, you’ve got to operate that. And historically we’ve purchased solutions inside of each one of those areas, and we have engineering processes inside of each one of those areas that have to happen. And that all generates data into its own database. And that’s great for business intelligence. It gets us some information from an agility standpoint or an Agile standpoint. We can look at things like cycle time and figure out how our teams are doing.

However, when I want to ask real questions as a business leader, when I want to understand how teams are performing across the organization, when I want to understand what changes are coming down the line that are really risky or when I want to understand what teams have the biggest impact to cycle time across the organization holistically, I can’t answer those questions with that type of approach.

So for me, I think the next evolution that we really need to see, and it’s going to set up AI initiatives inside of an organization, which is why this is also important, is the idea of unifying all of that data into a meaningful data lake and then putting engineering processes in place so that we can link the data together. And what I mean by that is if I’m doing a release and I’m not opening up a ServiceNow ticket or some type of tracking for that, well now I can’t tie an incident back to a specific release. But if I could, that would be very helpful. And if I can tie a release back to specific stories or features that are actually getting into that release, well that’s also very helpful. I still talk to customers every day that spend hours on change advisory board reviews, and they spend hours on tier one resolution calls that they have to jump on, and they’ve got 80 developers on there. So if it’s a situation where we can reduce some of that, that breeds value to an organization, certainly.

So I think the important thing is being able to measure where we’re at today and being able to unify that data to answer meaningful questions about my organization, then that sets us up for truly applying artificial intelligence and machine learning on top of that data set to help make recommendations. And that’s really where I think people want to get to over the next two years as we talk about AI and ML.

Shane Hastie: A lot of good stuff here. If people want to continue the conversation, where do they find you?

Adam Kentosh: So you can find me on LinkedIn. You can definitely reach out to me as well. I’m happy to have a conversation and talk anytime. I love chatting about this stuff. I’m also very happy to be disagreed with. So if you disagree with what I’m saying, I’d love to hear a counter perspective. I’m fortunate, I get to talk to probably 50 to a hundred customers every year, if not more. And a lot of those are in that large enterprise space. So hearing other perspectives outside of that is extremely valuable for me and helps me understand what are other companies doing, how are they doing it well? And so Yes, LinkedIn is definitely the place to go.

Shane Hastie: Adam, thanks so much. Been a real pleasure to talk with you.

Adam Kentosh: Thanks, Shane. Appreciate the time today.

Mentioned: