Unraveling Dynamics 365 and Successful Project Recovery Techniques with Hugo Herrera

Mark Smith: 0:31
Welcome to the Power Platform Show. Thanks for joining me today. I hope today's guest inspires and educates you on the possibilities of the Microsoft Power Platform. Now let's get on with the show. In this episode we'll be focusing on architecture in Dynamics 365 and the Power Platform. Today's guest is from Ascot, england. He works as a Microsoft Dynamics 365 and Power Platform solution architect. He has authored the book Microsoft Power Platform Solution Architecture Handbook. It's a comprehensive guide for architects and consultants looking to align and implement solutions using the Microsoft Power Platform. You can find links to the book, show notes, anything about us, bio, social media, etc. We'll be in the show notes for this episode. Welcome to the show, hugo.

Hugo Herrera: 1:23
Thank you very much, mark. Happy to be here, excited, big fun of the show.

Mark Smith: 1:28
Excellent, thank you. Thank you, great to have you on the show. Before we get started, I always like to start off with food, family and friends. We can get to know your background a little bit before we get into the tech side of your career. Take it away.

Hugo Herrera: 1:43
Absolutely. Let me tell you a bit about myself, Family. I've just been over to the Download Festival last weekend. It's a heavy metal festival of all things. I'm not a heavy metal person myself, but my daughter's a big, big fan. We went over there, spent the weekend it wasn't roasting over here, it's sunny over in England right now Enjoyed it, as you can picture. I mean, I'm a very average, very boring looking guy. I was wearing my khakis and my satish there's everybody that look fantastic, these staffs and all kinds of outfits. I was amazing. I enjoyed it. It was good fun. Yes, in terms of food, what I do enjoy is a good barbecue. I love to get the grill out when the sun is out. That's what happened very often over here when I live. When it does happen, crank it out, put a few steaks or a few burgers on there and enjoy them. Gosh. Yes, in terms of fun, well, I tell you what I do enjoy. It's a funny one. I do enjoy a bit of Skyrim. I'm not sure if you've heard of that. It's a game. It's an RPG game. It's an old one. Now, it's an old one for a goodie. I don't have much time to play these days. I've never finished it. I'm hoping to finish it one day. That's my guilty pleasure when I've got spare time. But yes, that's how I do. Mark, thank you very much for having me.

Mark Smith: 3:11
Awesome, awesome, good to get that background. On that context. I don't know if I could handle a heavy metal concert at my age, but it's never a genre that's really taken me During my formative years.

Hugo Herrera: 3:29
How did you find it? It's intense, let's put it that way Intense. You've got very, very, very ranges of heavy metal, something that I can listen to to have pretty much a wall of noise. Yes, somewhere along that range you find your niche. There's some goodies. There was also placebo in there. Metallica loved those. I love placebo. It's a bit milder, it's a bit more of a karma kind of dude. So yes, it was great fun.

Mark Smith: 4:02
Wicked, tell me about your career with Microsoft Technologies. How did you get into it? Sure, what's it? Journey for you and bring us up today Kind of what you do typically from a career perspective.

Hugo Herrera: 4:17
Absolutely yeah. Well, that goes back, I would say, about 20 years, when I was a consultant for an IT service management software company. I was out there trying to get my software to work on site south of France and I met this and these things were going right. Everything was exploding yes, as we all experienced on customer sites. And the customers got frustrated and we said, well, this is not working, it's on my website, it's an IS website. Well, they brought in a Microsoft specialist, a consultant, and he came in more professional, he looked at business. I could tell that he knew exactly what he was doing and that professionalism that inspired me to basically say, wow, these people are something else. And so that goes back 20 years. And so that time passed on. I did a lot of various jobs. I became a contractor, freelancer and so on, and one of my good friends and colleagues, andy Brown, he caught me into Microsoft. He said come on over, we're doing this fun project for this massive police to police services in the UK. Come on over. And so that's where it all started. And I tell you that by the time I got into Microsoft I thought, wow, I'm already the business. Yeah, I know my stuff, I'm nonet and all this stuff. I came in and I realized that, wow, I didn't know anything compared to what goes on inside. The level of professionalism it just shines through. And I had to take a few lessons right there. For example, initially I was doing a lot of coding back in those days and code reviews. Wow, I submitted my first bit of code for code review. It was all red Go back to the drawing board and try again. And so, after I swallowed my pride, I fixed that code properly and then that went on from there and since then I've done several stints with Microsoft. I'm an independent contractor. I tend to come in and help them out whenever they need a hand. So, yes, that's really how it all started for me with my career. Microsoft always loved it, wanted to be there, and now that I am, I really am enjoying it.

