Joe Gottlieb: (00:02)
Welcome to transformed a Higher Digital podcast focused on the new whys, the new whats and the new hows in higher ed. In each episode, you will experience hosts and guests pulling for the resurgence of higher ed while identifying and discussing the best practices needed to accomplish that resurgence culture, strategy and tactics planning, and execution people, process and technology. It's all on the menu because that's, what's required to truly transform. My name is Joe Gottlieb, President of Higher Digital. And today I'm joined by Gwen Krediles, VP of Services at Higher Digital based in Amsterdam. Gwen, welcome to transformed.
Gwen Kerdiles: (00:55)
Thanks Joe. Great to be with you today. What do you want to talk about?
Joe Gottlieb: (01:01)
Well, since you are a bonafide enterprise architect, and because we've been talking a lot about technical debt lately, I'd love to talk about the role of the enterprise architect as tech debt slayer. What do you say?
Gwen Kerdiles: (01:16)
That sounds good. I probably even have that slayer hat from when I was a teenager. I like that title very much. To me it compasses three facets of today's story. First, the tech debt, the “whats”, and we probably should start with clarifying the semantics of what technical debt really means. Then the “why.” Why EA principle should be applied. And finally, I hope that we can demonstrate “how” to achieve that tech debt relief really Slayer.
Joe Gottlieb: (01:54)
Awesome. Well then let's dive right in. As you suggest, let's start with the definition. What do we mean when we say technical debt? So Higher Digital defines technical debt as the deferred maintenance costs resulting from prior technology decisions, and we've intentionally hijacked a term deferred maintenance that is known amongst chief financial officers, financial planners, etc., because it represents typically in our real estate and other sort of hard assets, the cost of not keeping those assets maintained and whereas traditional deferred maintenance accumulates over the life of the asset as you'd expect something aging, digital assets don't age in the traditional way, but they do age in the sense of technology advancing. So there's that same effect of technology becoming, let's say more obsolete over time, but different from the deferred maintenance on, on hard assets that we tend to see normally in accounting, technical debt also ends up happening right at implementation when technology is often implemented with poor practices, particularly poor enterprise architecture practices or implemented without the benefit of enterprise architecture. So that's an important way to think about, you know, technical debt as, as we define it. So with that definition in mind, Gwen, w what are some of the symptoms of tech debt? You know you have tech debt when what's happening.
Gwen Kerdiles: (03:32)
Well. Yeah. You've got plenty of classical symptoms of technical debt. Just take an example, hardware. Hardware is a classical problem in any enterprise. You can detect the technical debt when you start to regularly apply hardware band eight, just to be able to run your current software. Your upgrades are pushed to you by the operating system, and that's, that's probably, something that a lot of our listeners experience quite often and have to make concessions. You want to deploy your new service and you can't do that just because the hardware won't be able to support that new service, or won't be able to scale up. So that's an example of how you can detect that you take care of technical debt. Another area where you see it is when you coach some software or some services, some SAS services, and the vendor provides to you or advertise those new features that your business wants to adopt, or you and clients monster adults.
Gwen Kerdiles: (04:54)
And you can't simply because you're not on the last version of the platform or the software, or you're not able to adopt it because of technical debt. And it results in tensions between the different groups in your organization, um, that, that supports those end clients, the business and the IT group, for example, and the leadership of course. And one thing I've seen in the world of higher education, and I won't mention any vendor here, but there have been several cases of universities running systems that have been running for a long time and have not been able to keep the system up to date. And certainly they were asked by the vendor to totally migrate to another. And these are nightmare stories for the industry. I think a very salient or the area where you detect and measure technical debt is for all the internally developed software. You detect that when it takes longer than expected, longer than in the past to correct bugs when you, um, when your cabins of new features that the business wants to you to develop or adopt, uh, take longer to be developed. So these are the typical symptoms of technical debt.
Joe Gottlieb: (06:42)
Excellent. So if those are the symptoms, let's take a look at the sources, right? And some of these are going to, I think, coincide with the examples we just provided about the symptoms as you would expect, but I've got a few here I'd like to share. And then I know you've got some others that you would add to the list, Gwen. So for me, the biggest one that is so necessary to talk about is customizing purchase software, uh, particularly SAS, but, but also software that you would then run on your machines or your private cloud, uh, both are, both are, uh, quite prevalent issues and quite prevalent sources of technical debt. Because when you deviate from the it vendors standard approach, by customizing it to fit the way you operate today, you are in effect putting yourself off on, um, you know, really this is really going out on a limb, you're leaving the trunk of the tree, and as the tree continues to grow, it's going to wind up leaving you behind and cause more issues than probably the value that you obtained by avoiding, um, what you experienced to be, uh, a high-impact changed your process because you've now tried to impose it back on your vendor.
Joe Gottlieb: (07:59)
So that's a big one. Another one would be when you're doing systems integrations and you're taking shortcuts. When you, when you get a new system or updating a system and you need to connect it to other systems via integration of those of those systems via the ways that they communicate and the data formats they use, there's a short, there's a fast way, and there's a slower way. And the fast way, often results in brittle connections that break later, uh, when you have an imposed, a certain architectural discipline on them. Um, and then, you know, the third that I would put on this list would be when you lead organizations, um, specialized too deeply in their purchasing of systems and then their development of systems. If you, aren't looking at the economies of scale, the synergies across the whole organization, you miss an opportunity to have fewer moving parts, fewer variables, which are always easier to manage and deliver a higher level of service and a higher level of agility and velocity in the future.
Joe Gottlieb: (09:04)
Then you would, when you let people specialize, you make these broad choices. And th the example I know Wayne Bovier, our CEO, likes to use is, you know, you don't really need your each division or department or school doesn't need its own, you know, Salesforce automation system. They're not going do any massive innovations there. And arguably that's true of the SIS, it's often true of learning management as well. There are ways to take common systems and innovate and show value without reinventing the wheel, uh, in terms of doing it differently in each of those areas. Those are a few that come to mind for me. How about you, Glenn?
Gwen Kerdiles: (09:42)
Yeah, I totally agree with you. I would talk about some points like, well, we mentioned it before the old ad hardware, and not maintaining the minimum hardware specifications that you need to have on your campus to serve your ecosystem and to run the software that you've decided as an organization to run. Another example I would like to use of a source of technical debt is the adoption of a new technology. And I would probably focus on the cloud and cloud migration here, adoption of that new technology before you were ready to adopt it. And a further one that, I would like to discuss further in a few minutes would be the choices, making other choices that are not adapted to your whole organization. So not doing a proper investigation of what feeds, what is required by the whole organization. I've seen many examples of universities adopting two complex workflow systems, or I passed systems tools that were very shiny and they thought that were very fit to bring them to the next century, but actually were not fit for the organization.
Joe Gottlieb: (11:23)
Got it. So great, great stuff. I love the, the it's a good list that will help our listeners identify, as we've said now, symptoms and sources of tech debt really in their effort to better understand it, better identify it, cause that's really the way you want to begin. Right? We recently launched a tech debt assessment, which we believe can very quickly help you identify some practices that may or may not be leading the tech debt at your organization in the context of higher ed. So we've, we've done that. It's on our website. I'd have our listeners check it out. It's very short, it's nine questions long, and you get some great insights and some correlation patterns that we've seen where I behavior on the one hand produces. Oftentimes, at least is at least correlated with an outcome on the other hand.
Joe Gottlieb: (12:14)
And so that's something you could check out, but if we move along here, let's talk now about the role of the enterprise architect, as, you know, as a mitigation point. And ultimately we'll talk about a really exciting role that we have in store for them with regard to tech debt. But first I want to contrast it with the role that we identified for CFOs. So when we did a tech debt webinar, and we actually invited a couple of CFOs to be on our panel because we felt that these forward-thinking CEO CFOs were actually already in a position of realizing that technical debt is an issue for them in the same sense that deferred maintenance is an issue for any CFO of any enterprise. Increasingly in this digital world, CFOs are need to be mindful about the cost of technology and not just the short-term costs, but also the long-term cost.
Joe Gottlieb: (13:14)
And that's where tech debt becomes plays a very, very interesting role. And so we found that this resonated very deeply with a couple of CFOs. We had them on our panel. It's a great discussion because we actually believe that CFOs over the next decade will become perhaps the lead champion for eradicating tech debt because they have this financial stake and in the implications of tech debt, and they are the stewards of the finances of the institution. And so given that role, we believe that they're going to play a great role in helping to eradicate tech debt. Now, the EA has a very different tool set and a very different sort of context for engaging with this problem. And so I'd like to talk now a little bit about, how does the EA step up in their contextual sort of role playing to really look at tech debt and make this something that is at least minimized.
Gwen Kerdiles: (14:15)
I like to come back to your CFO, to you mentioning this year for, in my previous job, actually one of the CFOs, he was very conscious of the tech debt, and it was funny to see him taking part in product development and those big discussions on where does the strategy need to put the focus in terms of development of our new products. And because he was very conscious of the investment that needed to be done at that point in time, and that depth that would be accumulated and that you will need to be, to carry in the future. I'd like to, to make a reference to one of those, quick poll that was produced at EDUCAUSE last year or comparison to the previous years and those results place EA in the context of digital transformation trends.
Gwen Kerdiles: (15:24)
And the, one of the emphasis is really on enterprise and enterprise E is a critical word in enterprise architects. One of the conclusion of that poll was that insufficient cross institution planning or coordination was one of the top buyer to digital transformation. And it it's even consistently a barrier year after year in those polls. And I know the conclusion of the same poll is that the cost of ongoing investment as digital technology advance remained a top barrier. And there, the EA is largely focused on that issue. And so here again, it can be part of the solution when it's available in the organization or parts of the intimidation or the problem when lacking.
Joe Gottlieb: (16:29)
So, so true. And so I think, whereas the EDUCAUSE quick poll we're highlighting in these, these barriers that you mentioned, you know, I would, I would just add that, that for our listeners, EA ends up becoming just a really important part of the team collaboration that's necessary and really the tool set for effective transformation, right? And, and as you said, when if you're on, on the best days, it is active and on the worst days, it's, it's not active or maybe even if you're not engaging, it can be one of the reasons you're not engaging because you don't feel equipped to tackle a transformation without some strong knowledge about how you're going to be smart about these technology choices, these technology investments that then can either lead to tech debt or minimize tech that there's always going to be some tech debt. We know we don't live in a perfect world and there's always trade offs. And so that's, I think an important thing for our listeners too, to internalize that, that this is not about theory, you know, back to your point, Gwen, about being very, you know, being very practical. This is, this is about understanding the best principles and applying them in your context and then doing your best, managing through an imperfect world, and then not letting the best get in the way the good and just be, you know, iterating through, so to speak.
Gwen Kerdiles: (17:57)
I agree with you. It's my approach to EA. Anyway, I like that pragmatic approach. We, we can talk about, um, the theoretical principles of betters. Like TOGAF AGM. They are, they are unnecessary and they certainly helped to design the target architecture. And when you study them you all think that it's all common sense. Yes, yes. I agree with all this. But it's very high level. It's a very futuristic or it's academic theory. And I prefer to, in my daily job in services, I really value the, or I believe in the power of, of some pillars of EA like simplification standardization. And, and you mentioned it, or we mentioned it communication across the enterprise. So these are very general principles pillars, but the are down to earth, very practical, and they helped you resolve problems.
Joe Gottlieb: (19:12)
I love the three pillars, but wait, I got to roll back a little bit for those that don't know what the heck it is, tow GAF ADM, can you help define that? What the heck is that?
Gwen Kerdiles: (19:24)
Well, it's, it's a method. ADM stands for architecture development method and, um, it's, it's a set of principle on how to develop and architecture and it, it follows a cycles where you study the requirements, develop the proof of concept of your target architecture and validated and so forth and so forth.
Joe Gottlieb: (19:50)
I just want to make sure no one is wondering what that is. So for those of you that know about it, you now know, how do we fit it in, but your point is is that there are, there are necessarily reasonably heavy methodologies that have been developed around enterprise architecture. But if, particularly, if you consider the power of iteration and this pragmatic approach, right, the key is to sort of break those things down and say, okay, I can understand the power of that heavy methodology and how it might be applied across the board, but now I'm going to, I'm going to apply it practically. And maybe it's a small project, or maybe it's an, you know, an iterative result where we, we, we apply some principles, we demonstrate some value and we, and then we, we continue to iterate through to get more of a return on investment with that effort.
Joe Gottlieb: (20:48)
But, you know, well, we could evolve. We could go at length at, at each of these pillars, but I, I, if I understand them correctly, uh, Gwen simplification is all about, um, a certain architectural elegance, right? Architecture done well, both in how has it buildings and in digital technologies, why, you know it, when you see it, right, there's a certain elegance to it. In fact, that the effect of good architecture is to simplify as opposed to, to make things sound and, and both, you know, more manageable, more serviceable, uh, more maintainable, uh, but also capture a certain even, even form following function, um, a certain visible, visible elegance, right. Am I getting, am I putting too much on,
Gwen Kerdiles: (21:40)
Oh, no, absolutely not. And, and w when you presented the definition of technical debt, you're talking about the price to pay, to maintain. And when you simplify, actually you make the maintenance a lot simpler. You can automate it. You can, it's, it's, it's, it's a lot clearer to those that needs to do the maintenance, uh, what job they need to do. Um, you, you also mentioned the, the theory about, um, what enterprise architecture does and there's different methods that are available. And then yes, there is, there is a lot of literature and, uh, and, and some very good principles there, but again, we are talking to organizations and not, not, you mentioned, uh, I shouldn't have mentioned an acronym, but there will be interlocutors that won't know what EA is or what it's supposed to do. So you, you, as an EA, you need to talk in simple terms as well, and explain in common words what you expect from that conversation and what you expect from that Intel relation between the different components of the university.
Joe Gottlieb: (22:53)
Absolutely. So then if we move to standardization, to me, this becomes the, this is the teeth, right? This is where the rules show up. And if I may, I'd like to lump it with the third, the communication across the enterprise, because those two taken together, particularly if you can simplify in, particularly if you can use good language to help people understand what it is and what the benefits are, and also the house of, of how you will apply it, the rules become easier to digest, right? Like we, we know we need rules at some level to operate in a, in a sustainable way. And in harmony with, with, uh, with, with contemporaries, with people who, with which we share a common mission, let's say, across an institution. And so this is really about harnessing the motivation to accomplish something as a whole, and therefore considering all the synergies and valuing that over the synergy, the, the, the, the benefits that might be experienced individually and in smaller forms, right?
Joe Gottlieb: (23:55)
Like it, by the way, it standards, any standards is all about the holistic benefits of the shared use. Right? Think of it, think of it when we, the fact that we have, uh, I know we have the metric system and the English system for tools, but the fact that we have standard tools, you know, standard fasteners, uh, with sizes that, that match, right, these are, this unlocks so much more productivity for those that use tools and use fasteners, that those tools are able to, um, you know, uh, manipulate, um, as a simple example, same thing is true in technology, right? So now if we take these rules and we're communicate them clearly in the context of the shared benefits and with simplified language, then now your three pillars right. Are really working together.
Gwen Kerdiles: (24:45)
Yeah. And standardization is also needed in order to, you mentioned, delegate the work. So, so share the work, the workload, uh, if, if we don't agree on standards, we, we don't, uh, we, we will all go in our own direction and we doing there, how to build a good picture all together.
Joe Gottlieb: (25:05)
So true
Gwen Kerdiles: (25:07)
Standardization is as well, um, often a way to adopt something that has been proven by the industry or by your peers. Um, so, uh, a few times you, you mentioned prototyping of proof of concepts. Um, the, this is another way to, um, once you, one of once the proof of concept as become successful as an organization, you can decide that it becomes your standard, and then you, you adopt it as your rule that you propagate
Joe Gottlieb: (25:43)
So true. Okay. So now, if we want to take our enterprise architect and really put that enterprise architect up to the test of being the tech debt Slayer, uh, let's talk about how the EA might slay each of those six sources we mentioned earlier. So take us through these Gwen, starting with customizing purchase software.
Gwen Kerdiles: (26:11)
That's probably one that is very close to, to my heart. Uh, I I'd been in the education world for 30 years now. Uh, and I started working with software in the IO heads, uh, 20 years ago. Um, oh, I, I mean software like student systems, uh, helping the, uh, education. Um, and at that time it was probably the, the, the, of the software vendors that, uh, you could do everything with the code that they were releasing to you. I actually was even a selling point that the more you could do, the more you could customize the better the software was. And what I've seen in, in the last few years is that back to baseline back to what the vendor release out of the box is one of the most salient trends in irons, in all types of institutions, from the small one to the very large one and, and worldwide actually, uh, I, I work in Europe and I see a lot of institutions in the UK that have been implementing software for 20 years, the same student system for 20 years.
Gwen Kerdiles: (27:31)
And they started 20 years ago by customizing so much that they are facing a critical decision at this point in time. Uh, can we still modernize that can or do we need to completely reimplement? So th the enterprise architect role is to help that organization, uh, define the boundaries of what is acceptable in terms of customization versus configuration versus, um, using meta data specs programming, or something that lives at the boundary of your system that respects your system, that doesn't invade it, but use the API APIs to talk to it, but still help you realize your business process without having you to change too much your business process. Um, and, uh, it it's really that that balance between, um, how much of that configuration can we do, or do we want to do, or should we rather try to convince the business that actually a simplified business process might help everybody?
Gwen Kerdiles: (28:48)
And, um, I've, I've also seen, um, in the same topic, uh, the, some universities or some vendors proposing solutions, but some universities, I don't think a shift of their technical depth. So in principle, um, uh, uh, a good solution instead of modifying, uh, the code and taking the risk of adopting, um, language and a platform to do the modification, then use, um, the software development kit and meta data driven development and delegate that technical debt to the vendor. Um, so this, this can be a good strategy. So there is still technical debt somebody has to pay, but you delegate it to somebody else to the vendor. Um, and, and, uh, yeah, the, the, the, this type of activity around customizing software, um, needs the support of, uh, of some critical roles within the institutions like, um, those that the facilitators between the, the, for the change of business processes and the leadership needs to be behind that, uh, that supports,
Joe Gottlieb: (30:13)
Yeah, I think that's a critical area because that's the part that's hard, particularly if you don't, um, have a good mechanism in your, in your organization to engage it. And so this is, this is often not a well-developed muscle, uh, I E the strategic change management muscle in organizations, but that muscle is going to become so important in the increasingly digital world, such that leadership can drive and be proactive about executing its mission and implementing its strategy and, and accomplishing its objectives with technology, doing its bidding, versus the other way around technology is showing up and being this thing that has to be managed, like other things have to be managed, right? This technology gets tucked underneath the trajectory of the organization under these better conditions. And so what it, what it calls for though, is someone to compliment the EA who can handle all the technical sides of this equation on and help the business recognize, well, you know, what we could take advantage of what this vendor is offering us and able to automate well for us and maintain for us.
Joe Gottlieb: (31:27)
If we think about this other way of doing the process, and actually it's not too far from what we were doing. And in fact, that might unlock other patterns that we might yet do in our innovative changes to our process, that maybe others are already ahead of us on, and they've given the vendor ideas about how the software should support that. So when you really get down to this, right, staying on pace with the advancing platforms for automation coming from the technology vendors, their whole goal in life is to maximize the value for the market. And so if they can't help those customers innovate, then there themselves going to become backwaters and they're going to become less successful. So it's a bet that you've chosen vendors well that are going to pay swell at the market. And then you keep pushing your innovations on top of that, which can be automated as opposed to forcing the vendor to implement what you do today as your process. And thinking that you've, you have a win there, which from a technical debt standpoint, you'll have a loss.
Gwen Kerdiles: (32:27)
I agree with you. Um, and not. And other points that we mentioned was the oldest shortcuts that can be done in system integrations. And that's so true of any adoption of a new service within a university. Usually usually a new services adopted because there is an urgent need and urgent means that everything is urgent, not only the choice of the software or the solution, uh, the deployment of decision, but also the integration. And we too often, we see poor integrations or poor integration patterns that are adopted because of that imminent need. Um, we saw it last year. Uh, we've uh, we've, we've covered and having to do introduce new business processes within the university of, uh, or even this culture, uh, having to test the students when they come back on campus, these are new business processes for the university. So a new systems had to be, um, introduced and integrated and integrated to what, to things like, uh, your HR system with problems in privacy, with your students system, with prob probably opening some doors to some dangerous activities.
Gwen Kerdiles: (33:50)
So all these needs to be managed. There needs to be controlled, and that's where the EA comes as, um, as a guide, but also as a referee at the same time, you need to lead, but also say these are the boundaries. We should not, we should not go outside the standard, or we do it in a control way. And we, we have, um, a proof of concept and, uh, all together, we decided that's the new acceptable way. And, uh, so the, the goal in that of that EA is, is to help define those standards. What is, what is acceptable by the organization, and when more importantly, what can be managed by the organization on the longer term, and, um, the, the, um, in terms of, of, of principle, you mentioned adopting the software or, or services as they come, and that triggering the discovery of new functionality of new possibilities.
Gwen Kerdiles: (35:00)
And, and it's true for integration as well, that that can trigger the discovery of new flows, new patterns for integration. One of the one simple example is universities, or a lot of organizations, not even universities, a lot of organizations tend to have point to point integration, very dedicated, and these can be perfectly acceptable for some dedicated type of, um, of very secure connection between two services. Um, there they are type of integration that you don't need to have, um, using your herb or using a sharing mechanism that the, the president of the U S and the president of Russia have a red line. That's not red, but they have a direct point to point telephone to talk to each other, simply because it needs to be secure and no other participants is welcome on that line. Um, on, on the other hand, uh, we, we see on the ecosystem of the university that most of the data that you exchange between the different components, actually, they are relevant for plenty of other components.
Gwen Kerdiles: (36:25)
And when you start having point to point integration, then you, you reach a possible exponential explosions of those connections. And you, you, you mentioned the triggering, the discovery of new patterns, um, instead of having those point to point integration, if you start having a mechanism of pushing change notifications, then you kind of offloads that network of spaghetti, uh, between the, the, the different components by just letting each of the participants of the communication, just push any new information to the outside world at the moment at the pace they want at the moment, they are ready to do that. And all the consumers can consume the change at the pace they are able to consume to change. So these are different, uh, type of integration patterns that you will discover if you adopt out of the box, uh, platforms that your vendors, uh, might offer to you.
Gwen Kerdiles: (37:34)
Um, we mentioned, uh, the specializing in new system purchase and, uh, and the, and the fact that too often groups or functions within the university, or not only business groups, it can be it groups. It can be any group in the university will identify in each, and we'll tend to have self power to choose the tool that, um, that, that can help resolve that need or, or respond to that need. And, uh, and the, the role of the enterprise architect here is really to, to help in that communication between all those components of the organization, so that, um, you, you, you don't make an, a selfish choice in one very simple one, one corner of the university that you make the best choice for the whole organization. So the, for the whole ecosystem, um, and by doing that, you introduce concepts like we use ability, uh, we know it from programming, uh, visit where usability is a concept it's closest simplification and standardization in a way you, you want to be able to do one type of job once, and then we use it, not have to read you all the time.
Gwen Kerdiles: (39:11)
You want to simplify your life in the future. Um, and you want to fight that fragmented system where too often we see the same function or the same system, um, that, that fulfill a capability that is available, or that is multiplied in, in different, uh, part of the, of the ecosystem of the university EA, um, enterprise architecture to, to, to achieve that has techniques and techniques of, for example, mappings the functions and the current assets to capability models. So at least that we have a map of what is available. So it becomes very clear if we communicate to the whole organization, it becomes very clear, um, that, that, that capability is already available somewhere else. And that we should talk to that other group and we use what is already in place. Um, but again, coming back to the three pillars, uh, in that communication between all those silos, the EA as a very central role in, in preventing that fragmented world, another point that we mentioned with the old hardware and I will, I was recently, um, working with a university and on some VMware infrastructure.
Gwen Kerdiles: (40:43)
And, uh, we know that it's end of life. We know that in a year that time, um, that we're going to have to change it still the EA as, as a very good role to play there. Um, there is, uh, again, standardization, the EPA can help build those blueprints of we've in the context we've been, what is acceptable in that aging hardware. We can still build things that are adapted to it and build the path to more automation. Because if we, if we talk about blueprints and standard deployments, then we open the door to automation and DevOps and cloud ops. And we also ensure that, um, they are processes to, uh, guarantee the security and the reliability of your system. So the more you standardize, the easier it is to guarantee security and reliability, and you can maximize your hardware assets while you're preparing to the next phase.
Gwen Kerdiles: (41:56)
So you get, you can still build some containers that you will be able to reuse in another world like a clouds or an EBIT world. And these things need to one point that we mentioned on the cloud or adopting adopting technologies before we are really ready to, uh, adopt those technologies. And I, and I've seen the, in the higher education world, um, that trend to, to go all cloud and sometimes wanting to fast to go to, uh, a new, a totally new platform, the cloud platform. And, um, and I've seen some cases, even in the, in the previous, um, organization where I was working, we decided because again of urgency and not looking at, uh, the maintainability, we, we built some images, technical depths by moving to a cloud, some of the, um, that were, uh, we removed them as they were in the cloud using a service from a service company, uh, and in the end, not adopting the capability of the hosting platform of that cloud platform, but really only what was constrained by that service company that was lifting the VMs.
Gwen Kerdiles: (43:35)
I I've seen too many universities, um, trying to do the same thing because of pressure and lifting. They are too complex system to a cloud. And I've, I've, I've seen in, uh, in the last few years that there is, uh, uh, different trends to take the pace and, and, and really rethink. And we architect transform the architecture of your system before you are ready to take full advantage of that cloud lift or migration to the cloud. And it means in the end that you're closer to move to any cloud service and move to a proper SAS service where you make total abstraction of what is in the black box that provides that service and a higher digital, uh, as, as helped universities on, on that transformation path to simplification of processes, processes, transformation, back to baseline, and, and certainly modernizing, uh, all the integration patterns. And, um, these, these are things that you need to do to be ready to move to the cloud. Otherwise you will just bring your old, uh, not really reliable way of doing things into a very modern, shiny, uh, platform. And it makes the platform less shiny suddenly.
Gwen Kerdiles: (45:18)
And I think I will last, uh, examples was, uh, how to help universities, uh, make the choice, the choices that are really adapted to the organization. And I'll take an example of, um, a client I'm working with at the moment. And, um, they are, uh, in, uh, in the I-PASS selection process, they have recognized that the integrations is aging point to point using a lot of, um, flat files and SFTP servers, and they are moving to a cloud. And it's, it's the perfect moment to rethink those integration patterns and, uh, the vendors that they work with have some good platforms of achy eyes. Uh, but that's not enough in this case. We want the flexibility to be able to, uh, integrate with that platform of ache. And so an ESP or an I-PASS, um, is the type of tool that, that would resolve that requirement.
Gwen Kerdiles: (46:33)
And, um, it could have, it could have been a very, uh, dedicated to a very small it group project. And the university decided to do something great is to open it to the whole organization as one of the pillar of their transformation. They opened it to the organization. And one thing that I've seen that that really struck me is, uh, there was a lady with the compliance officer. He needed really saw the power of what an I-PASS could mean for her job for, for what she has to do. Our listeners, Glen, what an eye passes and pass is an integration platform, uh, as a, as a service. So, um, if you want, uh, a tool, a massive toolbox in the cloud to help you integrate and reuse components and simplify low code, no code platform where you drag and drop your, your connections.
Gwen Kerdiles: (47:40)
And, um, that, that, that, that lady from the, from the compliance office, uh, she saw that, um, the, the I-PASS was actually going to help her understand where the data resides in the ecosystem. So, so understand the data governance and, and protect the privacy because the I-PASS is going to be also the, that set of pipelines, where the flow of data is going to translate between the different systems. And, uh, and any of those tools that is enterprise is meant to be enterprise, uh, like, uh, the document management to a workflow system, or a CRM requires an enterprise adoption. Um, and it also requires therefore an enterprise discovery. You need to talk to all the parts of the university before you make your assessment before you define what the requirements are. And before you start talking to vendors, um, and one of the, uh, balance that you need to find is, uh, find something that is adopted to adapt it to your, um, to your capacity, uh, your skillset, to, to what you want to achieve in the end and what you can maintain. Um, uh, I've seen some tools that were very shiny, very powerful, but way too complex, or requiring new skillsets, uh, that you don't, that that would become technical depth immediately. You, you, you, you would buy a very shiny, uh, a very shiny engine without being able to burn it.
Joe Gottlieb: (49:40)
Well, it was a great tour through all the sources of technical debt, Gwen. So to really summarize then for those of our listeners, uh, whose organizations have an enterprise architect, or they have, or are considering subcontracting an enterprise architect, if they don't have one so that they can make progress, let's boil it down. What are, what are three things that our listeners can prioritize, uh, so that they can in fact, leverage this enterprise architecture function to reduce technical debt. Let's, let's end with three practical points of focus.
Gwen Kerdiles: (50:15)
Well, you, you, you can, uh, I would recommend first you have your own enterprise architects and, and have a team of enterprise architects or work with, with other architects and use the enterprise architect. You facilitates a good technology choices. So that person is the one who will be, um, will do the study for you in order to make those good choices. Think, think also as the EA as a practical tool. So you want to resolve some practical, very salient problems, and not as an academic exercise that you need to do, because you've seen it on, on the strategic plan of the neighbor. Uh, DEA is here to help you and try to use actually proof of concept, short projects, to demonstrate the value and, and get the support of the organization around that value, and then deploy it further.
Joe Gottlieb: (51:20)
That's a great point to end on Gwen. Thank you so much for joining me today and thanks to our guests for joining us as well. We hope you found this to be insightful on a very, very important topic, not only the role of enterprise architect, but the role of that enterprise architect as the tech debt Slayer, we hope you have a great day and we'll look forward to hosting you again on the next episode of transform.
