 Welcome back everyone. I hope you're, if you're not quite back from the break, hope you can hear me and are on your way back from the break. I had a great, great start to the day and focused on the digital operating models and the roles involved in that and digital product management. I'm going to focus now on the digital transformation aspect. And to start off, we're going to have a case study from our first speaker, Tony Marrow, who is the vice president of consulting services at Irwin. Tony is the director and consulting, so director of consulting services and implementation enterprise modeling management and governance solutions for Irwin by quest. Enterprise architecture and system software engineering. And in this session, Tony will help enterprise architects and digital practitioners understand how not only to support but lead digital transformation efforts for their organizations, especially if you can think in terms of business impact. He'll examine a case study of a large US data services provider that lacked visibility and governance over all its business units and product lines following M and a activity. So a warm welcome from the open group for Tony Marrow. Welcome Tony. Nice to have you here. Thank you, Steve. Let me try to get my slide to presents. Make sure it's set up properly. How does that look, Steve? Looks great Tony. Yeah, we can see you and the and the slide in presentation mode. So it's good. Well, welcome everybody. I'm really excited to take you through one of Irwin's premier use cases with one of our. Quite honestly, one of our biggest and long standing clients. It's, it's both a unique use case and it provides kind of a unique approach to kind of achieving digital transformation. So just real quick at a top level for a lot of you that don't know who Irwin is. So Irwin is a premier software and services provider in the enterprise modeling and governance space. We were founded back in 2016. Although that's relatively new, our product lines are actually roughly about 30 plus years in the actual market space itself in this in this field. The products we really provide and services we provide are all around enterprise architecture, business process management, data management and governance and automation and integration for kind of it and business operations excellence. And really today I'm here to kind of focus in on enterprise architecture as a whole for this particular use case. And really focusing on, you know, a use case that all of our clients come to us for and that is digital transformation. And typically our clients that are approaching us for digital transformation. These are long standing, you know, industry, you know, businesses that are fortune 500 1000 type companies that have lots of technical that monolithic applications. And they want to be able to maintain relevance in the market space, implement agile operations and really transform how their legacy company is operating to date. And, you know, this is always a continuous thing with digital transformation. We're always evolving always trying to make the company better more kind of efficient at the end of the day. But it really comes down to where do you start with transformation and what's your end goals with it. So a lot of our customers come to us as a starting point to start looking at how do I actually plan for a transformation. What are the impacts going to be and how am I going to accomplish this without, you know, hitting any road bumps along the way. And then really important is, is how are they going to fund it. They have current operations already in place. They already have current it budgets that are holding up the business to date. But they need to figure out a way to actually fund transformation and really make the companies work around that new funding operating model. And then lastly, how do you mitigate risk along this transformation kind of road map, if you will. And these 3 items are really where enterprise architecture comes into play. Because as enterprise architects, we go through strategic planning initiatives. We go through kind of dependencies of our application landscape. And we really look for ways to reduce redundancies and actually kind of transform that organization without having too much impacts to the current operating model. And so, like Steve said, that brings me to my use case that I wanted to present everybody today. And it really is around a large scale enterprise data service provider that focuses in the real estate space. So primarily real estate mortgages, insurance, the financial backings that go alongside of that. So providing data assets and analytics to lots of various types of customers. Either from somebody buying a home or banks looking to actually qualify somebody to actually get a mortgage itself. This particular company, like many companies these days grew through massive acquisitions. So they, they went through a growth strategy that went over about a decade and they actually acquired 50 plus companies along the way. What this ended up causing is obviously massive redundancies in the landscape from applications to technologies. But then also from an operational perspective, when you start looking at resources, processes, value chains. So there were lots of overlaps in these for all intents of purposes, kind of independent companies operating underneath one umbrella. To make kind of matters worse is a lot of these applications and product lines that they actually had. We're all undocumented. So lots of tribal knowledge that was built up over the years around these product lines that were very deep into the individual business units. And what ended up resulting from this was a very high cost year over year. And also, you know, obviously, as we dealt with through COVID, they identified a lot of disaster recovery risks with these types of operating models. And with growing legislation, you know, lots of kind of fines and compliance items that they were going to have to start tracking with going across the organization itself. So just to kind of give a quick landscape of what they were working with in their IT departments. So they had roughly over 330 applications that equated to about 4000 actual functional components, and then over 1000 data sources. Each one of these applications, components, data stores were all developed using underlying infrastructure and different technologies. There was no real standards that were actually taking place going across the various acquisitions that they actually went through. And, you know, obviously to make matters worse, about 80% of that portfolio were actual mission critical systems that were either delivering, you know, client facing, you know, value and deriving the actual revenue to the organization. Or it was providing that back end infrastructure support that kept all of those things up and running at any given point in time. So right out of the gates, this client identified, you know, a real need to take a step back, rationalize the architecture landscape, and actually start to drive towards, you know. This digital transformation journey where they were going to start defining standards and defining new practices and making their organization a more agile approach to client engagement. So the whole concept to their journey was is that they had their current state architecture and they needed to produce the funds in order to drive innovation, drive common standards, drive new product lines within the organization based upon customer demands. So there was two ways that they were going to drive the funding that was going to ultimately provide that innovation concept. One was they needed to start moving all of their infrastructure off of on-prem solutions, either to one, a data center or to a cloud hosted environment. So from that, that was going to provide them initial infrastructure and operation savings that they could drive into innovating next generation platforms. The other aspect of this was to be able to actually do a massive scale application rationalization initiative going across all of the 50 business units. Now, obviously this is a big task filled with lots of risk, especially when you start to look at it from the perspective that there was no architecture. There was no understanding of the interdependencies going across the organization or the actual application portfolio itself. So the overarching concept was is to start off on this journey. We needed to first invest in enterprise architecture and not just enterprise architecture from the standpoint of defining best of breed kind of governance practices around your processes. But more of it is about just in time architecture for this particular effort because there was real tangible data sets that were actually missing for us to start this overall funding journey that we needed to document. So our tactical objectives was to be able to quickly and effectively document the as is architecture going across the 50 different business units and structure in a way that would end up one de-risking this data center migration and cloud migration activity and to allow us to assess the application landscape and identify the areas of opportunities to start to standardize on technologies and just to purely get rid of application and technology cost to where we could move that funding into innovation activities going forward. And that's just what I said there right so being able to rationalize the actual application portfolio and shift that funding into the new cloud hosted environment and then also to start to define innovation and next generation platforms. So at the end of the day, the tactical objectives were to document the as is architecture for the purposes of de-risking the data center migration, but then also to actually get an ROI on application rationalization going across the entire company. The commercial objectives like many other companies, you know it's essentially we need to be able to do more with less so drive down IT costs while we drive up product revenue. Now as much as I would like to say a single tool can do this all for you it just purely can't right so an enterprise architecture tool is just the pure repository to store this information and to give us consistency. So the real interesting thing about this project or program was kind of the framework we put in place on how we were going to accomplish our objectives as a project. First and foremost, we had to have a tool to store this information which obviously was Irwin's product line. And then we needed to define a flexible metamodel that actually allowed us to capture just the pieces of information that we're going to be valuable to us on the actual project itself. And more importantly, a way that we could communicate that to actual clients. So we defined, you know, a top level kind of metamodel and framework that we were going to use for the project. And then we started to populate terms and definitions that we could communicate to the actual broader audience within the company. That would allow us to set up a taxonomy for doing application rationalization going across the entire organization that everybody would understand. We also deployed a methodology to start populating the actual repository with relevant information so that we could have consistency going across every single business unit. So that we could properly do the analysis that we were going to need to do and make the recommendations that we were going to need to make in order for people to start putting rationalization projects in place. And then ultimately, you know, a big aspect of this is the team itself. So the EA team was stood up, but it was also more of partnering with the business units that we really needed to accomplish to make them feel a part of this activity at the end of the day. And then we always continuously monitored the quality of the information. So, you know, going through different efforts to get information into a modeling repository tool or an EA practice is only as good as the quality of that information. So we did define clear standards and definitions of what we're going to be tracking for so that we could always have trusted information in that repository. And then ultimately a long standing governance model. So although this was a, you know, a clear program or project, one of the objectives was is that once we get through this initiative and actually move the funding over is that this would be the current operating model for the IT department and the business units going forward to continuously have this information up to date so that they can control and not get back to the same state that they were at before. So, you know, like, like I said, a big part of this was around application rationalization. This was the driver to fund their transformation activities. And it really was the starting point that they had to get through before they could make that transformation into next generation plan platforms and product lines. So we took a very simplified and quite honestly, well known approach to rationalizing an actual application landscape where we go through cycles of inventory and identifying and assessing the portfolios. And then coming up with a plan and funding actual initiatives to achieve that that cost savings. Like I said before, this is a classic case of doing less with more. So we went across their entire kind of 50 business unit product lines looking for opportunities to rationalize products, services, business capabilities, functions, and then obviously applications and technology stacks itself. So, in all transparency when we first started up this project, we had a pilot phase and in that pilot phase, we tested an approach of doing a traditional kind of enterprise architecture data collection, you know, concept of doing data calls. Right. So doing data calls across the country going across the different business units. And quite honestly, it failed miserably. So doing data calls to get the level of information that we need to document the architecture to understand the processes to understand the dependencies. It just, it didn't work. We had to build a trusted relationship with the business units and that just does not take place going across emails and spreadsheets. The data quality was just all over the place. So we actually landed on a work based a workshop based approach to where we did pair wise teams between a business analyst and an enterprise architect that would actually travel to all of these different business units. And work with the product lines for a week at a time and take them through a well facilitated workshop to specifically document what we needed in order to meet our objectives of de-risking the data center migration and cloud migration and application rationalization efforts at scale. So this was a very tailored approach with this client and it is something that is quite reusable on many types of efforts. But it was at large scale. So this did become a heavily involved kind of effort in coordination and teaming and, you know, really executing to a properly planned project. So obviously this took a lot of buying from senior leadership within the company and then also clear direction going across the organization that this effort is a priority. And that the time is mandatory that each one of the business units had to participate in this documentation because it is well rooted in strategic objectives and the strategic direction for this particular client itself. So we had multiple teams of business analysts and enterprise architects go across the country and execute multiple workshops until our repository was full enough with valuable information that we could actually, you know, make value added recommendations and de-risking activities itself. So just to give you kind of a little bit of a top level of what our workshops look like going across this particular client. So like I said, there was lots of different types of undocumented product lines that we had to work with. So in order to fully flush out what the value added architecture was for a particular product line that would need to be either migrated to a data center or a cloud implementation. And then at the same time documenting what technologies and applications they used, we actually started off at high level business process modeling because we had so many different stakeholders that were involved with each one of these kind of product lines. The best way to facilitate this was to talk about what products are you delivering to your clients and really define what kind of the value stream was. And by gathering in different types of subject matter experts in a room and talking more about, you know, the value stream or the business process for this particular product line, we were actually able to discover the architecture as we went through this facilitation process. So we actually stepped through each one of the business processes, the tasks that the software was doing throughout the value chain itself, and then we would map the applications components and data stores at a very logical level as a way to flush out that information. From there we would say, okay, now that we have an inventory of all of the applications, the components, maybe third party tools or data sets that you're actually accessing from an architecture perspective, how are those things integrated together. So it was a very seamless process of understanding what the product's trying to do, what is the inventory of things that are actually involved in it, and then what's the actual architecture that makes that up. Another big area for this workshop was reference model mapping, and this was a key element for application rationalization. So before the project even started and kicked off, we sat down with our client and tried to understand what they did from a capability perspective. And then we drilled down even further from a capability perspective, what do you do from a functional perspective. And that really gave us a framework to understand what the company's core competencies were and how they are achieving things, but then more importantly, how do those things map to the actual architecture elements that they're supporting. So as we did these workshops over X amount of time, we were slowly building up the architecture, the dependencies, but then also the business context that comes around all of those details. And that's really what allowed us to start to identify opportunities for rationalization at the end of the day. So once again, another big aspect of this effort was to support the actual cloud and data center migration. So we actually went through this effort alongside of some other consulting firms that were doing detailed infrastructure analysis. And they were using things like automatic scanners to do server discovery and to identify connections. But one thing that started to become apparent during, you know, our efforts with with the client itself was the fact that the automatic scanning really did not provide the context needed to create. These move packages that you would either be moving to a data center or to an actual cloud environment. So as they were actually starting to move stuff dependencies were breaking servers were missing. There was just a lot of business context that was not picked up by those automated scanners. So one thing we put into our workshop approach was the fact that as we went through that architecture efforts. We would actually start to map those components map those applications map those databases to the servers that they actually resided on. Which is obviously another level of, you know, tribal knowledge that these guys had that the automatic scanners were not picking up. So once we had both sides of the story one from an automatic scanning standpoint and two from a knowledge standpoint. We were able to marry those two data sets together and actually reconcile the differences, which ended up de risking each one of the move packages because we had both a top down and a bottom up approach to the architecture documentation. And it really gave everybody kind of a good feeling as we started to migrate these applications and systems to a new environment that we had all of our bases come. And ultimately, you know, I took you through kind of the logical PowerPoint approach to kind of, you know, each one of the high level steps that we went through. And, you know, these were really long, you know, one week, two week series of workshops and it led to highly detailed end to end architecture artifacts going across the entire organization. So at the end of this effort, we were one able to provide a clear as is architecture picture that was going to fall under governance going forward. Two, we were able to define migration packages and prioritize those for the client so that cloud migration and data center migration teams had all the visibility that they needed in order to actually successfully move those systems. And then we were also able to provide redundancy identification. So we were able to go through their complete portfolio, identify the overlaps going across the 50 companies, what, what functionalities were the most ripe to kind of standardized on and then define, you know, which solution would be best for that particular one so that they could reuse it going across all of the different organizations and product lines itself. And then obviously, you know, provide lots of lots of analysis to support that information within the database itself. Ultimately, the business outcomes for this project, one, they ended up with, you know, a repository with their full architecture documented. They were able to do strategic planning off of it going forward. They're able to govern it going forward and they are able to provide kind of real time on demand kind of analysis to see, you know, if they change something, what are the downstream impacts going to be. They also have pure insight into where all of their IT costs are coming from. Ultimately, this customer also moved into a very mature state on how they integrated enterprise architecture into their actual ecosystem. They moved it within their SDLC process and they actually integrated it into all of their operational systems. So everything from finance to HR to their incident management system so that they actually have the enterprise architecture as an integrating factor for all of these business functions and data points. That provides them even more robustness going forward as they continue on throughout their digital transformation journey. Now, some real interesting kind of stats, you know, within the 1st year, they actually saw a $42 million savings from their rationalization activity and migration activities. And then after a 3 year period, they actually saved over $250 million in which all of this savings ended up driving the way that they develop products in a new agile manner and continuously creating next generation applications. And I think with that, that is my last slide. So, Steve, I can hand it back to you. And if there's any questions, I can answer them during the panel. That's great Tony. Thank you very much. Yeah, we'll hold the questions for the panel, but what a transformation from where they were to where they are now so congratulations to all involved in that. Well, we have to move on, but in the meantime, warm, warm round of applause Tony for you and for sharing that great case study with us. Thank you very much. Yep, my pleasure. See you on the panel.