Mark Smith: 6:36
Interesting. How did your career then pivot into Dynamics 365 and the Power Platform?

Hugo Herrera: 6:41
Absolutely. Yeah Well, do you know what? Dynamics is heavily based onNET, and that was my background NET as a developer, then technical lead and consultant and so on. I thought, well, I know NET and, to be honest, I was looking out there. Oh, there's some interesting projects going on with Dynamics. What's that about? Okay. So I convinced a partner to say, look, I know NET, let me in, I will help you with your Dynamics project. You don't have to train me, I'll do my own exams and so on. And they gave me a chance. It's a partner here in the UK. They gave me a chance. Thank you, I'm very thankful to those guys. And that's how I got into Dynamics. I pivoted fromNET into Dynamics thanks to the opportunity that was given me by a very generous partner in the UK, and that's been my life ever since. It's a smaller market than NET. Net is a very generic market. Well, power Platform Dynamics is more of a smaller ecosystem. But, as you know, in the last five years it's no longer a smaller ecosystem. Its balloon has exploded into all kinds of interesting tools that Microsoft keeps churning out every other week. So that's how it all moved into Dynamics and Power Platform.

Mark Smith: 7:58
So interesting, tell me, in my career. And I still have a lot of NET folks come along and say, listen, you want? In fact I just had a customer recently. We're talking about the Power Platform Dynamics and they're like. I'm a coder, I can build all this. I can easily create the code. I can build this application that our company wants. We don't need this. And now, in this case, he was a dissenter amongst a crowd of people that wanted the Power Platform specifically and to build enterprise-wide solutions that plugged into Maximo and SAP. And it was interesting, because it's been years since I've come across that mindset of we will build the whole thing from scratch and code as in that. Folks are still out there. How do you, when you're talking to developers, how do you talk to them into why they should consider the Power Platform or a Dynamics application to create another software application rather than starting with a clean slate?

Hugo Herrera: 9:05
Yeah, I hear you, mark. I think all the question is build it from scratch versus get something off the shelf In quotes, yeah, and I mean I think Microsoft has made it much easier to answer that question, based on the huge amount of functionality and features that come with even the simplest and smallest of licenses. I mean, you get yourself a license of Dynamics 365, pay a small amount for a user and you get this huge amount of functionality. You get SharePoint, you get database, you get UI, you get Power Pages, you get Automation and you get built-in AI functionality, and so it is a very compelling offering. That makes it very often the clear winner versus spending a year developing a custom system. And so that is really when I'm talking to developers and say, ok, shall we build it from scratch or shall we use Power Platform or shall we use more of the Out-of-the-box functionality? I tend to always go for the Out-of-the-box functionality if possible, and if a client's requirements are a very esoteric or interesting or a way out, you can try and guide them and say, ok, look, you want this very special system. That's custom, but if you do it, if you tweak your process slightly, you will have a much easier life. And so that's the negotiation, that's the discussion and the dynamics of that conversation, and but, like I said, because of the amount of functionality that you get without even configuring anything, it's a very easy answer most of the time.

