
Episode 37
Simplifying solutions architecture with Brian Johnson of Booz Allen Hamilton

Brian Johnson
Sr. Solutions Architect at Booz Allen Hamilton
Consulting firm Booz Allen Hamilton plays a pivotal role in keeping federal agencies including the United States Department of Defense and the VA on the cutting edge. In this episode, host David Joy is joined by Booz Allen Hamilton’s Sr. Solutions Architect, Brian Johnson, for a discussion on the exciting, intricate world of data analysis as well as expert insights on solutions architecture.
Join as we discuss:
Brian’s extensive global career that spans test engineering, software architecture, metrology, and his time in the military.
Demystifying the approach to problem-solving and technology selection.
Scalability, risk assessment, and the suitability of architecture frameworks.
David Joy:
What is up, everyone? Thanks for tuning in. In today’s episode of the Big Ideas in App Architecture Podcast, we speak to Brian Johnson, who is a senior solutions architect at Booz Allen, working with Veterans Affairs. Brian and I talk about his early career, to some really interesting work that he has done at Fan Gene in Europe as well as Booz Allen, to getting into some of his perspectives of cloud and scalable infrastructure, to his design philosophy for architecting big applications that are always on. Pump up that volume and get ready for an intriguing conversation with Brian Johnson.
It’s always fun talking to amazing people who have done some interesting things in their career. For people listening, Brian, you’re obviously a senior solutions architect right now. You’re working at Booz Allen, and we’ll get into that. But you’ve had a really interesting career, working across multiple companies in your tenure at multiple organizations. It’s fascinating to see how somebody starts somewhere and gets to where he is. But without butchering your introduction as to who you are or what you do, why don’t you let the people know what you currently do, what’s the hap right now?
Brian Johnson:
Sure. As you mentioned, I was a senior solution architect. Just since the last time we talked, David, I’m actually an enterprise architect now. I made a slight pivot to a little bit more strategic role, a little bit less implementation time but I think it’s where I’m really needed and happy to be there.
But I’ll say, as far as just a little bit about myself, again my name is Brian Johnson. I’m an enterprise architect, formally senior solutions architect here at Booz Allen. I hail from sunny Tampa, Florida. I’ve been at Booz Allen for about two years now, working in health technology. Booz Allen’s a really big company. We’ve got over I think 30,000 people at this point. We do a lot of management consulting, a lot of technology consulting. Booz Allen’s big thing is focusing on government consulting. I think while Booz Allen’s highly ranked among all the consulting firms, I’m pretty sure we’re number one when it comes to who is helping the DOD and federal agencies really learn how to best use technology and apply it in ways that they really need it to stay cutting-edge.
David Joy:
Yeah, that’s awesome. I have a few friends who work at Booz Allen and have heard great things about what you do. As well as in conversations around blogs or products that you guys have done that’s publicly available, that’s really fascinating.
One interesting thing that I saw in your career, you worked at Honeywell as well, and you’ve had this fascinating career where you’ve even worked in Europe. Obviously, we should talk about all those interesting things. You worked as chief architect with Fan Gene Retail Services, if I’m not wrong. We’re going to get into all of that today.
What I really wanted to ask you was how did a young Brian Johnson decide to choose this as a way to make bread?
Brian Johnson:
Long story short, I was really into computers. I was born in ‘79, so I really came of age in the early-mid ’90s. I think it was the perfect time to be born, in my perspective, because you got to see was life was like without the internet and social media. When we had 30-foot cords on the telephone, so that you could run and have a private call in your bedroom. At the same time, the computer boom was coming out.
I remember sitting at the public library … Anybody that’s maybe in their mid-40s like me remembers the really thick computer shopper magazines that were almost the size of phone books that you would flip through. It was almost like a Sears catalog, that you would call up and mail order custom-built computers from and such. I really wanted to go into computers. I taught myself C, I think at 16, because clearly I’m a masochist. Well, you got to remember, back then there was no YouTube, so I was pulling academic textbooks from the library to try to remember this. When O’Reilly came out with Practical C, that was a godsend to me.
I did that, and I really wanted to go into programming, but there were no programming jobs. Honestly, whereas now, I think working in IT is much more of a meritocracy, back then, it didn’t matter how good I was at C, if I didn’t have a degree already, I wasn’t getting a job. What was available to me, just broadening things out a little bit technology wise, was that I went into electronics.
Life was a little rough for me. My father passed when I was only 18, so college really wasn’t an option for me at that time. I joined the military, and I joined as an electronics technician. I got some great training, got to travel quite a bit there. I was stationed in Puerto Rico, where I met my wife, that we’ve been together, oh my goodness, since 2001 now. Yeah, I had a good time there. I got out, worked for a defense contractor for the Air Force, doing much of the same thing. As I worked in digital electronics and high frequency electronics, and I specialized in electronic measuring systems. It’s almost, you could say, like IOT before IOT, because most IOT is focusing measurement assisting and you’re just communicating those measurements.
Worked in that for a while and I loved it. Yeah, I was doing programming, but it was more like lower level, C type custom hardware, digital electronics. Think microcontrollers, more than actual microprocessors. When I was at Honeywell, I actually decided to go into operations management and program management, because I wanted to … I knew that I could do a pretty good job with that. We had someone step away and I had an opportunity to step up, and I did it. I had a lot of fun with that. I was still very much in an engineering mindset, but it’s like how do we model these management practices and things like that.
I think the big pivot was when I had an opportunity to go to Europe. They wanted to hire me, say chief architect … They wanted to call me the CTO, but I thought that was really pretentious, so I’d said, “How about chief architect or something, guys? That’s a bit much.” I told them, I was very upfront, I’m like, “Guys, I just want you to know, web and mobile application development, not the same as what I’ve been doing.” But you know, they’re a bunch of VCs, they’re like, “Oh, you programmers are all the same. You’ve got a good attitude, come on.” Who was going to turn down a good job, getting the opportunity to travel across Europe and work with a lot of the Europeans, and a lot of cool technology?
And hey, succeed or fail, I was in a position, living the startup life, where I had control over everything. I will say to anyone that’s listening, if you are one of these just hungry, hard-charges that wants to learn everything and do everything, startup life is rough but man, you will experience growth. It’s almost like, I look at my time at Fan Gene and running across Europe with these startups almost like my military career. In so far that A, I got to travel a lot, I had some good times. I had some bad times. But that was a time of tremendous growth for me, both professionally and personally.
After six years, Europe was cool but it was getting a bit much. I wanted to be home more. That’s when I started looking to do something much more permanently stateside so I wouldn’t have to travel to Europe so much. That’s where I found Booz Allen. I will say that, and no one’s pushing me to say this, I will say that Booz Allen is my home. I don’t plan on going anywhere. It’s a really great company. I have a really great boss, I have really great people that report to me, a really great team. I can’t say enough positive things. There’s a real reason why Booz Allen’s consistently ranked as one of the top places to work.
David Joy:
I remember when we first met, you were talking about how that whole experience of working at a startup culture, and especially in another country, it was a very fascinating beginning.
Let’s dive into that a little bit. Why don’t you walk us through how your experience was with Fan Gene? What kind of problem were they trying to solve and what was your exposure to the problem, and how did you go about it?
Brian Johnson:
When I first got put in Fan Gene, I was working … They had a brand they had developed called SuperGuud. It’s S-U-P-E-R, but then Guud is G-U-U-D. It was this brand and they were running basically high end sandwich shops. They were focusing on retail inside the Swiss train station. Core reason why they hired me was that they were really breaking records. I think they had the most sales in the shortest amount of time they’d ever experienced with the Swiss railways. However, the costs were a little bit out of control. They basically just tasked me with, “We need to understand how to see our costs and how to track our sales.” We needed it in realtime. Basically, “Whatever it takes to make sure that we can get costs under control, so that we can get the absolute best money for this company.”
The whole expectation was to buy out. There were multiple buyers, including Velora, who was the retail market leader in Europe, who was eventually the person who bought SuperGuud from us.
David Joy:
Yeah, yeah, yeah. I was thinking, while you were speaking, especially I’ve got the opportunity to work in retail. I got to spend some time with Walmart. I was busy when I was working with their Sam’s Club team. I had a bunch of friends who worked on the actual store cart and checkout stuff. It was fascinating to see and I had not known about this until I worked in retail. That pretty much everything that retail has to do comes down to consumer data and how to improve the customer data experience, but that then drives demand and that drives more people to your retail stores.
I would attest to this, that when I have been in Switzerland, it definitely feels like the place where you are basically transporting yourself from one place to other feels like a mall, feels like a luxury experience. Definitely makes sense that that’s a segment that you were focused on and data was something in the middle.
It’s very interesting. You worked on a retail problem, and then a social problem, but all related to data. There are challenges in building these systems. What were some of the challenges that you observed initially? Because obviously, you’re getting into a startup, the scope is very unclear. What’s your mechanism to go through asking the right questions and getting to building a solution, and things like that?
Brian Johnson:
The difference between solution architecture and application architecture is you’re not just fulfilling a story or an epic. It’s not that you just build this system to spec. You can build a system to spec as a solution architect, but if it just doesn’t deliver on the value that the customer wants, they don’t care or they don’t think you’re that great. They’re not impressed with your technology, they’re only impressed with what it can do for them.
When I’m solutioning a problem, I can really simplify it down to about four things. That is, when it comes to this problem’s space, who are the people, what are the processes that those people are executing to accomplish whatever they’re trying to accomplish? What information is each step in that process consuming and producing? Then, let’s see, the technology. The technology, that could be an app they’re using to complete a step in the process. This could be a barcode scanner that they’re using in a warehouse to do something. What is the technology?
I usually start with the process, but if I know who the people are, I just go to the people. Okay, “What processes, where are you at? Are these processes defined? Do we need to sketch them out?” Once I sketch out the processes, I can link each step of those processes to one or more people. I can know exactly what technology is needed in that step, what data information is consumed, produced in that step. Then, you really start to get a holistic view of the problem.
Now if it’s a smaller, confined solution, I may stop there. Once I have that to get my head on straight, then I can start talking about okay, hey do we need to go full blown do a DoDAF writeup for this? Is this the type of project that justifies that, because the risk and the money is just too great? Or is this no, that would be total overkill and a waste of time, we should just stick with this?
I want to say, all those architecture frameworks are great, but I will say is start with a problem, understand the problem, and then think about how you can leverage that. Because the danger is if you start with that, then you just start going through the motions of checking the box of, “I made this diagram,” whether or not it’s really helpful.
David Joy:
100%. Yeah, yeah, yeah. I agree with that. I have noticed this many times, when somebody says … Some people say, “This is what I want.” Okay, “I want to this switch and monitor transsection.” Or they’re talking from an outcome point of view, an objective. “This is what I want to see.” Those same people struggle sometimes to quantify the problem. The art of being an enterprise architect or a solutions architect is helping someone who is in that position to define what his problem is. Obviously, you have these architecture frameworks that you can then apply. It was very well said, that the problem, finding the problem, defining the problem is amazing. Once you get to that, then you know okay, this is what we need to solve for. What framework can we apply? It’s fascinating to know that, I’ve spoken to other people, the methods are similar so well said.
Let’s jump a little bit more to what you’re doing right now. Obviously, congratulations on becoming an enterprise architect at Booz Allen. I know you’re working with the Veterans team there?
Brian Johnson:
Yeah. I work in health technology. This was a good pivot. Going back to that Cogvis AI, that was the first time where I really realized what kind of technology needs there are now and will be in the future in healthcare, and just what kind of help they needed.
I think one reason you see me jump around a lot in my career, to me it’s not jumping around, it’s always going where there’s a need. As long as it’s something I find engaging and I believe I can make an impact, I’m all for it. I think that in my first taste of healthcare technology was with the Cogvis project, and that’s why I was interested to work with Booz Allen and the Department of Veteran Affairs. There’s CDC and some other agencies like but, but myself, I work almost exclusively for the Department of Veteran Affairs. Which, I’m a veteran too, so there’s a lot of fulfillment coming from there on really helping the VA and their CIO, Kurt DelBene, achieve their digital transformation goals there, because achieving those digital transformation goals means better care for our veterans.
David Joy:
Yeah. I’m for that. I feel like it’s such an inspiring project, or a position that Booz Allen has, towards helping this cause. Obviously, veterans have gone through taking care of certain things through the process for the country, and it’s great to provide that service.
Now what I’m curious to know is how, from your experience at Fan Gene and the healthcare problem, what are the kind of challenges you see on the VA side of things? How do you go about addressing those?
Brian Johnson:
First off, there’s your general healthcare challenges. That is you have to learn things like HL7 and FHIR, F-H-I-R, which is a healthcare higher level wrapping of OIDC and Oauth. It gets specific in healthcare remember, because you don’t just say somebody has access to my health record, you say, “They can look at this, this and this, but not anything else.” It’s a little bit more granular, so learning those types of technologies.
I think, other than that, honestly what I see is what you would see in any enterprise. That is you have some of the things that are really nice and new, or maybe if they’re not brand spanking new, we’re still talking about .NET or SQL server or something like that, we’re not talking COBOL. In any enterprise that’s been around 25 years or more, they’re going to have some really old stuff. You’re going to be dealing with some really cool, realtime data processing using Kafka, but you’ve also got to handle legacy because there’s also servers that are going to be dropping off nightly files via SFTP triggered by a Cron job.
You can’t do it all at once. This is another thing … I’ll just pause to say that anyone that’s interested in some of the digital transformation initiatives at the VA, if you go to digital.va.gov, you can see, they basically advertise exactly the types of things they’re working on. A lot of it is how do we implement this new, cool technology while remaining where we can actually still connect with the upstream and downstream systems that aren’t necessarily maybe the newest, greatest. In fact, it could be a little old. I mean, it could literally be something that, non-critical system that hasn’t been updated in a while, and it can be written in COBOL. Where you’re doing a complete drop, where yes, you are getting data from upstream systems, but it’s SFTP.
I think there’s some great cloud services that make that a cinch. For example, in AWS, there’s AWS Transfer Service for SFTP, which basically gives you a serverless SFTP server that’s backed by S3. From the other systems’ perspective, it’s just another SFTP server. But now you’ve got S3, so when that file drops, you can now do event based things and trigger certain actions on those uploads. It makes connecting with those upstream legacy systems really nice, and clean, and neat.
David Joy:
Yeah. To analyze what you said is a problem, you’ve defined the segment of problems that many people are trying to solve. These old, legacy systems that need modern paradigms and modern solutions, and event driven architecture obviously is one of those ways to get realtime, on top of the experiences that you’re building.
Back in the day, honestly, if you had a system and the system was down for a few hours, nobody really cared. But now … Well, people would still care, but they would be like, “Well, this is how everything runs.” But the new standard of operating is realtime and I think it’s good to know that, even across government products and some of the things that you are driving as a company as Booz Allen, is helping enterprises move into that experience. Because at the end of the day, that helps the veterans because they have all their data, whichever they want to can see, available in a clean fashion in realtime, so that’s good to know.
I’m curious to hear, take an example of any product that you’re working on, whatever you can share with us. Let’s just say it’s a modernization project. How do you go about the technologies you choose and the direction you have to take, in terms of modernizing it? Obviously you’ve talked about LaMDA and your event driven architecture. What goes into that philosophy? What’s Brian thinking when he hears, “This is what we want do to, Brian, and you have a few months to get this fixed?” Something like that.
Brian Johnson:
Well, I think we’ve got reference architectures on both Azure and AWS. Sometimes, there’s more than one reference architecture you’re going to apply. For example, I’m hearing things like, “Okay, they want one or more web apps.” Okay, they need data processing. Oh, that data processing really is just historical, they don’t need a realtime component or not.
If you get certified as a solution architect on one or more cloud systems, you’re going to start getting familiar with those services. As you get familiar with them and know what they can do great, and what they maybe don’t do so great, that’s really going to help shape you’re way of thinking. I don’t know if that’s something I can convey. I can give you some examples, maybe.
For example, I just mentioned Azure functions. I have to do anything that has Kafka and I don’t have already on standby, an infrastructure team with experience managing Kafka. Kafka, for those people who are uninitiated, from a developer’s point of view, it’s amazing, everybody loves Kafka. From the infrastructure and management point of view, not so much. I don’t want to say you don’t have people that are gung ho about it, but it’s far more complex. One of the great things on Azure is Azure Event Hubs is a serverless Kafka. In fact, you can click a button to make it a Kafka compatible API, and now every library in Python and whatever your language of choice is, which has standard libraries for dealing with Kafka, guess what, they work and you’ve got a serverless instance. That’s amazing.
If someone’s using Cosmos DB and they want to go serverless. I mean, MongoDB or a document database like that. Cosmos DB is an amazing DB. It can simulate, it can pretend to be Cassandra, it can pretend to be Mongo. Again, for whatever language you’re using, you’ve already got standard libraries ready to use Mongo, you hook right up. It’s really, really nice.
Now let’s say, if I had a data processing type thing. Now I do like Azure Data Factory. It’s pretty good. But when it comes to pure function orchestration, AWS Step Functions, that’s definitely, I think that’s a really well done service over on the AWS side. If I know we’re going to be doing a lot of orchestration, we’ve got a lot of ETL processes that we need to monitor, Step Functions is the way to go. Not only from the development side, but once you move into operations, you go into that AWS Console and it’s got a very visual … It shows your visual workflow, you can click on a particular execution. It shows green light, green light, green light, red light. You can show exactly where you branched into it, where it went wrong. You can click on it, and once you click on that red one, if it’s executing a land or a container, it’s got a one-click link where it takes you straight to the Cloud Watch logs for that particular container or land.
When I’m helping to write up the documentation to support a system, writing up the operations manual and what to do when these types of things go wrong, if you’re using Step Functions, it’s so easy. Both from the documenting point of view and for that person that’s on the operations team that’s going to be following whatever you write up to troubleshoot that. That’s a really amazing service. That’s the S3 and Step Functions, they’re two of my favorite services on AWS.
David Joy:
Gone are the days where you have to struggle to scour and buy infrastructure, manage infrastructure on your own and be focused on that, while you have a problem with something. It divides your attention. If you’re a startup, or if you’re an enterprise, or if you’re a consumer or a user, at the end of the day, you want focus on the problem, and that’s what brings everything together from a business side of things as well.
Now while you were saying that I was thinking, there have been so many amazing changes that have happened in the last 15, 20 years, and some of the things you alluded to right now. We had to write our own databases, to using an Oracle database, to now you mentioned at least four databases in your previous statement. Now we have a plethora of databases available, data is one of those trends. From that evolved the AI story and whatever’s happening in AI. Same way with infrastructure, where we had systems of servers, and then we went to systems of VMs, and now we have systems running on containers, and EKS, and ETL. So many changes.
What are some of the trends and changes that you have noticed, that you personally have a little bit of an affinity to? Like, “Hey, I like this way more than what I used to like before.”
Brian Johnson:
Containerization is one of the main things, particularly from a developer point of view, or really from an operations' standpoint too, I think. It just makes life so much easier. I think everybody saw that. The fact that Docker didn’t really maintain market share was one of the worst management cases in the world, as far as missed opportunities. The technology itself was … Anybody that managed, both on the development side using something like Vagrant with VMs and deploying things that way, and then moving to container, it was so much more lightweight, it’s so much more nice.
Honestly, even in not part of the actual SDLC for a particular product, if you’re just playing around at home. You’ve never used Postgres before, you don’t have to install that stuff, just spin up a container. Play around with it. You can play around with InfluxDB. Spin up a container, play around with it. Then you don’t have to worry about, “Did I uninstall everything from my operating system after I’m done with it?” What happens if you want to change and play around with different versions? Again, containers just make life so much easier.
David Joy:
I agree, I agree. I don’t use containers a lot now because I’m lazy, more lazy now. Although I feel like having containers made sense, but I don’t get the opportunity to do a bunch of POCs right now. But when I did, I agree with you, it was so much easier for me to learn something new, there was a container available.
Actually, one of my first experiences of Cockroach DB was trying to look for a containerized version Cockroach DB to test stuff out and see how that works with the basic application. It’s been a fascinating change.
What are you excited for? Where are you looking towards, to see where this industry and technology is going? Tell me about that a little bit.
Brian Johnson:
Well, I will say in addition, because I was thinking about Cockroach DB. At Dremio and some other places, they have these things on AWS Marketplace. One of the things I really like to see is managed services from non-cloud vendors that are perfectly integrated into your cloud account. AWS, Azure, they do a lot of things really great but there’s some things that … You work for Cockroach DB, extremely popular. Dremio, in terms of a BI solution, is something I found really popular in the past. But that’s not necessarily Azure, AWS. But with things like AWS Marketplace and Azure has something similar, I can deploy those things out.
Really, I think we can attribute that to Kubernetes because most of the time, what people are doing is they’re deploying their own cluster, and then they’re just mapping it so you can connect to it in there. But having that managed aspect where I don’t have to initially give up on this product that I think has a great fit for the type of work I’m doing right now, but I can also get it in the cloud and I also don’t have to hire a team of data engineers or something like that necessarily, to make it to launch and to manage that rather complex infrastructure. Because the infrastructure definitely does get complicated the more you get into the data.
David Joy:
Yeah, yeah, yeah. No, I think you bring a really good point. It’s something that I’ve heard from many people, especially people who are in the cloud ecosystem but they’re also like, “Hey, I want to use this product. But again, don’t want to create a separate account.” I just want to use my AWS on my Microsoft account, create, or associate the credits this way, but it’s challenging. At first you request, in my opinion, entering info on the third party vendor’s site. But apart from that, what’s also difficult is that the AWS or the Microsoft ecosystem is way complex and you have to talk to teams, and build together.
I know there are so many successful integrations of that. We at Cockroach Labs have this kind of an integration with AWS and GCP. I’m not sure if we have with Microsoft. But it’s a challenging engineering problem because you have to scope out how consumption looks between two different systems. In a sense, how it looks on our side versus how it will look for the AWS is different and you have to map billings, and SKUs, and things like that. It’s pretty fascinating to hear that feedback from somebody who’s looking at solving these problems, because that’s a pain point. It’s great to hear. I believe that many people, including ourself, working on that. It’s pretty good.
Are you dabbling with any AI stuff? Are you looking at it and seeing how that can help you with some of the things that you’re working on?
Brian Johnson:
Clearly, we want to implement a lot of that but one of the big things about AI is when you get into, say protected company data, how can you use that AI without releasing maybe trade secrets or sensitive information? Now, that gets even multiplied when you’re talking about healthcare. I will say that we actually have dedicated people at Booz Allen that are figuring these things out. Most of my work related to AI right now is making sure, knowing what the infrastructure’s going to look like for ops training, ML ops training, that type of thing. And knowing exactly how we’re going to integrate this, at the portfolio and product line, in a way that makes sense so that when we are ready to really execute on certain things, in partners with our clients, like the Department of Veteran Affairs among others.
David Joy:
I always ask this question to people who have worked in multiple continents. I got the privilege to work in at least three continents, a bunch of countries. What’s your experience been and how are the approaches different? I know we are short on time, but I’m curious to know did you change your approach to designing and solving problems when you were in Europe to when you’re in the US? Is there any difference?
Brian Johnson:
When it comes to the methods at which we go to solve problems and things like that in Europe, I don’t think there’s much difference. Mainly because Europe really looks to the US for leadership, when it comes to corporate business and is the best practices, and stuff like that. I think when it comes down to culture, and communications, and manners and formality, there is a world of difference.
Funny joke, and it’s funny because it’s not really a joke. The first year-and-a-half I worked for Fan Gene, I was not allowed to email anyone outside of the company. The emails that I wrote would be perfectly acceptable and emails that I see my coworkers now writing in American business, but they would be like a slap in the face over there. I literally received emails that began, “My dearest Brian.” I don’t know how you were raised, but where I was raised, a man only uses my dearest to address three types of people. His mother, his wife and his daughter, and literally no one else. It was almost a little uncomfortable for me, how they worded certain things and certain formalities there. It was one of those things that I just …
I will say that as much as frustrating as it was in the beginning, by the end, I think I really grew a lot because of that. From being in a culture where manners don’t manner, manners really matter. Yeah. I like it a lot. I think my communications are better. I’m certainly less abrasive than I was before. I will say, as much as I’d like to say that Europe didn’t change me too much, I do cringe a little bit when I see my coworkers writing emails sometime.
David Joy:
I had a very interesting experience. Obviously, as an Indian working there, it was good to experience that culture. But I’ve noticing, just on the technical side of things, how mature things are becoming on both sides of the pond, technically. One of the things I’ve been noticing, apart from obviously the cultural changes, is that Europe is pushing towards a sovereign cloud. They’re saying, “We need a sovereign cloud.” AWS, and GCP, and even Microsoft, at least two of them I know have committed to sovereign cloud. That means that we’re going to keep data secure, and we’re going to make sure that as we scale, it’s going to be secure.
On this side of the pond, for us it’s about solving the problem, and making sure that we use whatever is available to solve it. We’re not really concerned about … Of course, we are concerned about security and things like that, but the objective is how can we solve the problem. Different way of functioning that I have noticed from my experience. I used to support and consult some of the clients in Europe side as well, so it was very interesting to see that and see that trend happening.
It’s been an absolute pleasure hearing what you’ve done in your career. I’m super excited to see what you’re going to do at VA. Booz Allen is definitely one of the companies where so many of my friends work, and they keep talking to be me about some of the amazing things that you guys are doing and the kind of spaces you are in, making a difference for the country and for the people.
Tell me this. If somebody wants to reach out to you or somebody wants to hear what Brian Johnson’s working on, do you have a blog or something, or a place where people can learn from you? Yeah.
Brian Johnson:
Reach out to me on LinkedIn. I’m not really big on social media outside of that. Anything, any blog posts I write or any videos I do, I’ll always link it right there on my LinkedIn page. Especially if someone hears this and they’re interested in saying, “Hey, I think maybe I’ve got what it takes and I’m really interested in what Booz Allen is doing, and I’d like to maybe think about getting a job there.” If you have any questions, hit me up, reach out. People do that all the time, it’s really not a big deal. I’m happy to offer my perspective and maybe point you to a few people or postings that might be a good fit for you.
David Joy:
For people listening who don’t know about Booz Allen, where can they go and learn about what the company is doing and some of the cool things that you guys are working on?
Brian Johnson:
Sure. Boozallen.com. That’s B-O-O-Z A-L-L-E-N.com. If you go there, right off our page, go to the about us, there’s an about us on the top right. There’s a careers, where you can check that. But yeah, you can find open job postings and all kinds of stuff, in terms of about us. A lot of it is not just some corporate little paragraph. They’ve got interviews with real Booz Allen employees, telling why they’re excited to do what they do.
David Joy:
With that, Brian, thank you so much for coming on and for sharing some of your story. It’s so difficult to condense everything that one has done, but you did a great job of explaining to us some of the things that you have worked on and your hopes for the future. Appreciate you taking the time. Thank you, everyone, for chiming in and listening. And thank you, thank you, Brian.
Brian Johnson:
Thank you, David.
A podcast for architects and engineers who are building modern, data-intensive applications and systems. In each weekly episode, an innovator joins host David Joy to share useful insights from their experiences building reliable, scalable, maintainable systems.

