CTO Advisor 65 - Defining the enterprise architect

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

Hey, how's it going? com. You're listening to episode 65 of the CTO Advisor podcast. You know what? I'm at DockerCon Europe 2017 and we are going to play back a podcast me and Mark recorded back in August at the VMUG UserCon in Indianapolis and I think the material is so relevant. It's basically what's the value of an enterprise architect, what's a good enterprise architect, and what's good enterprise architecture. We sit with two enterprise architects from the VMware community and the lessons learned from this podcast I think are applicable across the board of all IT in general.

So I hope you really enjoy the podcast, but first I'd like to thank our sponsor Druva. Druva delivers the industry's first data management as a service, a single SaaS platform that unifies data protection and management for endpoints, infrastructure, and cloud applications. Unlike traditional systems, Druva aggregates this business-critical data for scalable backup and disaster recovery while also unlocking the true value of search and advanced analytics for the governance of that data. For administrators, Druva means simplification. For IT leaders, Druva means scalability.

For your CFO, Druva means saving a boatload of money. For InfoSec, Druva means security by design and to the highest standards. For VMware and Nutanix environments, Druva means backup, disaster recovery, and archival, all powered by AWS. Druva roughly translates to saving your butt from data loss, litigation mishaps, and regulatory fines. Druva, the future of cloud data protection, now our discussion. We don't get a chance to podcast live often, and when we do, they don't turn out well because we talk a bunch and then we have equipment failure.

Hopefully no equipment failure today. Hopefully not. Right in the middle of good questions. Which is a great, I think, introduction to our next topic, which is on enterprise architecture or holistic IT, as Mike brought up, one of our guests. So we have Mike and Brian. Mike, go ahead and introduce yourself. So thank you for the introduction. Mike Burkhart, VMikeB on Twitter, Solutions Architect, guitar player, beer brewer, lover of things. Bourbon drinker. Hell yeah. Byron, what about you?

Sure, I'm Byron Schaller. I'm at Byron Schaller and all the things. Principal architect over at Roundtower. So it's pretty cool. We were just randomly going out and grabbing people and off the show floor and pulling them in and saying, you know what, what's top of mind? What are you dealing with in either your customer or as a customer or as a vendor? This topic is enterprise architecture. You know, are we doing it well? Are we not doing it well?

What's the business impact of not doing it well? So let's start out with what's... So Mike, you brought up the topic. What is good enterprise architecture? Like what's ideal? So I mean, it's a broad paintbrush. My thought on the topic is basically, you know, enterprise architecture has to be dynamic, flexible, and yet structured, right? So there's always that push and pull between things that, you know, like a framework or something that's a little more rigid to provide buckets to fill in, right?

To say, okay, well this is my database architecture or this is my automation orchestration layer, etc. But, you know, my curiosity lies in the fact that our framework's restrictive as well, to the point where we can't remain agile with the business. So am I tying myself into certain mentalities and certain architectures that constrain the business further down the line? So the idea of, you know, holistic IT, quote unquote, is just the idea of, you know, am I looking at the business from a holistic perspective of not just, you know, automation orchestration or infrastructure or development or EUC, but am I looking at how all these things fit together and ensuring that, you know, I'm flexible, I'm meeting the business needs, and also I'm not just tying into, you know, X structure that looks like this for 10 years or however long.

Can we simplify that and say that enterprise architecture is about driving the needs of the business, not driving technology? Yeah, absolutely. I would actually say that it's about getting IT to give the value to the business or help the business realize the value and the plan around that and how you get there. I mean, they really are the bridge between the business and IT, and it's their job to make sure that what he is doing serves that end goal. So, Mark, you have a lot of experience with this.

Enterprise architecture, when it's clicking on all cylinders, what's the best case scenario? Where do we see practically the value? I think best case, your business comes to enterprise architecture with a business problem that they need to solve, and they don't know how. Enterprise architecture takes technology, community, social, all the things about the business and combines that and partners with them and all of the lines of business IT and comes up with a solution. It's all about finding that business value for the company without driving you towards that technology or that technology or that technology.

None of that matters, right? It's all about how we drive business value and move that business value up. So, let's talk about what makes bad enterprise architecture. When have you seen either, anyone can take a stab at this, enterprise architecture done wrong? Like, oh, that's architecture maybe, but enterprise architecture? Start with product. When you start with product, every single time I've seen sales teams do it wrong, I've seen architects do it wrong, and you say, wow, this is a really cool thing, I want to do that, and it doesn't serve your needs, you know?