Mark Smith: 10:47
Yeah, so true. Tell me what's your journey in architecture. You've been doing it a long time and I assume, similar to me, that you've come across situations where you go in and your job is to recover a project. The project's gone south on and could be on any number of the dynamics products maybe, or Power Platform. Have you been in that situation and what's your typical process around addressing it? Because I tell you why I say this? Because I've been at so many times where I've been bought in, sit down in front of a customer and they tell me why the product is wrong and very quickly I work out it's actually not the product that's the problem, it's the implementation that's the problem. In other words, they've either over engineered it, over configured it, made it much more complex in what's needed, or, fundamentally, the consultants involved in the work to that day. Just they didn't know what's in the product, the full product suite, and have made glaring, obvious mistakes. And so I've never been in a situation where the actual product choice was fundamentally the wrong choice. It's tended always to be something around either the project management, the way it was architected, the outcome solution, or there's been massive scope creep and nobody had that in check.

Hugo Herrera: 12:13
What's your experience? Yeah, well, it's. My experience is similar to yours, mark, in the sense that I least with power, platform dynamics 365, with other products, yes, I've seen where Impass in my past life. I've seen where, yes, obviously this product doesn't quite fit in and we should really think about something else. But the part of my it's because it's, it's quite said, fairly generic Framework for for employment in blimp to miss the person applications. That is not often the often the case Well, it's often the case is the two things you described. Yeah, over engineering, or we gone off on a tangent, we ended up in that in a different, some, some worlds, and then we were expected. So what I tend to do is, and that have that as a, as an independent consultant and architect, I do get engaged quite often in that kind of project recovery. I bring the project back in line and or or else Okay, and so the this, this, three things are really think are important. What one of them is to understand what you've got very and that that can't is stress that enough. Clear understanding of what, what has happened, what, what do we have, what's the architecture, what's the, what's the that, what's the setup, what's and what is it that has? Is not the hub customers not happy about? You see, we don't understand that, then you're going to probably end up six months on here down the line on the same place. So understand what. What's happening, what's, what do they want, what's wrong and what? What is the, the infrastructure, the architecture that they really need? So we this, then you do that with discussions, workshops and, until you draw it up, I love Drag and drop in front of customers so that they can feel that they're involved in the process. Drag and drop An architecture diagram or process diagrams until they feel that the play, the, the boxes are clicking into place, and that is a very powerful tool. And so, first of all, understanding and and what one important thing about understanding the, the, the, the. What's going wrong over there? What they've customer wants is not making assumptions. That's that's really. That's something that's caught me out and that's a lesson that I've learned in. And it's making assumptions, may. By that I mean Assuming that what people are telling you is correct. That's one assumption. Yeah, if you, if you always assume that what people are telling you is accurate or that the documentation that you're looking at is accurate, then you run the potential of missing a huge amount of technical debt Issues down the line that suddenly make you're back into recovery mode a six months down the line. So don't. And so to to avoid those assumptions, yeah, analyze. Yeah, if you, if you don't have the time to do it yourself, get somebody to help you analyze. What's a quote really like what's what, what's, what code do you have there? What implement, what tables do we have here and what integrations do we have here and this, the integration really working? Somebody's tell me that is working, but is it really? Because I found that, yeah, people, that that can happen. People tell you, yeah, it's working, but it really is not. And then you, you, you basically you inherit technical debt without knowing it, because that will come double surface later on. So, understanding what you have, and Without me, without making assumptions, so that you get the reality of the project. So once you got that, yeah, the second part, I believe, comes, comes easy, and that is to gain the customers trust, or the organizations trust that you actually Can't deliver on their vision. Or and, and that's quite important in a recovery project because they've been, the company's been burned, yeah, they've, they've, they've struggled for x number of months, years sometimes, and and, to end up in a place where they've lost money. The lost face in the product they left, face in the delivery capabilities of the partner or whoever it is that some that was delivering, so are you. You have to prove that you're not just one more of those people coming into to tweak a few things, charge and building by the day, and then and and so on. So gain the trust. And you gain the trust by you showing them that you understand that if you complete step one, you're like most of the way to gaining the trust. You gain the trust by explaining this is what you have and this is how I plan to resolve it for you. This is how to cover. Clear plan architecture diagrams, I think, are very important. For that. I create a very clear high-level architecture diagram for C-level executives and so on, so that they know that, yeah, this is all going to click into place. And then detail architecture diagrams for the architect, security infosec teams, business analyst and the stakeholders and so on, so that they can feel that, yes, we can build this, yeah, this makes sense, this meets our security requirements and this resolves the really bad problem that I had before, and then also create a plan and architecture diagram, enough documentation or break down the problem in such a way that the implementation consultants, developers and so on can take your vision, your plan and make it happen. So when the customer sees that all those things are falling into place, yeah, then the customer, you gain the trust and then everything will be easier. Because without that trust, the wheels will do not move, the cogs don't turn quite as easily and you'll have a whole lot of hurdles to overcome as you go along. And lastly, once you gain the trust, take the reins. Yeah, and by take the reins of the project it means do whatever it takes to move things along. Because when you're working on an implementation project of any size, there'll be perhaps a number of issues that you need to overcome, perhaps skill shortages or skill gaps, and you haven't got a consultant that has ever integrated with a particular solution like SAP. Well, how do you gain that expertise? Fill that in most of the time that will, as a solution architect, if you can bring your expertise to bear on that and that situation. Fill the gap and help somebody, if you have somebody, to gain that skill, that knowledge, as quickly as possible so they can deliver the integration or whatever it is, and take the reins in the sense that break down the task, give the developers what they need to be affected every day. And especially, it's important if you have resources and distributed across the world. You've got people as a team of 10, 20 people in the other side of the world and if you don't, they don't have clear instructions. They will spend half a day not knowing what to do. So that's 10 people wasted half a day. So clear instructions. I love it as your DevOps. You know my big fan of that. Breaking down tasks, massive projects into little tasks that people can chew, and so that's the idea. And with those three things understanding what the problem is and what you want to do, gaining the customer's trust so that they know that you can deliver and then take the reins until you and do whatever it takes to get to the finish line with those three things I see those as the three ingredients to recover a project. That's the idea. Absolutely yeah.