David Joy
Host, Big Ideas in App Architecture
Cockroach Labs
Latest episodes

Introducing Cockroach Continuum | A Big Ideas in App Architecture Exclusive
Tara Shankar Jana "TJ"
Senior Director Product Marketing @ Cockroach Labs

A Love Letter to the Database: Industry Shifts, Lessons Learned, and What's Next with Perry Krug
Perry Krug
Manager Solutions Architecture at Baseten

The Everything Trap: Building AI Software That Lasts with Sam Hilsman
Sam Hilsman
Co-founder and CEO of CloudFruit

Why Inference Engineering Is the Next Big Role in AI with Philip Kiely
Philip Kiely
Author of Inference Engineering | AI Education @ Baseten

Distributed Systems, Linkerd, and the Cost of Network Calls with William Morgan from Buoyant
William Morgan
CEO @ Buoyant, creators of Linkerd

Making Software as Durable as Data with Peter Kraft from DBOS
Peter Kraft
co-founder of DBOS

Breaking the Pillars: Rethinking Observability with Charity Majors
Charity Majors
Co-founder and CTO of Honeycomb.io and co-author of Observability

How to Transform Dev Workflows with CI/CS and AI Agents with Tomer Karin
Tomer Karin
Embedded Software Architect

AI, Market Cycles, and the Systems Built to Outlast Them with Cockroach Labs CEO & Co-founder Spencer Kimball
Spencer Kimball
CEO & Co-founder Cockroach Labs