Or, well, this product's really cool, but it doesn't have these feature functionalities, so I'll just build them in, you know, where something else may fit your needs better, or no solution at all, you know? So, you know, you start starting with product is always a focus on fail, right? So, in the enterprise, that can be a little tough. The, you know, you, we've gone through these tool rationalization project, projects in which we said, okay, we have 30 tools, we need to get the tools down to four.

And, Mark, you, you've had, I think we've talked about this in the past, what happens when you constrain your, what's the balance between constraining your, or limiting the number of vendors you have, versus constraining your architecture team to come up with the right solution? Well, you've got competing things there, right? On one hand, you've got a procurement department that wants to minimize the amount of vendors they're using so they can maximize the discount. On the other hand, you've got the, the architecture team who wants to maximize the business value.

Both of those things are providing business value in different ways. So, you really have to work together. Enterprise architecture isn't a silo, right? It's not, it's not a person, it might be a role, but it's something we all have to do so that you can balance those. Otherwise, you're just going to end up, you know, moving the bar on the right up just so you can move it down on the left. That's a, oh, Byron, you're gonna say something? Oh, sure, yeah.

So, it comes back to operational complexity as well, and you'll be able to actually operate your environment in the same way. I think that's really all the, the architect to figure out where that balance is. So, allowing flexibility of tool sets so people can work the way they want to, and at the same time, have a manageable environment that's, that's not overly complex. That is a very fine balance and definitely a trade-off, but that's what enterprise architecture is all about. It's about those trade-offs, and how do you best serve the business, and how do you best, you know, realize, you know, that value for the lowest possible capital expense.

So, Byron, I'm interested to know from your experience in consulting, when you're going out speaking to customers, and they, you know, a lot of times they'll come to a show like the V-Mug or VMware, VMworld or Oracle World, and they'll come to you with a product. How do you get them thinking beyond the product to solving the business problem? It really depends who you're talking to, and kind of where they are in the value chain of the org. The higher up the chain, the closer you're going to get to the business problem.

When you get to the folks who are doing all the implementation and the, and the management, they're very product focused, because that's what they do, you know, day in, day out. So, really, it's, it's a matter of getting that, you know, executive stakeholder to really drive that initiative around a business problem, getting them involved in saying, okay, what's, how does this meet, meet your need, or really, what is your need? What are your requirements? I think there's, there's a book that kind of defines, at least the titles, start with why.

Yeah, I haven't actually read the book, but I think just the title alone. I think it's a fantastic book. I don't know anything about it. Well, yeah, you need to start with why you're doing what you're doing. So, that leads to some really strange conversations with clients. They'll be like, we want to go cloud-native, we want to, you know, lift and shift all this, and I'll just sit there and say, just why? And they get, and they stop for a second, because they didn't expect to be asked why, and why, what's the value here?

What, what are you trying to accomplish? Then they think about it, and they're like, well, really, we just want to, you know, drive our earnings per share price, and like, okay, well, this is not the way to do that, so let's talk about that problem instead, and, and then you can relate IT back to that, and that's when, if that works well, they realize real value, and that's when you become that, you know, trusted advisor kind of role, as opposed to just, you know, another vendor they have.

I had a similar scenario with a hospital customer of mine that they were, we need stretch clusters, we need stretch clusters, you know, just going down that path, and just every time, I'd say, why? Why, why do you need, you know, what's your requirement? Is it availability? It is a really cool technology. Yeah, oh yeah, and their storage guys were loving the idea that they could make it very complex and very interesting to them, and I said, interesting is not availability, interesting is not business resilience.

Interesting is not business value. Yeah, exactly. Definitely not. But actually, if, if you don't mind, I'd like to go back to something that Mark said on the procurement side of things, where when we first introduced the idea of, like, architectures and frameworks kind of locking in, or making things a little more rigid, you know, it's possible to think about business procurement and business processes confining architecture and enterprise architecture to almost debilitate business use cases. I don't mean that in any sort of negative way, but I have seen that, you know, like hospitals, again, they, a lot of hospitals like to buy into something, pour concrete over it, and call it done, because they need stable architecture.

Well, and then sometimes the vendor selection there, Epic, right, you're talking about a hospital, so we've decided to go with Epic. Now you're locked in to a certain set of choices, and you're not changing from those. Absolutely. You see the same thing with SAP all the time, right? It really comes back to you, what's driving this, to start with. And there's some politics, and there's agendas involved, and there's, you know, sales folks have, you know, certain champions inside organizations that try to drive their agendas, and really, you know, a good EA is going to balance those, and say, you know, understand why the person is saying what they're doing, and like, there may be, you know, vendor X has been there forever, but vendor Y has some personal connection to the business, that it's, that stuff gets very tricky, and being able to manage all that, and manage the personalities involved, is almost as hard as the technology itself.