Mark Smith: 19:47
Is there any tools that you use? As you know you talked about, the documentation could be way off and you're told what's in the system, but it differs to what is actually in the system. Do you have any tools go-to tools that you use to assess a new environment, to kind of find the things hidden in those dark back corners that you don't want to have as gotchas later on?

Hugo Herrera: 20:11
Yeah, absolutely. Well, you've got a number of options there. Yeah, the first thing I'd like you can go to is the solution checker. The Microsoft has expanded on this functionality quite a bit, so you run a solution checker on that and make sure that you cut. That solution includes all the components that really are custom and that will turn out. Let's see. Well, ok, there, we got a few issues there. Those are more generic issues. They're not going to tell you what's really going on. Yeah, so to understand really what's going on, I do like to extract a schema of the tables in a visual format so that I can see how the tables because quite often there'll be loads of custom tables and you think, wow, ok, where do I start? Yeah, I've got 100 custom tables and they're all interlinked. What is the real core structure? So you need to start breaking it down. In the XM toolbox you'll find a Visio extraction tool that will allow you to say I select the 100 tables, 50 tables, and then turn them out into Visio and then, with a bit of drag and drop, you can then get a feel for what's really in the mix and get a feel for the data structure. That's crucially important because Power Platform. It's all about data versus, isn't it? That's the foundation of it. If you don't understand what's going on in those tables, in the data, then you're going to have a hard time understanding what else is going on in the system. Then, of course, you got other tools in the XM Toolbooks. I keep using the XM Toolbooks and I'm very, really grateful for the guys that built it and all the plugins that keep creating. Another tool is the tool that I use quite a lot. It extracts all the tables and all the fields columns, as we call them now and into Excel, and then I can just say, okay, I've got all my tables here, I can see I've got lots of custom fields, and then I get a bigger picture of what's going on there.

