RISE UP AI Challenge -Day 2 AI Solutions Architecture

Hi, hello everyone. I don't know if there's an echo, y'all gonna have to tell me. Um, I'm gonna see if I can— I'm trying to like share screen. Hello, what's up? Are you here? Let's see, it says, oh, hi everybody. Let me know if you're here. I'm gonna take a look. I want to show you something real quick while we get everybody here. Welcome, welcome back. All right, here we go. There's no audio. I don't know if I even want to show you. Let's see, we'll see what happens. Let me go in. Has it started yet? You're not late, Joanna. You are here. Let me know in the chat if you are here listening to the sound of my voice. Type in live if you are here with me live. If you're catching this on the replay, you can put in replay so I know you do. Um, but also let us know where you're coming in from. Yesterday we had 37 countries, I think, showed up. So that was pretty cool. What's up, Kim? Good to see you. Hello, Afua. Um, one of the things, uh, I, I hear a little echo. Do y'all hear an echo? Is it good for you? Audio okay? Um, I have a very special, uh, opportunity. Uh, oh good, awesome, no echo. Awesome. Thank you, Joe. Always glad that you are here. I feel like, Joe, you're gonna have a lot to say in this, this session today. What's up? Good to see you all. All right, don't forget to let me know where you're coming in from. Listen listening live from Colorado, West Chester, Pennsylvania. I am here in Washington, DC for day 2. Tomorrow I will be back home, um, in warm— it's very warm here in DC. I don't know how many of you are in DC, it's pretty warm today, um, but I will be here, uh, as well. Um, I'm leaving tonight and we will be heading back home to Fort Lauderdale, so I'll be coming to you live. What's up, Boston? Good to see you in the house. Good to see you, everyone. Someone is here from Dubai, Los Angeles, we are all over, Chicago, all the big Cities represented. Michigan, where are you on, on the hand? Uh, Michigan is here. Hello from the Caribbean. Cincinnati, Ohio. I said this the other day, we have MidwestCon coming up very shortly. Nicole's here in Washington, DC, so hello. I'm right here. I'll be back actually. All of you DC fans, if you are in Washington, DC or the DMV area, you can come to an event. Uh, it's going to be held, it's actually a cybersecurity and risk event happening on the 10th and 11th, maybe 10th, 11th, and 12th. Anyway, it's happening here right in DC. I can get you a very special pass, so DM me on LinkedIn and I'll happily invite you. You can become part of my little entourage of people. So good to see you. What's up, Iowa? Miami's in the house. Charlotte, North Carolina. What? Bentonville? I didn't know that you were from there, Kim. There's some big there's at least a big company in Bentonville, Arkansas. So what's up, DC? Jonathan, good to see you. All right, awesome. Yes, I cannot wait till MidwestCon. Uh, Tristan's in the house. Good, excited to see you as well. New York, what's up? Um, so, so great to have you here. I always like to just give people a chance to, to get in. We started a couple minutes late, so sorry about that. I'm literally trying to get my iPad to connect to this device. I'm hoping it's gonna work out because a big part of what I was gonna do is this like live demonstration of me writing on the whiteboard. So let's just see what happens. Um, I'm hoping it's gonna let me, uh— oh, awesome! Oh, you might be, Nicole, volunteering for that DC event. I hope so. If not though, you're welcome to be part of my crew. We will not be volunteering, but we will be representing. So would love to see you there. Amazing. All right, maybe I have to accept myself. There we go. All right, let's see here. Um, hide camera, keep audio— no, I'd prefer not to have any audio whatsoever. All right, it says iPad. Let me just see, maybe I can share. I'm trying to see if I can share my screen. I don't see it. But yes, Shannon, yes, Shannon's event, exactly. Shannon Noonan, she runs High Noon, um, cybersecurity consulting organization. Very good friends, love the work that she's doing. So I'll be helping to support that event. I am the keynote, but I am them, you know, I think I'm pretty good, but she's got some major, major cybersecurity names coming, uh, representing the federal government, representing different, um, parts of the cybersecurity ecosystem. So if you're in DC, or hey, if you want to fly to DC and hang out with me, I will get you in. So send me a message, we can all go together and be super fun. All right, awesome, great to see you here. Welcome everyone. Okay, cool, I got this. Going. All right, so today, welcome to day 2. Today is all about AI Solutions Architecture, and it's probably my favorite day. Now, my husband and I spent the morning— and some of you, first and foremost, please check your inbox. Some of us are friends for the first time, we are emailing for the first time. My emails are getting trapped in your spam because we have not said we know each other in email universe. So please go in friend me, add me to your contacts so I can actually email you. I'm trying to send you some information. There are a couple really cool things that are going to be shared with you today. This is probably my favorite subject. I'm— I started my career in AI solutions architecture. I mean, I guess I should say in solutions architecture years ago, probably 2007, 2008 is when I first got my first role as a solution architect working for Red Hat. Loved it. It was my favorite job. It was— it had this— I don't know, being a solution architect, if you're not familiar with the term or the role, it's this really interesting blend of very deep technical expertise and the ability to communicate to business, to stakeholders, to executives, to, to the people that are actually going to use that solution. And I found like, this is where I realized it was okay to be an engineer who could communicate. Because many times, you know, some of y'all are engineers. We know, like, we tend to be fingers down, you know, fingers on keyboard, heads down, build, build, build. Um, and I, as you can tell, actually do like the idea of, of being able to come and, and, and not just build, but build and then share what I'm building. So some of you, if you're interested, you can go back to my, like, YouTube channel, Noelle AI. You can go look at my YouTube channel, and on my YouTube channel, if you scroll down to the very end or beginning whatever, if you scroll down to my older videos, some of my earliest videos are like 2008, 2009, 2010. Some of them are 13, 15 years old, but they're all of me kind of doing what I did as a solution architect, which is I would learn the technology, I would implement the technology, and then I would teach the technology. I would share what I was learning. And my career really has become an evolution of that very same skill set. And now I think it's important more than ever for you to have that skill set. So that's what this day is all about, is how to harness your own inner solution architect idea methodology. This will help you whether you ever become an SA as a profession. I think this skill set is really useful when you're interviewing for new roles, when you are communicating deep technical topics to stakeholders, to, you know, people who are going to buy your solution as a seller. I read a book, I think it was a book. I can't remember if it was a book or if this was a chapter in the book, but the chapter was called Sell or Be Sold. And it actually taught me this very important lesson that in every conversation that I was having as an engineer, every conversation, either I was selling— and you all have seen this probably in your own LinkedIn inboxes— either you're talking to someone and getting them to hear your ideas, or they're talking to you trying to sell you on their ideas. And this could be ideas, it could be products, it could be solutions. But in every conversation, someone's buying and someone's selling, and maybe it alternates in a conversation. But being a solution architect means that we dive in like intentionally into that conversation. We know what we stand for. We know what we represent. We know what we're trying to accomplish. And we stay on a very straight line to that outcome that we don't get distracted by, you know, shiny red buttons and moving squirrels, that we stay focused and how do we derive the most value for the person that we're talking to? And that, in my mind, is the best type of salesperson, right? Is, is the person who understands how to build a solution, but then is ultimately their goal is to get the best outcome for their customer or for their employer or for their family even. Right. So I approach all of my problems this way. It starts in my mind. As a, a problem. And immediately, almost immediately, I'm like, okay, how can I solve for this? What I'm going to encourage you today is the distinction between the essay I was in 2008 and the solution architecture-minded person I am today is this really wonderful evolution, of course, of large language models and generative AI and AI democratization as a whole. So I have taught a couple of different programs. I have a Maven class coming out in just a couple of weeks. Um, that is all about the deep technical side of this journey. So for some of you, maybe you'll join me there. I don't know if I opened the cohort. I'll probably open that cohort on Friday, so if y'all want to join me, you can. Last cohort sold out. I can't take a bunch of people because I need to make sure that I can actually talk to everyone. We did a free-for-all and opened up our cohort. We had over 150 people join our Agentic AI for Beginners course, and that was a lot. So, uh, so now I'm, I'm a little bit more interested in having kind of a smaller group of people, but that means that it'll likely sell out pretty quickly, but we'll open that up on Friday. And that journey though is all about what I have, literally all the things that make me good at what I do. And so I'm sharing that with you pretty candidly. Um, thanks Eve. Thanks Eve. So good to see you. Um, awesome. Uh, okay. Oh, me too, Nicole. We're probably the same, right? Where we're like, yes. Let's go. So pretty cool stuff. I'm really excited to be here. And we have so many solution architects in this audience in the LinkedIn. Now, I will tell you that this is broadcasting on 7 different channels. And so our chat is distributed. Yesterday we had over 300 people join us in the challenge. Hopefully today we will top that number because more people joined yesterday, which is very exciting. That means y'all are talking to people. So thank you for that. I'll also encourage you, every day is different in the challenge. So if you know somebody who wants to Just get started. And it doesn't matter how some people maybe naively say, oh, I'm already pretty technical, I don't need to be here. This isn't really about technical chops, right? Yes, of course there is some something to that, but I honestly do believe I can teach anyone the technical side. It is more about how do you get the solution into the hands of people who need it most? And that really is the combination of all the things that we're talking about. Yesterday we talked about adoption, the challenges to adoption. We're going to send you out the results of our VIP session, which were so cool, um, where we identified kind of what the most common barriers are across. We had over, uh, about 40 people joined, uh, in that session. So we broke out into 2 different groups, or actually 3 different groups, and talked about the barriers and the strategies and what made people successful, what caused people to fail. So the answers from that, whether you joined VIP or not, you'll get access to like the Cliff Notes version. I'll send that out to all of you via email. So don't forget, find me, find me and make sure that I am available to send you an email with all of these resources. Today, the AI Solutions Architect course that— I mean, it's a much deeper course. It's like 6 weeks. So that's a lot. But, but I created a guide. I called it The 21 Laws of AI Solutions Architecture. It was extremely popular when I originally wrote it. I put it out, you know, I just put it out there on LinkedIn and we had thousands of people download it. Lots of people reply with questions. So that ended up creating a video series on how to become an AI Solutions Architect. Also really exciting. It's about 7 videos. And so after this session today, I'm going to give you kind of the, well, the 1-hour version of that talk, of that session. But I'm going to encourage you, both of those things are free, right? The book is free. The video course is free, but it just takes more time because it's more in-depth. Today what I want to do is kind of COVID the top-line AI solution architecture principles that I care about the most. I'm gonna say 3, I might say more because I care about this topic and I might get crazy and do more than that, but that's my goal. Uh, we'll start with 3, maybe we'll get to a couple more. Uh, there are 21 laws that I have really embodied as a— now an executive. But all of these things have made me a better engineer, a better architect, a better salesperson, and a better executive. Like, they are all good skills. I feel like everyone really needs to embrace their inner AI architect, um, because at the, at the end of the day, this new world, this new world of artificial intelligence, of being able to use our words to create systems, like, that is an incredible opportunity, an incredible amount of power that we have access to. But when we do that, right, when we use our words to create systems, now all of a sudden we're using our words to architect solutions, whether we know we're doing that or not. And so the more systems planning, systems thinking, architectural design patterns that you are aware of and know, I think the more powerful your solutions can be and the more likely they will be to scale. If you don't know, I do have a book. I don't think I have it handy. No, I don't. But I wrote a book called Scaling Responsible AI. This is a section of that book. But we also, like I said, I have an ebook that you can download that's like the cheat sheet version, the CliffsNotes version of the solution architecture piece. I'll throw that link in the chat eventually. If Sherilyn's here, this is our 21 Laws of AI Solution Architecture. I'm going to try and pull it up as I see it and I'll throw it into the chat. See if I can get it. But yes, embracing your inner architect. I'm so glad. See, we're family. Many of us, we think these things, but sometimes we don't say it out loud because we're not really sure who we're with. But you are with family here. I think we all are, are on this journey together. And I'm so excited that you decided to spend some time with me. So the first AI solution architect— I'm not going to go by order in the book because I build a beautiful story arc in the book that's very intentional. But I'll give you a couple of my favorites. And one of them I think is, is a little more challenging than people realize. But the first principle that often comes to mind when I think about being a good AI Solutions Architect, it might surprise you. It is actually to be the most positive person in the room. Now, I have done thousands of client present— I mean, tens of thousands, thousands of client presentations, but more importantly, thousands of these executive presentations where the decision maker who can buy the thing that I am selling is in the room. And I'm not I'm not a seller, I'm an engineer. So my job is to say, look, this technology can solve your problem. Every one of us, like I said, sell or be sold. In every conversation, you're either selling yourself to a company to say, I can do this for you, I will be a good asset for you. Oh, amazing. Oh yes, that is my book. Thank you, Sherilyn. Um, I will be, you know, great asset to your organization. So as an employee, this skill set is important. Also, as an entrepreneur, this skill set is important. That's how you're going to equip yourself with joint venture partners, with, um, an system of providers, as well as of course your clients, um, and as leaders inside an organization, figuring out who you want to join your team and how do you find the right talent. These are skills you're going to want to look for. So when I say be the most positive person in the room, I literally do mean that. Most of you know me, some of you know me, um, and that is the, the vibe, right, is that when I walk in, I am the most positive person in the room. I am excited, happy, enthusiastic. People want to do business, want to work with, want to be around people that are positive and happy. I'm not saying you have to hide your authentic self if you are typically an Eeyore kind of person, if you're like into Winnie the Pooh, right? If you're like, you know, like typically kind of not excited. I'm just encouraging you that in a world that is transactional, when you are trying to create relationships and in the world of AI specifically, The AI I am seeing being sold and transacted, it is all happening human to human. It is not happening like no AI robot is calling and doing a million-dollar transaction. It is happening with humans. And so your ability to present yourself as a positive interaction in someone's day, here's the sad news, you might be the only positive interaction they have that day because that's just a bunch of nonsense going on right now. So that's number one. Make— set an intention to be the most positive person in the room. I went a little bit maybe further than that because I, when I was at Amazon Alexa— so those of you, I think you all know me because I invited you here, all of you. But in the case that you're not familiar, my journey into the world of AI started a little over 10 years ago. I'm joining the Amazon Alexa team. I mean, technically, I guess it started before that when I was on at Pivotal with big data, but I'm just going to call it Amazon Alexa. Because that was the first productized AI system that I really got a chance to put my fingers on and build. And in that journey, when I was there, my job literally was to architect solutions for a platform nobody really understood. And now we're all in the same spot with a platform like LLMs and ChatGPT and Gemini and Claude. Like these, these models, they are a solution to a problem yet to be defined. I will say that again, these are solutions. These are tools in your toolbox for a problem that is yet to be defined. And what I mean by that is my job as a solution architect is not to say, hey, I've got this cool thing, let me, you know, stick it into your business and force a solution to use this technology. First and foremost, as an AI solution architect, my first and foremost job is to ask the question, what problem are we trying to solve?? And secondly to that, not only what problem are we trying to solve, but then maybe more importantly, how do we know if that problem is being solved accurately, correctly? We need a way to measure the success of that model. So a couple years ago, maybe 3 years ago, there was a study by McKinsey done, was complemented by another study by IDC, which is a research organization. And Gartner has documented this as well. They said that in, in the years between 2013 and 2023, which is right, you know, in the up-and-coming of LLMs, but kind of the, the good old days of applied AI, meaning that you could use an AI model as an API, wasn't an LLM, just a typical model. Companies that tried to use applied AI, they would typically fail. 82% of AI projects failed to get out of pilot purgatory, failed to get into production. And the main reason was, is that those projects never clearly defined— many of you agile people will appreciate this— they never had a really clear definition of done, right? What is done? What does that look like? And I thought, I think that's really interesting because it, it means that we were really bad at saying, okay, here's the problem I'm going to solve and here's what it means when I have solved it. We just built tech. I don't know, many of you might remember this. What's up? Good to see you. We have like a lot of technologists that we like to build. We actually think we understand a lot of these problems and we build without really including people in those decisions. And many times, let me know in the chat if you've done this before, where you build something and you hand it to the people you build it for and they're kind of like, meh, right? Or they don't even really appreciate it, they don't like it. It actually doesn't even serve their needs in the best way. And so this comes to my second philosophy as an AI solution architect, is that when I'm architecting a solution leveraging artificial intelligence, that I never build for a community without them. I never build— I never solve a problem without people who actually have that problem in the room with me. And this I borrow because some of you know I have a child with Down syndrome. He's 20 now. But he really encouraged me to think very differently because again, as a technologist, as a tech mom with a special needs son, I'm like, I can build all the things. I can build all the tools you need, honey. And but what I uncovered was that he didn't need all the tools. He needed very specific things. He wanted very specific things. I'll give you an example of this as well. One, I was building for a healthcare organization. A couple of you here were on this team with me. We were building a solution for a healthcare organization. And I was like, okay, you know what? It was for nurses and outpatient nurses. And we were like, oh my gosh, it's going to be amazing. I can go in and I can help these nurses. And I just do my best to kind of watch what's happening. I'm like, look, they spent all this time like talking in between patients. I was like, what if I could build an app? And this is what I did. We, we literally built an LLM. This was 2 and a half years ago. We built an LLM for shift change reports, basically allowing an LLM to capture data about patients in flight during a, during a time that nurses are on, you know, during their term or whatever. So for an 8-hour period or 12-hour period, depending on how long they were there, and it would automatically generate the shift change report to transfer duties to the next nurse coming on staff. Does anyone maybe see a problem with this? I certainly didn't. I was like, this is awesome. Look, you don't have to do any of this. They crystallized this concept of never for them without them because they— when I gave this solution to them, presented it to them, I'm like a little kid, like, look what I did, isn't it awesome, isn't it beautiful? Um, and they looked at me and said, um, yeah, so the one time of our day that we truly enjoy is the time where we get to connect with each other and exchange information about patients and kind of just hang out and talk. It takes about 45 minutes. It's really quite— it's like the delightful part of their day. And without their input, I actually built AI to do the one thing they really wished I'd leave alone. And so they were thankfully, you know, vulnerable enough and transparent enough and kind enough to share that with me in a very nice way. But it's so interesting because my tendency as an engineer is to just build it when the most important thing I can do as an architect is to invite those people to the conversation at the beginning when I am ideating, not after when I lob it over to them and go, "Here, isn't it awesome?" Right? It's at the beginning. So never build for them without them. So that's 2, right? First one, be the most positive person in the room. And if you need help with that, I did build an application on Alexa to help you. It's called One Minute of Mindfulness. So if you need help kind of resetting yourself, you could just ask Alexa for mindfulness and That's my code. You can have that run for you. So that's pretty cool. But that's the first one. First one, be the most positive person in the room. Be the one people want to work with. Be excited about the solution. Be focused on that. Part 2, step 2, the next principle is to never build for them without them. As an architect, it's so easy to look in our toolbox and build cathedrals. But if we do not know who we're building for, and more importantly, if we're not empathetic to their needs and have them sitting right next to us going, yes, more more of that, no less of that, we will build the wrong things. We will waste precious time, precious energy, um, building things that people don't need. And that is probably the biggest moral of that story, is to make sure when you build things that you're building things that people need, um, that they require. Oh, awesome, thanks Tony. Um, and, uh, so good to see you all. Nice to see you, uh, everyone. Thank you for being here. Roseanne, awesome. Going through— thanks Joe. Yes, awesome. Also remember, these people in the chat, these are your friends, these your counterparts, your helpers, your partners. So many people that are here today are not, you know, that we're on various levels of our AI journey. Some of us just starting, some of us have been doing this quite a long time. Some of us have been doing it before AI was cool. Some of us have even been doing it before applied AI was a thing. So really important to kind of connect with us. LinkedIn, that's why I do this on LinkedIn Live, though we are also live on YouTube. So if you don't like LinkedIn Live as a platform for watching this. You can go on over to YouTube. You can also see me live on Instagram. You can also see me live on Amazon Live. So it's up to you where you want to go. All right. So, so be the most positive person in the room. Never build for them without them. My third one is be a doer, not a talker. I was just— I'm actually in D.C. I think I mentioned this yesterday because I'm talking— I was talking to the Commonwealth Cyber Initiative. They run a summer program where they bring in a bunch of students, high school students, early college students, their summer interns in local companies, but they're all interested in cybersecurity and AI. So I was there as the keynote speaker yesterday, and one of the questions that I consistently got, and I think it doesn't matter where you are in your career, this question often comes up, is, you know, they're like, how do I like do the thing? Like, how do I acquire this knowledge? I don't, you know, I'm not going to necessarily acquire it by watching YouTube videos. Academic institutions that provide live training, it's not the most exciting training, right? Like, a little bit boring. I've watched people watch videos and, like, fall asleep while watching. Hopefully that's not you today. Um, but training is hard. So what is the mechanism you use? This is them asking me, what do you use to gain these skills as new skills come up? And so I went back to my earliest days I mean, I could go way, way back, but I'm going to go to like early days of Amazon Alexa, like 2013, 2014, and tell you, like when I joined that team, I didn't know anything about, you know, speech recognition or natural language understanding or, you know, any of that stuff. I didn't know anything about AI, really. I was just passionate about the problem, right? I was passionate about the fact that, wait, if I could create a device that you could talk to I have a son at home who has, you know, learning disabilities. If, if I create a device that you talk to and it can run any code for you, which is the world we're in right now, you say words and any code will execute. I'm like, this is massive, huge. Like, all now the only thing I need to do is teach my son how to communicate and the whole world opens up to him, right? If I could just teach him to speak, now everything else happens through something like Alexa or Siri or any of these other devices. This was well before LLMs. So I needed to learn how to build for this platform. Now, I will tell you, I did already know Java. I'm a Java programmer at heart. I helped build IBM WebSphere back in the day. I have books that I wrote on it back in my old life. But, but that was my, my, my thing back then, enterprise Java, which sits in like 90% of the Fortune 100 500. So enterprise job, I did have that under my belt. So it's— I didn't know how to write code from that perspective, but I didn't know anything about building AI systems. So here's what I ended up doing. I went into GitHub and I decided to look for projects. The first project, I wonder if I can remember his name, Sam something, I can't remember, but he wrote a project. It was called Alexa Pi. Y'all should go check it out. This is years over a decade ago. So he wrote a project called Alexa Pi on GitHub, and it was basically you could go out, buy a Raspberry Pi, and you could configure Alexa voice service on top of the Pi, and you could like use headphones. I don't know if I can get them out in time, but like headphones like this, you could plug it into the Raspberry Pi and you could use the little push-to-talk button and you could teach it. Now I— so I was like, okay, I'm doing that. So I went and bought a Raspberry Pi. How many of you built— have built on Raspberry Pis before? Burned so many. As a matter of fact, when I was leaving my AWS role to move to Alexa, a good friend of mine— I don't know if he's here— he ended up buying me this book on my, like, departure day from AWS over to Alexa. He was like, here. And it was, um, electric— no, it was like Electronics for Dummies. That's— and boy, did I need it. Um, I didn't know anything about any of this stuff. But here's what made what I am doing today possible is that I was willing, number one, to say yes, yes to the fact that I didn't know and yes to the fact that I could figure it out. Just believing you can figure it out is like half the battle. So I believed I could figure it out. I was relentless in my approach and I just started going into GitHub repos and rebuilding those repos. So I went to Alexa Pi and I built it. I went from there though and got a little excited. So again, this is the heart of a good solution architect is that I'm like, I'm like, how do I do, you know, I get this bare bones Raspberry Pi. I'm like, how could I do more of this? This is like true story. I haven't told the story very often, but back then, and it's even still available, I think it's on Hackster. Do y'all remember Hackster? Anyway, it's like hackster.io. I don't know if it's still a website, but I built something called the Alexa Bartender. This is well before, I mean, there's newer ones now. I think there's actually productized versions, but this is like at the very beginning of Alexa. So I build this Alexa bartender. I buy DC motors, silicone tubing, 5 bottles of colored liquid. They will just say that. And my goal at the time, the problem I was going to solve was I wanted Alexa to be able to build a Negroni, an alcoholic drink that contains, I think, 5— I think the reason there were 5 liquid bottles, because there's 5 alcohols in it, and it creates this like orange drink. So that was my goal. So I built a robot bartender that was voice activated with Alexa Voice Service, all running off a Raspberry Pi. But you know how much I learned in that process, right? I learned about DC motors, number one. I learned about transistors. I learned about all— I mean, some of these things I knew already, but I learned by building. I found new problems to build for. And so this session today is going to lead us right into tomorrow which is where we will build an agent, your first agent or your next agent. We will build it live. I'm going to build it live in front of you, but those of you in VIP, we're going to build it live on the platform. Um, and so it takes like— it's a 2.5-hour boot camp. I'm gonna mush it into 2 hours. We're gonna do the talking points, and I'm gonna tell you everything you can do. So it's DIY. You could go and do exactly what I'm saying. We still have time to kind of have every— all all 300 to 500 of you do the lab in the 1 hour we're doing. So VIPs, you all will get access to coming on Zoom and we're going to build an agent live together. But that is what became my superpower on Alexa, is I started going and I just started building apps for Amazon Alexa. In the first year, I built over 100. There were less than 1,000 skills on the whole platform, which meant I had 10% of all the apps on Alexa at one point. I even have a little t-shirt Some of you have this, not that t-shirt, but some of you have some of those early t-shirts where we were like, first thousand skills, first 10,000. Anyway, but I had 10% of Alexa at one point and I just kept building. The best way to learn is to start building. And today when you, all you need is words, clarity of thought, a problem to solve and an idea on how to solve it. And you could just have a conversation with an LLM and build something awesome. Like, that's pretty cool. So that is another principle that I have, like, that's ingrained in me, is when in doubt, build something, right? Learn by doing. Be a doer, not a talker. Um, there are so many people, as you know, in the world that talk about AI, and they're not builders. And you can tell by the questions they're able to answer, by, you know, I— people will interview me and they'll be like, here, I'll send you the questions. And I'm like, you don't have to send me any questions, you can ask me anything. About anything because I've been doing this a long time and I've put in a lot of reps. But that is, I think, the secret. Another principle of being a good solution architect is you have to put in the reps. And here's the good news. You don't have to put those reps in for clients. You can manufacture the reps. I say reps like repetitions in working out, right? Like the only way to get fit is if you actually go to the gym or in your home gym. And you work out. You put in the 30 times 4 reps of tricep, you know, whatever, kickbacks and bicep curls and quadricep, whatever, right? Like, but that's, that's how it works. Like, you don't get results unless you actually do the work. So be a doer, not a talker is the principle that allows you to align to, okay, when in doubt, I just start building. And Here's the good news. We have this wonderful— I feel like they, they knew Noelle when they said it, um, but we have this cool new term called vibe coding. I purposely intentionally set time every single week to just vibe code a platform. So the other day I vibe coded a platform. It took me less than an hour. I did it on airplane Wi-Fi because I fly around a lot, um, and I vibe coded a challenge hackathon platform. It created a platform that allowed me to register hackathon teams, allowed me to give them names, upload images for their logos, create 6 different challenges, measure the challenges, create an opportunity for all the challengers to participate, build the ecosystem, created an admin console. In that admin console, I could add additional challenges. I also could record all the winning prompts that were used in the challenge. And I did it all with my words. And what was best about it is that the model pinged me and was like, so I know, I see what you're trying to do here, but you probably are going to need this little feature. And I was like, you're right, we do need that feature, right? And so it is— again, the outcome was very cool. It's a platform I, I use today to do AI red teaming challenges. But what was cooler about it is that got me from idea to execution. And that is the bridge that an AI solution architect— that's our job to cross— is to get our customers from, wow, that's pretty cool, art of the possible, to delivering with excellence, actually having a real product operating in production. Now, the next principle that I'm going to share with you, and hopefully you're taking notes. I did tell you in the email to bring a journal and take notes. But the next principle is around this concept of building. So once you decide you're going to build something, here is something that I learned again in Alexa, but also at Microsoft during my time there, was there is a lot of talk these days about building MVPs, minimum viable products. That's— I hear it all the time. I go into organizations, they're like, build an MVP. We're building MVPs. POCs is another word. Proof of concept. Here's what I'm going to encourage you to do differently. In the— what differentiates us from being just a typical solution architect to an AI solutions architect is that we don't just build for viability. We take the time to think about our clients and our customers, and we think, what, what would be remarkable? What would be delightful? What does a delightful experience look like? So I've heard some say change MVP to MLP, or minimum lovable product. But the way I characterized it back in the day was building a minimum remarkable product. When you think about what's the minimum thing you can build, one of the variables of that minimum capability needs to be its delightfulness to your user. And I'll tell you why I think this— the reason it was the case is that we would build lots of these MVPs, if you will, for clients. And what we found is that when we build it, built for this level of remarkableness, so many cool things happen. People got excited. They're like, "Oh my gosh, that's so cool." And here's the fun fact is that the viability actually wasn't there all that much, right? Like maybe what I was trying to do wasn't perfect, but the fact that it was remarkable, that it did something pretty cool, was enough to get us out of pilot purgatory and into a state of How do we become production ready? So let me give you another, an example from, again, my time at Amazon. We would always look for these remarkable use cases. What could I build that's small, scope small, so I could deliver it quickly in an agile way, in autonomous way? How can I deliver these features? But I want it to be a feature that people are like, well, that's pretty cool. So one rubric, one way that we measured how to do this, how to find a remarkable use case. And you could do the same thing for your own business, your own clients, or as an employee. We went in and we looked for things that were hard to do that people needed to do all the time. And the way I did this, because I was serving e-commerce kind of clients, because this was Alexa, so we were serving e-commerce clients for the most part, like Tide or Nestlé. How could I go into— or even banks, or even healthcare, but they were very much like online businesses that we were supporting and encouraging people to use their voice to talk to those online businesses. So in order to develop a remarkable solution, what we would do is we'd go to those websites and we'd ask them, okay, what are the most common things that people are trying to do, and then rank them by how hard it is to do that thing. So to help you imagine this a little bit more, think about like a financial institution 10 years ago, maybe 15 years ago, right? If you look at a financial institution back then and you looked at the click trails on their website, like all of the clicks that came into their website, and you looked for the hardest thing, it like the thing people went to the website to do most often but required the most clicks to get to, that was the cross-section that created the, like, the best opportunity for remarkableness. Because people would be like, oh my gosh, I do that every day. It's kind of hard and annoying. Going, and you made it available at the top, like tip of my tongue. That's amazing. So what we found actually in finance was the one remarkable use case that was everyone did it, like a bunch of companies did it every day, but it was really hard to do, was finding the routing number. I don't know if you remember when we did this, and still companies struggle with this. But a lot of our financial customers on Alexa were like, okay, why don't we start with that as a top-level intent or something you could just say to Alexa if you were working You know, there were organizations back in the day where we sold— I don't have one. If I was in my office, I could show it to you. We'd sold these little dots, right? These tiny little hockey puck versions. They're a little more rounded today, but back then they looked very much like a hockey puck versions of Alexa. And they had like an audio output, right? Like an audio, an auxiliary out for audio. And so you'd put in your headphones. And so if you were working, We created a bunch of skills, remarkable skills, that workers could use to make their day go better. And one of them was just ask for the routing number of any bank. You could ask for the bank you're in, you could ask for your routing, any bank. And that, as soon as we did that— now, that is, that mission critical, is it necessary for them to like use AI to grow their business? No. But it was enough remarkableness for them to be like, That's so cool that I could just ask for what I want and it gives me what I want with, and it's always correct and everything's amazing. And so that gave us enough energy to do the next use case and then the next one. But remarkableness became the key ingredient to encouraging further investment. Start small, start remarkable, and make sure that, of course, as an architect, you've thought through the next 3 to 6 use cases. So that's another challenge that I find architects struggle with, is that we often will build for the immediate need and we're not thinking about what the next 16 or 18 use cases will be. I remember going into an organization now with our— and there are a couple people in the chat that do this as well. I'm gonna make sure I can see all your— oh my gosh, so much love in here! Thank you so much. Um, yeah, exactly, Ivan, exactly. So there's so many cool things that you could do with that. So I, what I think is so cool is like we were doing this with Alexa, but imagine today, imagine if we took the approach of building agentic solutions by looking at human work, going into an organization and being like, what remarkable thing could I do for you that currently just annoys you, that you don't want to do? And if we are the architects we're trying to be, we not only see that tiny little, you know, spot in the workflow, We're also looking at the macro. So I always say micro and macro when it comes to AI. It's so important to have both of those philosophies in your brain at the same time. And that is the magic skill that we get to harness, right, as an architect, is that we look at— it's, it's extremely crafty, right? Like, you're going to look at the big overarching, what is the best outcome look like, and then you're going to dwindle that down to a single remarkable use case. I always tell architects that I'm training that you are going to sell hundreds of millions, maybe billions of $100K in AI solutions, but you're going to do it $100K at a time, $25K at a time, $50K, like little remarkable use cases at a time. The burden is on us as architects to see the big picture, to know that that little remarkable use case is actually a tiny puzzle piece in a grand, you know, masterpiece of a jigsaw puzzle that we are pulling together. And this was a little easier back in the day. I mean, I— my journey into AI started back in, you know, pre-Y2K timeframe. But about 10 years into my career, we had this beautiful world of web services that came about, and I was working for IBM. So I was in charge of training tens of thousands of engineers on how to build for microservices. You know, how many of you were around for microservices? Yeah, I see you. I see my friends. So we're not too far from that, like, same mindset now., right? Is that back then, the people who were the most successful were the ones who were not just thinking, how do I break this up into kind of indiscrete little, you know, or discrete little pieces, but how are we architecting them? How are we orchestrating them? Some of you might remember we had this language called BPAL, Business Process Orchestration Language. Like, how do we orchestrate our execution? Anyway, how do we orchestrate how these services are going to talk to each together. That was 10, 15, almost 20 years ago. Fast forward to now, now we're looking at the opportunity for us to orchestrate them again, except instead of microservices of, you know, big monolithic code that we're breaking apart, these microservices are now going to be AI services. Some will be LLMs, some will be applied AI services like, you know, computer vision, custom vision, things like that. Some will be document intelligence, content intelligence, but we are the orchestrators. As a solution architect, our job is to know what the big picture, the big problem we're trying to solve, and how do we develop remarkable increments to that big masterful solution. So really cool. Yes, exactly. Think about scaling the use cases, not the model. Exactly, Joshua. I love that. 100%. Yes, exactly. Oh my gosh. So cool. So cool. Yeah. Yes. So, so that's the good news is that if you've been in this industry, if you've been in technology for a long time, the enterprise patterns of architecting solutions are not that different today. As a matter of fact, I believe data scientists, data engineers, AI teams, they require this skill set now more than ever. Like, how do we piece these systems together? How do we make sure— many of us went through this journey with microservices and Eventually, it became obvious that we were challenged, that we had— okay, that we were challenged by, okay, if I have 100, 1,000 microservices, how am I going to manage security for all of them? How am I going to manage, right, like RBAC or role-based access control? How am I going to manage networking? How am I going to manage who gets to access what? Minimum access, like zero trust. Those problems we've solved before, and they are amplified in a world of agentic, mainly because— I don't know if you saw this recently, but OpenAI just did it. Microsoft has a protocol for doing this. But we are now seeing people take their old tech and just wrap it in a protocol and stick it on the wire so that it can communicate as an agent in an ecosystem. That's kind of— I mean, yay, I think it's good, but it's also kind of scary, um, because it does require people like us who are going to think through those business processes. So I've covered quite a few things. The first one, um, the most positive person in the room. Make an intention. You don't have to be the most positive person everywhere all the time. I cry over my dishes sometimes. It happens. Um, so feel free to feel the feels. But when you are delivering, when you are, are, uh, talking to someone about a solution, about a problem you're trying to solve, Be sure that you've put on like, hey, I'm here to help. The, uh, a second part of that is never— and I mentioned this, I think, was it yesterday? Maybe it was Dave, maybe it was Friday in our community calls— never argue with any, anyone really, especially though with your customers or your stakeholders. Always find a way. And I, I won't tell you to agree with them if you don't agree, but I will tell you that when somebody presents you with an alternative approach to something, you telling them they're wrong will not end in a sale. I've never, I've never seen that happen. And not just as me, the seller, just watching people. When you argue with your customer, argue with your stakeholder, tell your stakeholder they're dumb or that they don't know what they're talking about or that they don't have the experience, like, none of that leads to a positive outcome. What does lead to a positive outcome is, tell me more about why you say that. Asking people questions about why they have the assumptions that they have. Most of us have been hurt by technology in our years of experience. Most of us have preconceived notions about what tech can do and what it can't. So as we enter into this new world of AI, our job as solution architects is not just to know the deep technical part, but also to understand that our job is to coach and facilitate our stakeholders in realizing there is a new way to do things. And even more importantly, that potentially building something from scratch, solving a problem from scratch, is going to be better than actually building on top of the duct tape, MacGyver bubble gum, you know, paperclipped solutions that we've been building on for the last 20 years. Like, we have a chance to do things differently now. We have a chance to do things brand new, and it's going to require brand new people with brand new mindsets. To bring that to light. But I do think, you know, being a Solutions Architect, I think one of the coolest things that I love about this role and this job is that it offers us the ability to, of course, be the most positive person in the room, be a doer, not a talker, be curious, right? And apply what, you know, basically be a builder, right? Build first, build POCs, Build remarkable viability. Do not just build viability. Anyone can build a viable product today with just their words. Remarkableness is what's going to set you apart. It's going to distinguish you and what you do in the world. And as we have a few minutes left, I definitely want to see if you have questions, you can throw them in the chat. I'll do my best to scroll through and grab them. I do want to give you— I love— I agree too. I agree with Noelle Russell Russell. One of the things I want to share with you as it relates to solutions architecture is when I go into a room and I talk to organizations about their challenges, I have a process. Actually, there's a few of us in this space that do similar work around AI impact assessments or AI readiness assessments. I like to call them impact assessments because my first job as solution architect is to understand the problem and not to understand it from my engineering perspective, which is where I come from, but to really empathetically understand it from the customer's perspective, the stakeholder's perspective, the executive's perspective, or my employee's perspective if I'm building for my employees. And so that means having conversations. I, I always like to— I mean, I don't want to say I like to remember this, but in the first week— some of you know this, some of you don't— but in the first week of Amazon Alexa when it launched, I was pregnant with my pregnant with my third child. I have a lot of kiddos, but I was pregnant with my third child. My son was born on November 1st. Alexa launched November 6th. So I was very busy that week. I did not— anyway, it was very busy. I won't say anything more about that, but it was very busy. So now I have a brand new baby. He was my third, and some of you with more than 3 kids probably can, you know, he basically took care of himself at birth, but, but he was my third. I carried him around. But then a few weeks later, my dad has a terrible accident. He is— we're living in Seattle. He's running across that bridge between Mercer Island and Seattle. He gets hit by a distracted driver, breaks a ton of bones, is now in the ICU. And Alexa is like just launching where— I mean, the devices are all just brand new anyway. So now I've got a brand new baby who's now 3 weeks old, an Alexa product that's just launched and we launched with lots of defects. So we had problems every single day. And then my dad gets in an accident. He's in the ICU and I go to work because that's what I do. I went to work and I remember someone walking up to me and being like, hey, Noelle, are you okay? And I was like, yeah. I mean, how many people— like when people walk by and they ask you, how are you doing? How's it going? We're always like, it's fine. It doesn't really matter if it's fine or not. That's just like how we've been trained to react. And what I realized in this, of course I wasn't fine. Like, the things were going like, oh my gosh, my life was so crazy. But anyone who would ask me how I was, I'd just be like, I'm fine. Until one day, a woman, a good friend of mine now, came up to me and she like put her hand on my shoulder and she was like, no, really, like, are you okay? You just had a baby, right? Like, how are things going? And I like, was like, oh, I got all emotional. And I was like, well, my baby, I mean, healthy but young, and my dad got in an accident, and this happened, and this happened. And then there's Alexa, and then we have all these accuracy issues. And I just unleashed all this stuff on this poor woman. She wanted it though, she asked for it. But what I realized is that sometimes when I am coming into an organization and I'm asked, I literally will ask them, what's wrong with you? Like, what's broken? What can I fix? What can we fix? How can I fix it? How can I make it better? When the most important question is actually, are you— how are things going? And then more importantly, proverbially, not like literally, but like being caring enough to stop and pause, put the hand on the shoulder, like be like, no, for real, I actually care about you. Like, really, how's it going? I adopted this when I went to Microsoft. I got an opportunity to do this a few times, one at Abbey Road in London, and then one at the Metropolitan Museum of Art in New York, where I got a chance to go in. And my job, I was with a bunch of data scientists from MIT, and we were meeting a bunch of curators from the Met. And when we met the curators, the curators were kind of like, you know, you've seen these stakeholders, they're like, I get that you're here to help us, but we don't need your help. Like, we're fine. We don't need your tech. And it was all AI data science, right? That's what we were there to do is like, how can AI help you? And we went in pretty fast and furious, like, we're here to help, what can we build for you, what can we build for you? And they were all kind of like standoffish. It was like an awkward high school dance, right, where curators on this side and data scientists on this side, and neither of them wanted to like talk to each other. It was very odd. I remember the producer at the end of day one of this hackathon we were doing looking at me and being like, so, um, I don't think it's going very well. That's what he said. And I was Just wait. And so by the end of day 1, we started shifting our approach. We started to think about how could we build trust with this team. And so we started asking them questions like, tell us about your day. Tell us about how you do your work. Where do you find the most challenges? And the longer we spent with them, the more they realized we actually did care about what they were doing and their work. And it was literally like that moment when that woman said, Noelle, like, No, really, I care about you. Like, what's going on? Is everything okay? And I unleashed— like, same thing happened at the Met where all the curators, as soon as we got them to believe, to trust that we actually cared more about their problems than our solutions— should I say that again? Like, we care more about their problems than our solutions— they, like I did, started unleashing all sorts of use cases. They were like, oh my gosh, if you could do this and What about this? And it would be amazing if you could do this. We ended up in less than 2 hours coming up with 17 use cases. You can actually go to my X profile. I have a pinned NBC Nightly News interview where they interviewed me on that project that we built. And of course, the one I liked the most was the one that we built for my son, which allowed for someone with neurodiverse challenges or differences to be able to navigate art at a museum like the Metropolitan Museum of Art or the Louvre. Like, what if I couldn't walk through it for 4 hours? How might I create a voice experience for it? I was most proud of that. But that was the moment in my career where I realized I actually do care more about the problem than my solutions. And my solutions are a constant evolving, as y'all know, right? A constant evolving Rolodex of capabilities that are getting better and stronger. And my job, of course, is also to understand what capabilities are available, but only through the lens of the problems I'm trying to solve. And that's why, you know, that going back to that research that has been done over the years on why AI projects fail, they fail for all the reasons that I've mentioned so far today, right? All of them. For not having great, like, positive people in the room to facilitate the conversation, not having a metric for success and knowing the problems that you're solve. Not being a doer, not building first, not being really hands-on, putting in the reps to know your technology, because you end up falling into a hole. And in our VIP session, which hopefully you got that email, so go check for it. If not, you can DM me or any member of the team and they will send you the link. It's in Zoom. I'm gonna actually walk you through the rubric, the architecture for building solutions, and And you can borrow it, take it. Like, it is proven. We've done it hundreds of times. But this rubric for managing that conversation to architect an agentic solution for someone, this is how all organizations are going to be run. But I do think it's critical that we shift away from, you know, like, as an engineer, I like building stuff. And I build for fun. You know, I'm that person. I worked at Red Hat early in my career. I was like, yeah, I was the one who played around with the Linux Kernels on Friday night, like, for fun. Like, that's who I am. But that's not who the world needed me to be, certainly in the last 10 years, right? The world needed me to go, hey, I got all this technology knowledge, how can I help you, small business owner? You, executive that cares about your team and want to build AI solutions to help your employees? You, as a consultant who wants to grow a practice? You, as an internal employee who just wants to do your job well? How do I focus narrowly on the problems you have and build solutions completely for that? So as I leave you today, I will tell you what I'm seeing, the future that I am seeing right now. The AI solutions that are the most successful are people willing to kind of take a step back and look at problems the world has, narrowly focus on a single problem. I'll give you an example of an amazing woman I just met. I told you about her yesterday. Alicia, she's the CEO and co-founder of this cool company, Claimable. You should look her up. But like, I loved her story so much. I talked to her in a session last week at NTT, one of the best technology implementer organizations in the world. And I talked to her on this panel, and she solved a problem that could not be solved 5 years ago. So I would say, as a solution architect, that's kind of part of our lens as well, is look for problems that could not be solved the way they can be solved today. I call it bring back the backlog. Go back to the problems we tried to solve 5 years ago, 10 years ago, even 2 years ago, and see, can today's technology maybe get you there better, faster, stronger, with less— maybe less people, maybe more people, who knows? But I definitely think this is the art of being an architect today, is how do you use the tools today to solve problems that we've long given up on in an organization. That maybe now with your skills, your interest in the problem, and your ability to be the most positive person in the room, maybe now we actually get to change the world the way we always wanted to. And that is the truth for solution architects. I mean, that's who we are. We are world changers. You are world changers. So thank you for being here today. I really hope you enjoyed the session. Hope you enjoyed the, the collection. I think we got to 7 of the 21. I'm going to be sending out a link in the chat right now, maybe. For the AI Solutions Architect, the 21 Laws of AI Solutions Architecture. So hang in there with me. I'm going to grab the link. We are also heading over to the Zoom. You will be in a waiting room until I get there, which means it'll take a second. I'm also, like I said, I am launching an AI Solutions Architect deep dive where you not only learn the art of communication the way I do it, how do you present to clients? How do you, you know, do an executive briefing, but also how do you build solutions on the fly while in that executive briefing? How do you know what to build, what questions to ask? Really, it's the, you know, roadmap, the Bible, if you will, for becoming an AI Solutions Architect. So I'm so happy to share that with you and really excited. We're going to do it at the end of the month. So if you're interested in becoming a certified AI Solutions Architect through my company, you're more than welcome to be there. So here we go. Let me see if I can grab this link. And I'm gonna put— I don't know, I don't know where this link is going to go. I think I have to go into LinkedIn and put it in here, so hopefully I don't mess anything up. Um, there we go. All right, I'm putting it here. There's one. Send. And then there, like I said, there's so many chats going on right now, so I'm gonna go and try and find— it's live! Where's the theater? All right, hold on. You all are there. I'm almost there. Let me copy the link. All right. There we go. Now I'm live. Now I see myself. Hello, everybody. Oh, there I am. All right. So here we go. I'm going to put in the chat right now. There you go. You are welcome to it. Let me see if I can hit send. Thank you for all the love. Y'all are amazing. It is so awesome when, when people actually use the emojis because it's really, really fun. Okay. I'm trying to hit comment. Did I already put it in there? I'm trying to hit enter. Oh, yeah, I did it. I did it already. Okay. It doesn't look hyperlinked though, so maybe I'll hit enter again. Oh yeah, no, sorry. Oh yeah, I see it up there. Okay, it's in there. It's in there. So hopefully you'll go check it out. This will register you as an interested party potentially in the Solutions Architect class. I really hope you love it. This is just a fraction of some of the things I share every Friday, 4:00 Eastern Standard Time. You can join me for a live Q&A on LinkedIn Live. It is my favorite day of the week. You also get to join a bunch of the friends that have joined me in the I Love AI community. Don't hesitate. This world is too small for us to not be friends. So if you're listening to the sound of my voice, I hope you'll connect with us. But I do want to be respectful of my, my other people. So we're gonna head over to VIP. Thank you all for joining us today. Tomorrow we build an agent, a responsible AI agent, end to end in less than an hour. Don't miss it. I'll see you right here tomorrow. Bye everybody. Have a great day.