So one of the things, being an enterprise architect, is stepping back and looking at the big picture. So we've talked about looking at the big picture from a business perspective, but Mark, you've mentioned SAP. There's, in a healthcare environment, there's Epic, there's these extremely heavy applications that IT has to revolve around, and this is a little bit pre-recording, we talked about this a little bit, about what does it mean to take a holistic look at technology. So we've taken a look at the business processes.

What about the technology itself? As people are going out and solutioning, we've gotten past the selecting engineering based on a product, to the business problem. What are the considerations when you're architecting for a large environment, or small environment, and you need to prioritize the solution based on these heavy applications, these center gravities, or the relationships between those? You know, I think that can often be hard, but I think the first thing you need to look at is the user experience, the end user experience.

You define what they need, now you have to talk about how they do it. Because if you can give them a way to do something, and they can't actually do it, you haven't really solved a problem. You've just created another problem that's probably more expensive, and wasting their time. Yeah. Right, so starting with the user experience is where I like to start. So that sounds an awful lot like a system. So from a business process, or a user experience process, you know, we can give VDI as an example.

The users need to be, you know, we've always heard this axiom that don't move the data, move the compute closest to data, and an easy solution for that is VDI. So what are some of the common mistakes, as people might say, okay I'm going to deploy VDI, and put users closer to the data, but there still ends up being a overall architecture problem. So really, you have to look at it from all angles. Like, so there you're solving the data problem, but what about the latency problem?

What if your users are devs over in India, and you've got, you know, 500 milliseconds of latency? It's still going to be a bad experience. So you have to take into account all facets of the service that you're offering, not just one. So like, there where you're focusing on data locality, that solves that problem, but that could open up other doors of really unintended consequences. So really keeping those, I guess, in mind is what makes good architecture, I think. And I think that's one of the reasons people are gravitating more towards buying solutions, rather than trying to build a solution, because your core competency at your job is probably not VDI, right?

That is not a business differentiator for you. So more and more people are starting to embrace it, and we saw this starting with hyperconverged infrastructure and, you know, SaaS software. Why build a solution when somebody else has already figured out the way it works? And also, I mean, going a little granular on this too, when we're talking about user experience, it doesn't matter what the application is, you need to, from a higher level, define expectation and baseline. So whatever KPI is, whatever metrics you can gather and select and say, these are the things that are going to define success.

That also must be a requirement for your design to ensure that not only is the business protected, but you have SLAs, SLOs, you know, things that make that architecture successful, so you can monitor and ensure that those are delivered. Because ultimately, it is about the user, and if those aren't, if that business service isn't available or it's slow or non-performant, then your user and business ultimately suffer. And I think that's actually a great point, documenting how something is supposed to perform, you know, a performance baseline.

So user doesn't say it's slow, we need to define what normal is, right? And that's difficult. It's very difficult to do. Well, just KPIs in general, I mean, that's half the battle, is knowing what that KPI is that you need to look out for. I talked to a lot of customers who have really no idea, because they're either new systems or they're unfamiliar and they don't know what they should be looking out for. And that's one thing I'm really excited about with like these new APM solutions that are coming out in the past couple years, the granularity you can get with like latency between different components, just this visibility that we've never had before.

That's, I think, really driving that up and making it easier for people to understand. Yeah, I think we've done this, if you build it, they will come and, you know, business for a while, and now that's not good enough. We've known that's not good enough, but we've been doing it anyway. So I think it's about how we move away from how we've historically done it into a new way. So let's talk about skill set for a second. So we know enterprise architecture may not necessarily be a specific position, but there has to be someone leading or someone or some team leading the thought leadership portion of what does it mean for all of these things to interact?

What does that look like either in a from a reseller, a VAR, a enterprise looking to help set direction? What's the critical types of skill needed to provide that oversight? Visio? This is a very bearded episode. This is the beard cast. As far as skill set goes, I mean you really have to have someone who has deep experience across a variety of enterprises, hopefully. Or people, right? It doesn't have to be a person, it can be people. Situations, because here I think experience matters.