Mark Smith: 22:14
That's really my go-to areas.

Hugo Herrera: 22:16
I think there's several others that people use, but I'd like to start with us to get an understanding of what's going on.

Mark Smith: 22:24
I like it. Let's talk a bit about your book. Oh yes, Tell me what was the goal you're wanting to achieve when you agreed to write the book. What was the goal you're wanting to achieve?

Hugo Herrera: 22:39
Okay, that's an interesting question. Well, I think there are two answers to that. First of all, when I was approached by the publisher to write that book, I was actually writing another book completely unrelated to Power Platform. It's a science fiction book which is still working progress. Then there's this publisher pack that approached me to write the book and I thought, well, that's fantastic, I like to do that. For one, I like to know how the publishing industry works so I can get a feel for what's going on. How do you actually publish a book? Second, over the last few years, I've learned quite a few things. I've been just you know what. I learned a lot of things by making a lot of mistakes along the years. I thought, well, I can put that down on paper. Besides, the things that you find in that book do cover the basics. It covers the exam PL 600, and so on. But I've also tried to instill some of the experiences that I've had over the years. Well, and various customer sites, various projects of different scales and sizes. And I like to instill that when I've found what I learned on through those pages such that it can be useful for somebody else, and though that it was one of the aims that I had when I was first approached to write that book and, yeah, hopefully I've achieved some of it. The book is. I think people like I don't talk to call myself a perfectionist, but I'm never happy with whatever I've delivered, and I always looked at a book and think I wish I had another three weeks, five weeks, to fine tune a few of the chapters. But you know what? Publishers are very good at keeping you to your dates. Yeah, they knock on your door every single day until you churn out the chapters, and that's a good thing. Yeah so, but yes, it's a fantastic experience.

Mark Smith: 24:39
Yeah, tell me, what Sub-Subjects does the book cover? What are you know? Have you broken into themes? What's the structure of it? Particularly because I found you know in reading it and I just want you to go through that from your own words perspective, because it'll talk to the way you were thinking but there's not a lot of really great books for architects and for people that aspire to be architects, and I feel that the examination paths provided by Microsoft and I've been part of that examination ecosystem over the years they tick a box but they don't really impart skill. Right, there's they, and exams can only ever go so far in that respect. Right, and I'm a big advocate. If you don't have experience, you need qualification, because at least it shows you've done some study and have a thinking. But ultimately, right, it's the rubber meets the road when you're on a project and things go wrong and you have to solve and get the right outcome. You learn so much, right, as in when you're in the field, like that. So tell me, for aspiring architects, what are they going to? Just give us a bit of an overview. What are they gonna experience? What are they gonna get? How is the book gonna help them?

