In this interview, we speak with Dr. Michelle Supper, a senior advisory executive architect at Service Now. In this role, Michelle consults with a wide range of enterprises and their enterprise architecture practices to help them with their digital transformations. In this session, Michelle draws on her wealth of experience and gives her insights on how EAs can have the most impact on a company's digital transformation journey, in the particular the subtle and oftentimes overlooks the role of EAs in translating the vision and the needs of a transformation between all the layers of a company - from the C-Level on down
In this interview, we speak with Dr. Michelle Supper, a senior advisory executive architect at Service Now. In this role, Michelle consults with a wide range of enterprises and their enterprise architecture practices to help them with their digital transformations. In this session, Michelle draws on her wealth of experience and gives her insights on how EAs can have the most impact on a company's digital transformation journey, in the particular the subtle and oftentimes overlooks the role of EAs in translating the vision and the needs of a transformation between all the layers of a company - from the C-Level on down
So Michelle, welcome to the show. We're delighted to have you on today. I think it'd be great for our audience, if you could perhaps just introduce yourself, who you work for what you do for them, and maybe a little bit of a potted history of your career background. Okay, thank you. And thank you for having me here. I'm Dr. Michelle sapper. I'm a senior advisory executive architect at ServiceNow. Been here for two and a half years. Before this, I was working as an as an independent Enterprise Architect, as a consultant working in public and private sector, for ministry of defense and all kinds of projects I can't tell anyone about. But here at ServiceNow, I help people to do major digital transformations, particularly within our platform and seeing how they can get the most value out of platform based thinking. Fantastic. So an independent Enterprise Architect, consultant. Sure. And also in the role you on on ServiceNow. I imagine you get to see lots of different Enterprise Architecture organizations and approaches, and probably a good view of what goes well, and what could do better. Is that right? Oh, yeah. So I get to see enterprise architecture can use across all kinds of organizations, really, from banks, to consumer based retail type organizations. Also, like my work with the open group, I get to see how various different organizations use Enterprise Architecture there as well, I get to experience the enterprise architecture from hundreds of different companies by by getting to meet people through our organization. Fantastic. Well, the topic we're going to talk about today is how enterprise architects and Enterprise Architecture organizations can build the case to be part of digital transformation. That's the sort of question before us. And I'm really looking forward to getting your insight. But maybe before we sort of go into answering the question, we'll begin by, you know, digital transformation. Michelle, we hear that phrase all the time, it's somewhat tired and overused. I mean, almost everything is just transformation. Could you just give us your definition, when you when you talk about that what you mean by it? Yes, it's a little controversial, really, I'll give you my approximation to a definition, I'm sure everyone's going to have their own version. There's a difference in my mind between change and transformation. So something which is involved in change, often swaps one technology for another, but doesn't materially change what a company does. A transformation is something which can affect or improve, or even introduce a whole new business capability to an organization, something which is far more substantial than a change. So if you're doing a digital transformation, then that new business capability is achieved through the use of information technology, or the use of data. And is that I love that distinction, change and transformation. And you use the phrase, their business capability is that in your mind is that kind of like the currency of transformation, we're talking about establishing new business capabilities or eliminating your business capabilities at the primary level, can we also transform I don't know, technology platforms and processes and things like that as well. So business capability, and Enterprise Architecture comprises people process and technology. It's one of those very rare artifacts within. So it's one of those very rare stereotypes within architecture, which actually encompasses other stereotypes as well. So when you talk about changing your business capability that can involve changes to the people within an organization. So it's organization structure, the roles, staff. But it can also mean changes the process, the way that they do something, and the technology that they use. And underlying that, if you want to extend the definition, the data and how that flows through their organization, even the infrastructure that it sits on. And I know business capability based planning sort of emerged in popularity over the last decade or so do you see it widely used now? Is it widely adopted? Is that generally a concept used by enterprises or what's your what's your experience of its its adoption? It's certainly something that ought to be adopted by organizations. The organization's I've seen the maturity of Enterprise Architecture capability that they have varies. The best organizations do have their their capability maps absolutely sorted out. And those are used strategically to plan what the organization is going to do. And everything is aligned to that capability map. When, when an organization has a capability map. I know it's one of the first questions I asked them if they say yes, we have that map. I know that they are really good at Enterprise Architecture. I know this taking it seriously. Because when you have that view, you can connect the different layers of Enterprise Architecture together, and you can start to think holistically about your organization and make changes which are going to be aligned into the strategy of the whole organization. I got it. So our topic today is how enterprise architects can build the case for participating in digital transformation, just by the words you're using. It sounds like enterprise architectures have to be completely intimate with it, they're necessary for it because transformation effects capabilities and capabilities is a sort of grouping of different Enterprise Architecture components. Is that Is that how you see it? Yes, absolutely. Too often, I'll see a customer who maybe says we want to change everything. And then just say to them change what and they won't know exactly what it is that they have, even if you say, what applications do you have, they can't give you a list. If you say, how are the applications that you've got linked together, they couldn't possibly tell you. If you're in that kind of a situation, as an organization, it's very stressful, organize that stressful situation to be in, you can't manage what you don't know you have. And you can't effectively change what you don't know you have. So quite often, you'll find especially larger, older organizations almost paralyzed and unable to shift or to change or to be agile, because they have so much technical debt, they have so much legacy software, they're afraid, and they don't know what they can turn off safely, and still maintain all their normal operations. So having Enterprise Architecture having that insight to say, yes, we have these systems, and we can manage those properly. Or we can take these out and substitute something else, or we can move this functionality on to something else. That's tremendously powerful. When you're trying to do a transformation, and you want to move a significant amount of functionality from one place to another, let's say from old legacy software onto a platform. Or if you wanted to retire a whole bunch of applications, you really do need to have that wider insight, you have to be able to see what you have. Right, exactly. And it's I always think about it like, it's a collection of these processes, and organizations and applications and technologies. They're all massively interconnected, and the enterprise architects role, they want us to figure out those interactions. In fact, I had Roger Belden Belden on the processor new group a couple of weeks ago, and he just wrote a book called collecting, correcting and connecting the dots, which seems to be the case. So it seems to me the case is pretty straightforward for why Enterprise Architect should be involved. But how do they make the case to perhaps the business stakeholders who don't necessarily Fathom or understand enterprise architecture and maybe see them as the standards guys, for example, which I know is oftentimes a stigma that the enterprise architects come around with? Well, there's there's nothing wrong with standards. Having contributed to eight international standards, myself, I can wholly support standards. But yes, it's often what you'll find in a larger organization is you'll have sea level people who are concerned with strategy, they have very high level thinkers, they look down from a great height at the organization and see the whole thing and will try and make decisions. But what they're unaware of other things happening in the lower down layers, where the politics is very different, where the experience of life is very different. And so the changes that the people at sea level feel they need to make could be very different to change, transformation programs or change programs that are happening in middle management, and then again, how people feel at the end user stage about how they want to protect certain parts of their work. So you might have a whole group of users whose entire career centers around the use of three or four individual pieces of software. If those pieces of software are retired, that say they won't know what to do, they'll need retraining. And that's very stressful for them, they might then be resilient, resistant to change. And so there's this whole spectrum where we have to try as enterprise architects to understand the needs of the whole organization. So understanding the drivers and the goals of the sea level. And at the same time, understand the stresses and the pressures happening further down in the organization. Bring all these things together and into alignment, and help everybody to make that journey together. So that everybody is supportive of the changes, that's going to happen, everyone can see the benefits of those changes. So when we when we start to bring the architecture diagrams together, there's there's an interesting twist and how things are communicated. So the message up to C level will always be quite a high level view, quite abstracted, showing solution concepts, bring everything back to the high level strategy. And then the lower down the organization you go, the more detail you have to include all the way down to the level required for implementation itself. How will the data flow which things will be integrated into which other things, even down to data fields, sometimes to say, this data field has to be mapped to this one so that these two, two applications can communicate. So each layer has its own level of communication, and that you have to make very clear. And so you're communicating through those layers. And you're communicating between the layers to make sure that the needs of each are made clear to everybody else. That's fascinating. I've never really explored that area before. And it's fascinating you bring it up. I mean, Enterprise Architecture often has the reputation of you know, it's boxes to connect it to boxes with lines, you know, in nice diagrams, according to some standard that you're bringing in a whole new layer of consideration as enterprise architects need to understand organizationally politically, how organizations work and their role, the way you talk about it is very much been that lubricant for change by by facilitating communication from the top all the way down, and making sure those pieces of messes that how you see it. Yes, absolutely. There's a huge communication piece, often translating so particularly when you still work with with defense industry, though, there was a translation job that I would do sitting effectively between the people at the top who held the budgets with a business minded, and the people at the technical side, who are concerned with the detail of how systems will be put together. And the two spoke very different languages. So trying to explain and communicate the needs of each to the other side, in language that each could understand. It's really important. But also trying to make sure that the benefits could be extracted. So when when a technical team said we want to do these things, I was trying to translate the things that they wanted to do into business benefits that the budget holders could understand, and therefore support as interesting. And I wonder they ever had seems to me some one of the big things is always difficult to quantify the benefit of is the paying off of technical debt, we know we should pay off that technical debt. But it's hard to articulate in hard dollar terms exactly what the benefit of that is. And when when we might receive that benefit. Is that an experience you've had like? How do you make the case for doing just hygiene things and cleaning up that technical debt, sometimes application rationalization is something I specialize in. And you see it, particularly in older organizations, ones, which have had a few decades to accumulate a whole bunch of different applications. So when an organization starts, they will have a very clean set of applications. And then as the years go by, some of those will be taken out replaced, or move on to other stuff or take on new ones. And if they haven't got good governance in place as well, they can quickly mushroom. So within a few decades, I have several 1000 applications in use across the organization. I don't want to give personal examples here. There was an organization I found once a national organization that had 79 different case management systems, wow. And across the whole country, what that meant was that if if someone was if they if the details were put into one of these case management systems, if it had to be transferred, transferred to a different one, none of them were actually connected. So it had to be printed out, posted, and then re keyed into the new systems. Every time this happened, you're looking at work that has to be done. It's manual work. And you're looking as well, because as is 79 different systems, each of these has to be maintained separately licensed separately paid for separately. And all the staff internally have to know how to use those different systems. That makes it very difficult. So let's say you've trained a member of staff five years of being on their job in one particular area, they decide to move, they want to stay within the organization, they go somewhere else to do the same job. And now they have to learn an entirely different toolset. So simply by having all these different tools within the organization, it stops people from being able to move easily. And it multiplies the amount of cost and complexity. And that's before we start looking at how these tools going to integrate with other systems and how all of those integrations then have to be maintained when all the other platforms and applications have to be updated around. So there's there's a there's a cost argument you can make absolutely you can leave yourself a bunch of licenses or whatever that might be there's just a management overhead a headache argument you can make less headache not dealing with 79 systems. And then it seems to me your third argument isn't agility argument. We can be agile, we can move faster, we can do things better. And I imagine that center nine systems that's that's crazy. And I imagine you know, particularly companies who have been through large rounds of m&a and bought a bunch of other companies have ended up with an application sprawl, as we call it, often you'll end up with duplicates, you know, two or three different ways of doing things just because of merger Because the organization's merge, but the tools don't, you know, from my background, my PhD is in astrophysics. So I used to look at how galaxies merge is interesting, where two galaxies hit each other, the stars never hit each other, they're far enough away, they don't, what hits each other as the dust. And, and it's the same, you know, when the dust clients with each other when two galaxies merged, you get a whole load of stuff formation and clouds and activity going on. And it's the same when two organizations bashed together when they when they emerge in an acquisition, because then you have the the applications will just sit there. But what clashes will be the data and the people and the processes and you will have all of these duplications of functionality and complexity that gets introduced into a system, which will slow everything down unless it's actually handled properly and mapped properly? By preferably an Enterprise Architect using capability analysis? I like that so and two companies merging like galaxies colliding. Now, you talked a lot about business capabilities. And you talked about your role. Many times have been that at the translator, I've often heard said that business capabilities are like, the Rosetta Stone, like the common language that both technology people and business people communicator, because we all recognize that business capabilities is that where you found business capabilities are not used anywhere near as much as they should be. But if they are, then yes, business capability is where the layers of architecture meet up. So in the in the TOGAF, the The Open Group, Architecture Framework way of thinking, then you have different layers within the architecture. So you might have motivation layer, so why do you want to do something and then the business, the data, the applications and the technology, and often we can look at those different layers, separately, and then the TOGAF, ADM, you might look at each phase and do views and each phase separately as well. The capability map is a place where you can start to pull together elements from all of those different layers, because it combines that the concepts of of people and process and technology and data and and and it means that you can start to bring that data in and cross reference it and collect it together. So there was a piece of work I did at at one of the government ministries. And I drew a diagram, which showed how their business capabilities lined up with the applications that they were using. And it was the first time that that organization had ever seen that connectivity, before the people would be managed separately by HR. And the application has been managed separately by it. And both of you know, there's very siloed organization, you're looking at different management groups, different budgets, and so on. And there was no alignment between who was using tools to do what, right, it sounds obvious. But when you start to link those things together, that's when you can start to see all kinds of things use duplication of function, you can see processes that were convoluted and take too much time. And huge savings can be made just by looking, doing capability analysis, also looking across value streams. So a value stream enterprise architecture will connect between the different capabilities. And we can start to join up the different processes that take place. So here at ServiceNow, we focus on automating workflows. So another way of looking at that would be looking at value stream end to end. And if you're trying to look at that lifts that idea up all the way to that value stream level, you can say end to end, that can be automated, how much of what we're seeing in this end to end value stream could be moved onto a platform could be moved on to a different set of software, how many of these processes could be joined together? And when I do that the fragmentation goes away very quickly. And you can rationalize very quickly. So what I'm hearing is our original question is, you know, how can enterprise architects you know, position selves participate in digital transformation, the first thing we talked about, it's not just nice to have, it's a must have. Because what enterprise architects can do is understand the interconnectedness between all of these different things like applications and processes and technologies that will hopefully manifest itself in business capabilities. And then the second thing he talks about, which was, which was really interesting for me was they also have a communication role. Above and beyond, you know, TOGAF and architecture diagrams and things like that to communicate between the different layers and as you said, to be that translator, from the business down to the technology and make sure everyone understands what's, what's going on. And then finally, we talked about business capabilities being possibly that Rosetta Stone that common language or lexicon that we can use to orientate ourselves that I missed anything that sounds about what we talked about. There is something that's before you get into The detail of understanding about applications and how things fit together. If someone's considering doing a major digital transformation, I would start all the way up at the motivational side as high as possible, and really understand what it is that the organization's high level strategy is first, and then what's driving them to change? What are the pain points, what are they experiencing at the moment, which isn't working. And then in relation to that, what goals would they like to achieve? When all of those things are connected together, you have your strategy, your drivers and your goals, then you can make sure that any changes you make in that transformation, are aligned with the company's strategy. Because what you really don't want to do is start making a whole bunch of changes, which don't relate to the strategy at all, because then you're going off on a tangent, but it's very easy to do. So one of the nice things about architecture is it lifts the list, the desire for change, and the motivation for it away from, let's say, an individual person or a small or non representative group of people, and lift up to the views of the whole organization, holistic view, and then you can be sure that any changes you make are actually in line with what the whole organization is trying to achieve. I see. So it shines a bright spotlight on the reasons for change and make sure that that's aligned to the overall corporate strategy. Well, fantastic. Michelle, could you give us three key takeaways, and that can be the first one if you want, we've got to start with motivation before we get down to execution. But if you only give us three key takeaways, that'd be fantastic. Absolutely, yes, that first one, get that holistic view, you don't want the opinion of just one or a few people, you don't want it to be the pet project of one person, you want it to be something beneficial to the whole organization. The second one is if you use Enterprise Architecture, particularly with standards, then what you have is a common language, which can be understood by all the different teams working on a transformation. And that way they can share their diagrams and their data. And they can work together on one project. And you don't have a very fragmented project. So things run on rails when, when you're using Enterprise Architecture. And the third and most important thing about using architecture in any context is it helps you to plan changes in advance. So you can map out what you have now. But then you can map out options for the future. And you can make those tweaks on paper before you start to implement things. Implementation is very expensive and very difficult. So do it on paper first, it helps you get it right first time. And it helps you to validate your ideas and disprove them if necessary. And you can help build a business case as well with evidence. So yeah, I like that. So getting it wrong on paper is a lot cheaper than getting it wrong in real life. I guess that's the takeaway from that third one. Michelle, thank you so much for your time. It's been an absolute pleasure talking to you and I'm sure our viewers really listened like the insights that you provided. But once again, Michelle, have a great day and thanks for your time. Thank you very much.