Just you, things have not always gone right in your career, and things have blown up, and things have failed, and the more that you understand how things fall apart, the better you are to build them successfully. And I just think that that skill set is something you can't teach. You just have to just acquire through your life experience, and that's I think paramount. Then beyond that, just being able to be a solid communicator, and bring folks together, and really have productive dialogue as opposed to just playing this politics game.

I think something you overlooked is you have to know how the business works, too. You have to understand not just technology, at least at some level, what it is your company does. In an enterprise, what your company does, a lot of people don't know. You're a storage guy. What do you do? Well, I work at a financial services company. Well, what does that mean? How do you profit? That's difficult. The other thing, too, and not to get mushy on anybody here, but I think empathy comes into play a lot.

When you said leadership, that kind of clicked with me in saying leadership isn't always telling someone what to do. Leadership can be helping along the process, where your customers are going to be way more knowledgeable about their business, from a partner and VAR perspective anyway. When we go in and help customers with business transformation or enterprise architecture, it is more us listening to their needs and trying to understand what it is they're trying to accomplish. From my perspective, personally, I always say, what sucks?

What sucks and what can I make better? At the end of the day, how am I going to own this with you? It's a partnership. There's some empathy there. How am I going to help you and how are we going to succeed together? That goes back to the business value, too. It goes back to knowing what you're trying to accomplish together. Last question. We can't get out of this topic of enterprise architecture, holistic IT, without talking about the cloud.

Mark, I think you made a really great observation that as customers, we're looking to buy solutions now. I think one of the great things about AWS, Azure, IBM, take your pick, Google Compute, is that now you're buying a solution. Let's focus on infrastructure as a service. You're buying a solution in infrastructure. You can move talent higher up the stack or you can move the skill set to focus more on business. What are some of the practical gatches or considerations when you're pulling in cloud operations into your overall enterprise architecture plan?

I think the first thing you have to really consider is, will your application be lift and shiftable to the cloud? Is that just going to fail? Not more often than not, but very often, if you try to lift and shift something, it just simply doesn't work based upon how your users and it interacts. That's key number one for me. Going along with that is, do you have to rewrite your application? If you're going to rewrite your application, do you really want to do infrastructure as a service or do you want to just get some platform and consume a platform?

That's dead on. The first thing someone says, let's go to the cloud, this is a giant red flag of why, what are you trying to accomplish? When you try to solve application problems with infrastructure, things usually go awry. If they go well, then you honestly got lucky. Knowing that application architecture and how that actually works, like is it a three-tier application? Are you decoupling? Is there a pub-sub? All these things that get drawn into complex applications, you have to really understand.

I think that's made complicated because historically, things like application resiliency have been an infrastructure problem and they can't continue to be. That's the dirty secret of emotion. It's so great that it solved that problem for the past 10 years that people have forgotten, at least some folks have forgotten, that when that goes away, there's consequences there you have to account for in your application being resilient itself and having circuit breakers and failing well. I think that's something that we've lost in the past decade that we need to remember.

I think what's interesting too, talking about years past, we're seeing similar trends from moving to the cloud that we saw when managed services providing started around. First it was build your own data center, then it's well, I want to get out of the data center game, but I just go to hosting. But you lose some control there. I don't have hands and feet there all the time, so someone can do that for me. Maybe I don't have my own switching network or my own firewalls, but they're provided to me as a service.

Well, great. But then I have a loss of certain functionality because those are selected for me. The building is selected for me, the cooling is selected for me, the power, etc. So in the cloud, you have this added functionality of scalability, elasticity, this very dynamic sort of platform, but you also don't control that. Going back to Mark's lift and shift versus build new, if I'm lifting and shifting the application to the cloud, I'm lifting and shifting the application that I've built processes around, such as, to your point, the ability to monitor the switches, the storage, the underlying compute, and understand the telemetry data and how it impacts application performance for the application that I lifted and shifted.

But I don't have any of that visibility in the cloud, so I have to come up with a new operating model of how I manage this application that was built with the ability, the vMotion, for resiliency in an environment that just doesn't even have that concept. So there's quite a bit to consider. So we're at that point where we need to wrap up. This has been an incredibly informative conversation. I appreciate you guys stepping away from the user con to talk to the audience.

Where can folks find out more about you and the work that you do? Mike? com. com and at vmikeb on Twitter. I'll say ridiculous things and post Beyonce gifs. You're welcome. What about you, Byron? Where can we find you? Sure, so on Twitter at Byron Schaller. io. com. com. And you can find me at CTO Advisor on Twitter. com. Talk to you guys next episode of the CTO Advisor.