How to Scale Data Infrastructure from Startup to Enterprise
Nishant Raman
Data Engineer at FinTech Company

How to Build an AI-Native Organization
Peter Mattis
Co-founder and CTO/CPO at Cockroach Labs

Inside Infrastructure as Code with Pulumi’s Founder & CEO
Joe Duffy
Founder/CEO at Pulumi

Inside Ericsson: How AI and Automation Are Shaping Telecom
Anand Bajaj
Chief Architect - 5G Network Slicing at Ericsson

Unboxing the Cloud: AI, Microservices, and Resilient Databases
Jim Hatcher
Solution Engineer at Cockroach Labs

Strategic AI and Cloud Solutions: GitHub’s Blueprint for Modern Development Success
Ari LiVigni
Senior Cloud Solutions Architect at GitHub

Cloud Architecture in the Public Sector: Balancing Innovation and Security
Nick Mayer
Principal Cloud Architect at Maximus

GenAI Meets Celebrity: Inside Cameo’s Journey from Startup to Stardom
Dom Scandinaro
CTO at Cameo

The journey from mainframe to adopting generative AI with Equifax’s Senior Network Architect
Samarth Shah
Senior Network Architect at Equifax

Modernizing your cloud strategy with OneStream’s Senior VP of Cloud Architecture
Ryan Berry
Senior VP Cloud Architecture at OneStream Software