Hugo Herrera: 26:05
Yeah, absolutely so. What I try to do with this book is take the reader through a journey, and the journey is through using a case study as a fictional organization that's a very typical financial services organization, insurance, consultant, delivery and so on and they want to transform their legacy systems into shiny new power platform dynamics. All the goodies done, the tools that come with the power platform, and the journey takes you right through from the beginning, from the discovery and analysis of what the customer is all about and what they want and requirements captured and understanding what the requirements is and the requirements captured part is one that I particularly enjoyed writing because I learned new things as I was writing it that I would particularly call out to me as an architect, and I'll tell you about them in a second. But anyway, you go through discovery, requirements capture and then you go through design how to design a power platform system, how to, how to get asked the right questions, how to build a blueprint, how to get an architecture blueprint we also talk about as a integration with other systems. There are various options for integration, as your and, and the various tools that come with Power Platform itself, without even touching, as your, you know we're talking virtual tables and so on. Okay, we want to also bring into the mix all the toys that come with Power Platform, power Pages, power to Made, virtual Agents, all those good things, yeah, and we the journey takes you through how you can map what the customer is telling you, the requirements on to these tools, and so that you can say, okay, yeah, yeah, you can do this with a Power Page, but you can do this with a model driven app. Perhaps a camera set will be suited. So you go through that thinking process until you find you fine tune your architecture to suit the short term and the long term goals of a particular organization. Then we talk about security good old security, make sure that everything's locked down and, in terms of data, verse and another component very important for a lot of organizations, particularly the financial sector. And then we go through the journey of how to manage a project, how to keep a project running. Yeah, and that talk that is talk that is also about, as your DevOps, how to break down tasks for your developers and your consultants, break down the big things, that the big blueprint, into achievable tasks that people can, can deliver. And then what we did we went through to the how to plan a go live strategy and a rollback strategy, because that's quite important. You need to have a plan for going live and how you're going to do the migration. Is it going to be a big bang go live, or are you going to phase it? I'm a big fan of phasing. I like to minimize risk whenever possible, and I do find phasing is that it lends itself towards keeping risks down most of the time, and it's not always possible, and so that is really the journey that the books do. The book takes you and then it's trying to go through a typical large scale power platform project from start to finish, so you can get a feel for things, and what I try to instill in there is some of the nuances of being a solution architect and the problems that you're, the challenges that you would face yeah, like as simple things, like how to deal with conflicting requirements One department tells you want this, the other department tells you want that and how to reconcile those conflicting requirements and make sure you deliver something that the business really wants. And one part that I really liked about the whole journey is you finally enough is the requirements capture out of all things, because I found that something very powerful is, that is, to understand what it is that the customer really wants. The customer may tell you I want this, I want a big user interface that shows me all this information. And then you ask you as a developer or consulting, okay, great, I'll go away and deliver this. And then you end up saying, okay, you deliver that. But then really the customer finds it not quite as useful as they thought. And so, if you delve deeper, initially you say, why do you want that big UI? It's because I want to see this information, the financial list of information. And they ask why do you want that financial information? And you, without being annoying, you get. You delve deeper until you find the root. And perhaps it might be that what they really wanted was an automated system that sends an invoice every week to those people in that list. So, instead of that UI, build them an automated system and they'll be a lot heavier. So that's one powerful thing that I find is pivotal and crucial to a project, because that is where you send the project off into recovery later on, or something that they're not that useful to something that really adds value. Yeah, so critically important.

Mark Smith: 31:38
I was talking to somebody the other day and they said the difference between a consultant and a doctor is a doctor, once they identify where the pain is, they'll prescribe something, get underway. A consultant's job is, once they find out where the pain is, is really prod it and around it and really understand why is it painful. And so therefore it's a. You know, expect that when you're engaging with a customer they will tell you one thing, but you need you know the five whys if you're like you know, keep asking why until they've really run out of rationale, because then you'll get to really what that truth is before you start building yeah. I love it. Hey, this has been so interesting talking to you, hugo. We'll make sure you put links to the book. I highly recommend to the listeners that you check this book out, especially if you're you know you're currently a functional in a functional based role or a developer based role and you're wanting to to progress to architecture. You know you might have done a few projects. You want to go on that progression journey. This book will help you get there and be a leapfrog for you to really understand what other skills that you need to add to your portfolio. Before I let you go, hugo, anything you want to advise in part before I say goodbye.

Hugo Herrera: 32:59
No, absolutely Mark. I've really enjoyed being in the show. It's been a big fan, like I said, and thank you very much for having me. It's been a pleasure and, yeah, keep it up.

Mark Smith: 33:10
Hey, thanks for listening. I'm your host business application MVP Mark Smith, otherwise known as the NZ365 guy. If there's a guest you'd like to see on the show, please message me on LinkedIn. If you want to be a supporter of the show, please check out buymeocoffeecom. Stay safe out there and shoe for the stars.