Driving digital transformation with Chief Architect at Altimetrik, Ignacio Segovia
Ignacio Segovia
Chief Architect at Altimetrik

Discussing the Patterns of Distributed Systems with Unmesh Joshi
Unmesh Joshi
Principal Consultant at Thoughtworks and Author of Patterns of Distributed Systems

How to simplify your software architecture
Rob Reid
Technical Evangelist at Cockroach Labs

Behind the scenes with Vimeo’s Director of Enterprise Architecture
Sachin Joshi
Director of Enterprise Architecture at Vimeo

How to leverage real-time data processing for enterprises
Andrew Sellers
Head of Technology Strategy at Confluent

Inside the Mind of the Chief Architect at Index Exchange
Joshua Prismon
Chief Architect at Index Exchange

Solving for Scale: Real-time Retail Experiences with Endear's CTO
JP Grace
Endear

Data, Acquisitions, and AI: Insights from FiscalNote's CTO
Vlad Eidelman
CTO and Chief Scientist at FiscalNote

Discussing Data Trends in the AI Era
Gajanan Chinchwadkar
CTO at Hypermode

Unwrapping Moonpig: Architectural Insights into Personalization and Scalability
Alexis Lowe
Principal Engineer at Moonpig

Solving for data intelligence at scale
Madalina Tansie
Chief Technology Officer at Collibra

Simplifying solutions architecture with Brian Johnson of Booz Allen Hamilton
Brian Johnson
Sr. Solutions Architect at Booz Allen Hamilton

How to make your applications smarter
Rod Senra
VP of Engineering at Loadsmart

Scaling for 2 billion events per day with Principal Software Engineer at Red Ventures
Majid Fatemian
Principal Software Engineer, Data Platform at Red Ventures

The data behind digital marketing: A conversation with Bluecore’s Software Architect
Mike Hurwitz
Software Architect at Bluecore

A Lesson in Scaling: How Kami handled 25x growth with CTO and Co-Founder Jordan Thoms
Jordan Thoms
CTO & Co-Founder at Kami

Mastering Multi-Cloud with PwC’s Erol Kavas
Erol Kavas
Director at PwC Canada

From FedEx to Five Guys: Designing digital experiences with Yext’s VP of Software Engineering
Matt Bowman
VP of Software Engineering at Yext

Reliability and scalability in a data-driven world with Fivetran’s VP of Platform Engineering
Mike Gordon
VP of Platform Engineering at Fivetran

Enabling a data-driven and innovative engineering culture at Amplitude
Shadi Rostami
SVP of Engineering at Amplitude

How Estée Lauder scales strong engineering culture
Meg Adams
Executive Director of Platform Engineering at Estée Lauder

Can I take your order? Building conversational AI to improve the customer experience
Akshay Kayastha
Senior Engineering Manager at ConverseNow

Engineering resilient systems: Rescuing old treasures and unleashing modern capabilities
Marianne Bellotti
Author, Engineering Leader, Systems Geek

The Full Package: How Route architects its all-in-one post-purchase platform
Siddhartha Sandhu
Engineering Manager at Route

A historical journey in developer technologies
Mike Willbanks
CTO at Spark Labs

From Legacy to Cloud: Success stories from migrating mission-critical applications
Kishore Koduri
Senior Director of Enterprise Architecture at Ameren

Building purpose-driven engineering cultures
Jason Valentino
Head of Engineering Enablement at BNY Mellon

Modernizing Insurance Application Architecture at New York Life
Mike Murphy
Corporate Vice President and Life Insurance Domain Architect at New York Life

Innovation and Disruption: How Materialize pioneered a new era in data streaming
Arjun Narayan
Co-Founder and CEO at Materialize

Stories from an SRE: How Hans Knecht builds better developer experiences
Hans Knecht
Cloud Consultant at Knechtions Consulting (Ex: Capital One; Ex: Mission Lane)

Inside Chick-fil-A’s infrastructure recipe for a perfect customer experience
Brian Chambers
Chief Architect at Chick-fil-A Corporate

Modernizing from the Mainframe: An Exploration of Distributed Systems
Chris Stura
Director, PwC UK

IoT Standards & Data Mesh: Utility Facility App Architecture
Grant Muller
Vice President, Applications and Technology Architecture at Xylem

Relational Data Problems: Doubble Dating Application Architecture
Mattias Siø Fjellvang
CTO & Co-Founder at Doubble

From Legacy Systems to Limitless Scaling with Paycor’s Systems Engineering Fellow
Adam Koch
Systems Engineering Fellow at Paycor

How to Understand Problems & Build Better Software with Technical Leader Joe Lynch
Joe Lynch
Technical Leader

Observability in the Cloud & Dataflow Modifications with Yolanda Davis from Cloudera
Yolanda Davis
Principal Software Engineer, Data Flow Operations

Early Days at Google & Building CockroachDB with Peter Mattis
Peter Mattis
Co-Founder and CTO of Cockroach Labs

Database Benchmarking Efficiency with OtterTune’s Andy Pavlo
Andy Pavlo
Associate Professor of Databaseology at Carnegie Mellon and Co-Founder at OtterTune

Observability & Statelessness with TripleLift’s Chief Architect
Dan Goldin
Chief Architect at TripleLift

Understanding AI: PubNub CTO Stephen Blum’s Key to Faster App Development
Stephen Blum
PubNub

Building reliable systems with DoorDash's Matt Ranney
Matt Ranney
DoorDash

Real-Time Data Capturing: The Future of Fitness Technology
Paul Lawler
Head of Software at Wahoo Fitness

Building Efficient App Architecture with Alloy Automation’s Gregg Mojica
Gregg Mojica
Co-Founder and CTO Alloy Automation

Unleashing the Power of Hiring Software with Greenhouse CTO Mike Boufford
Mike Boufford
CTO at Greenhouse Software

Decoding Data Warehousing: Insights from Ken Pickering, SVP of Engineering at Starburst Data
Ken Pickering
Senior Vice President of Engineering, at Starburst Data