 Hello, I'm Steve Nunn, President and CEO of the Open Group. Welcome to Toolkit Tuesday, where we highlight the various components and leading experts of the Architects Toolkit, a collated portfolio of the most pertinent technology standards for enterprise architects. During the series, I'll be calling on a number of recognised experts who will bring their particular insights on how to most effectively use the various tools in the Architects Toolkit. We'll have a mix of interviews, panel sessions and pre-recorded presentations along the way. While all standards of the Open Group are designed so they can be adopted independently of one another, the greatest value for an organisation can be derived when they're used in unison, for some of the parts should be greater than the whole. In the Architects Toolkit, we have collated a portfolio of the most pertinent ones for architects, together, all in one place. For most of these tools, certification from the Open Group is also available, so practitioners can demonstrate that they have the skills required and recruiters can take the guesswork out of the recruitment process, all backed up by our Open Badges programme. Hello everyone, welcome to Toolkit Tuesday. Thank you for joining us today. We have a lot of people registered for this event, from all around the world, so do take a moment to let us know where you are if you can in the chat channel. We'd love to get that going and share the different locations of our attendees today. But delighted to have you with us today. Can you believe this is our 10th Toolkit Tuesday? Over the last 20 weeks, we've brought a lot of information and knowledge that's available on our website, so you can go back and see these if you missed any, or if there were any you particularly found useful, you can go and see them again. Today we have one that really sums up what Toolkit Tuesday is all about, using the availability of open standards and using standards together, and I think it's going to be a great session, and there's some homework afterwards, which is to read a book which you will find very easy and approachable to read. I strongly encourage you to do that. Today we are talking about how to leverage open standards to accelerate digital transformation, and to take us through that today, and in fact, before I go there, sorry, just one thing, if you want to ask a question today, I should have done this at the beginning, if you want to ask a question today, please do so in the Q&A channel, rather than the chat channel. Let us know where you are in the chat channel, but use the Q&A channel to ask questions if you would please, and if you can't see that, if you go to the bottom right-hand corner of your screen, you'll see three dots to the right of the chat bubble, three dots, and if you click on those and then click on Q&A, that will open up the Q&A channel for you, and that's how we'd like to ask questions. We won't have time for lots of questions, but if you have one, please put it in there, and also our speakers today will do their best to answer questions in the channel if you ask. So as I was saying, to take us through our talk today, we have a threesome, a triple act, and I'll introduce them all now and then hand over to them. So the first is Stephanie Ramsey, who is Senior Principal IT Architect Manager at Raytheon Technologies. Stephanie's worked for more than 30 years in the information and digital technology world, with extensive experience in service delivery, applications and infrastructure in three industries, defence, healthcare, and retail. Stephanie is a leading authority in business architecture and product service integration with strong competencies in enterprise architecture, portfolio management, business relationship management, service management, sourcing and supplier management, and program management. Stephanie is also an active member of the Open Group IT for IT and architecture forums and is currently serving as a customer representative on our governing board. So welcome, Stephanie, thank you for joining us. Next up, you'll hear from Case van de Brink, who is Senior Manager of Platform Architects Service Now. After being an officer in the Merchant Marines, Case started his career in IT as a developer working in a team to maintain a network administration system. Over time, Case has been a sales engineer, a solution architect, a platform architect, an architect to practice lead, and an engagement lead. Currently, Case works for Service Now, managing a team of platform architects for the northern part of Europe. He's a strong believer in initiatives that help to bring standardization to life, like the IT for IT standard, which he helped to establish and maintain. And third, you will hear from Sylvan Marie, who is a consultant on IT and service delivery at Accenture. Sylvan has worked in information technology and service delivery for more than 30 years as a consultant. 15 years ago, he extended his experience into the field of enterprise architecture, and he's now a leading architect in IT for IT. He's certified in Togaf IT for IT business architecture and is an ITIL expert. He's been involved in ITSM and IT for IT consulting projects in major European companies. He also likes to share his experience in using Togaf IT for IT and ITIL as a trainer, and is an active member in the open group. So a warm welcome from the open group to our three presenters today. And a short version of what they'll be talking about is they'll be talking about how open standards helped resolve three real world scenarios faced when deploying digital technologies in an enterprise. The scenarios are based on the presenter's recently released novel, The Turning Point, Agile Architects Building a Digital Foundation. So first up today, you will hear from Stephanie Ramsey, a warm welcome from the open group for Stephanie Ramsey. Over to you. Welcome. Great. Thank you, Steve. That was a very nice intro. Just to give you a bit of a context on The Turning Point, it's a book about a fictional company called ArchEssurance on a digital transformation journey. The story describes the foundational work that's necessary for companies that would like to deploy digital technology at a faster pace. Many of the open group standards are used throughout the story to solve problems that arise during the ArchEssurance digital transformation. Myself and two co-authors, Case and Sylvan, will each take you through a scenario out of the book. I chose a scenario on application rationalization to talk about. The main character in the story, Dr. Kathleen Stone, Chief Architect, is a strong proponent of working across value streams and cross-functional teams versus the way many organizations have tended to work in functional silos. In the silos, groups have focused primarily on their individual goals rather than common goals and outcomes for a value stream. The result of working in functional silos is often duplication of effort and the creation of redundant and disparate roles, processes, information and tools in many organizations. In the novel, the fictional company called ArchEssurance had also gone through a merger, and there was a lot of redundant applications in the ecosystem. This is also a common problem in organizations. This picture here is from the book called Design for Digital, and we reference it several times in our book. It depicts the silos that have been built in a lot of companies over the course of many years where there are lots of disparate processes, data, applications and technology that have been created over time. As companies begin building their digital foundation, we highly recommended that the core systems of record are identified and integrated, and that the duplicate tools are removed from the ecosystem to reduce complexity. Application rationalization is a method for identifying and removing redundant and non-value-added applications to free up budget for the business critical work that needs to be done and to simplify environments. The technical viability, risk, and how well applications meet business needs are assessed. Based on the findings, applications are designated for retirement, consolidation, or modernization. Application rationalization is an imperative for building a strong digital foundation because it reduces complexity in the environment and it renovates digital ecosystems. This is groundwork that can make an organization agile and adaptable to handle incoming digital demand for things like big data, cloud and mobile. The IT for IT standard can be used to help guide the flow of data for digital products and service. There's also a guidance paper available in the open group library called Tool Rationalization using the IT for IT reference architecture standard that gives the steps for an application rationalization effort. This picture is from our book. Kathleen and her team are able to determine the core systems of record for their digital products and services by mapping the tools in their existing environment to the IT for IT digital product lifecycle. They were able to identify and eliminate all the tools that had redundant capabilities narrowing it down to four core systems of record. Core systems of record were integrated so product information could flow digitally in an automated fashion versus all the previous manual intervention that had been necessary to keep information moving from one silo group to the next. So in summary, build a strong digital foundation by identifying your core systems of record. Eliminate duplication and redundancy in your ecosystem, and build an integrated information thread through your core systems of record. And organize teams around value streams to eliminate silos and stop the progression of disparate processes, technology, application, and data. Application rationalization is referred to several times in the book, but chapter eight is where you can find the product lifecycle automation part of the story. Now I will turn this over to Kase, and he will tell you about his scenario that includes the villain of our story, Vons Pickle. Thank you, Stephanie. I would like to discuss also the scenario I picked, and it's one that most of us who are working in IT run into every now and then, which is legacy systems or more importantly, the replacement of legacy systems and the difficulty of it. The same truth for the company in our book, our insurance. There's a prolongation application, which is known by the employees of the big ludicrous old system or BLOS, which is seen as large and complex and is inflexible and needs to be replaced. Over the time, a number of attempts have been made to replace the system, but until now they basically keep on failing to do this. And to then, Hans Pickle, he's actually currently tasked to replace the system, and he and his team have been working on this for a long time and taken a Big Bang approach, something that most companies are trying to do with legacy systems. And unfortunately, because of the focus of Hans's on replacement, he kind of doesn't have any room to do anything else, so which in itself is killing the new demand and therefore killing innovation and the progress of the business. In fact, Hans is actively stopping anything which will change the publication system. The strange thing is that Hans in himself considers himself and his team to be the most mature in working agile in the company, given they're running scrum and doing stand-ups for the last two years. But he fails to see that his own attitude towards change is more and more specifically the blocking of change is actually not agile. It actually can be seen as an anti-pattern. So one can see that considered this has to be the anterior of the book. In one of the scenes that we described, Kathleen and Amy Lee, Amy Lee is an agile coach that is helping the transformation of the organization. They're witnessing a heated argument between Hans and Ben Cohen, and Ben is a business analyst who's newly joined the company and he's trying to convince Hans to really make a small change in this propagation application because he needs to produce meaningful reports. Hans flat out refuses to do so and has no intent to help Ben in any way shape or form. So he has no other option to let go of his demand. Luckily for Ben, Amy makes sure that Ben and Kathleen meet each other and during the conversation, Amy gently coaches Kathleen into helping Ben with the solution and then define there's a way to go around the propagation system, implementing something that doesn't impact the replacement. Once the solution is, Kathleen helps Ben to implement it over the course of the book and once solution is implemented and the word is out, all the parts of the organization start to engage with Kathleen and her team with request of their own to help find solutions to solve problems around this propagation application. This is for me what is most important of being an architect. It's not about building diagrams or models, it's really about helping the business and helping finding directions and solving issues and reducing the impact of those. And afterwards, Kathleen actually learns that the process she has taken is well described. And in this way, it's described as the Strangervlick application by Martin Fauner, which we reference in the book, something that is assuring her in her approach to be correct. And that takes me to the summary of what I just described. And it is that be careful when you talk about Agile and don't become Agile in name only or as I call it, ANO, because Agile is not just doing stand-ups and scrumming. It really requires attention and it's not just done by developers. Also, architects in their role need to help the organization to be Agile, serving the business to become this flexible that they need. And the second thing is that and we call this creating room to breathe by strangling the Strangervlick application is not as an architect, it's not just about creating diagrams and models. And doing the architecture for architecture sake doesn't make sense. It's more about finding solutions and as with the Strangervlick pattern, it's basically finding ways around finding solutions in this case, finding ways around the legacy system. And this leads me to the third item in the summary and the learning and that is that stand-ups and frameworks are not just about being a reference architecture or providing a set of rules or something like that. Stand-ups typically have much more value in them. Embedded in stand-ups like the Open Agile architecture or the Digital Protection Book of Knowledge, you find a lot of pointers to knowledge that can help find solve issues. Often they're used to explain the standards and the way they work, but in itself they are valuable as well for architects. With that, I would like to hand over to Sylvain to take us to the third scenario. Yes, in this last scenario the lead architect, Kathleen Stone, she gets a call during her vacation from one of her colleagues. And what her colleague says is that they are facing a major incident because customers cannot access anymore the digital platform. And more than that, all the monitoring systems are down, which prevents the support team to correctly diagnose the cause of the problem. So they try to investigate all the changes that have been approved during the last three weeks and none of them relates to the actual problem. So finally, Kathleen Stone says that maybe the best way to diagnose this problem was to look at all the investments that has been approved recently and that maybe with that they could find what is the cause, the root cause of the problem. So after that, Kathleen goes through the security at the airport and suddenly she realized that the problem was probably due to the security platform, a new version of the security platform that has been approved recently. And effectively, this was the real cause of the problem. This new version of the security platform has implemented new security policies that creates the problem on the digital platform. And also this new version of the security platform as an artificial intelligence mechanism that reapplies the policies each time the support team was trying to correct the problem. So from this incident, Kathleen looked at what's the reference, IT for IT reference architecture and mainly in the last value stream which is the operator or the auto-detect correct value stream, what would try to prevent the same type of problem to happen again. And finally, if I go to the summary, she decides to implement two solutions from the IT for IT reference architecture. The first solution was to provide a consolidated view of all the changes, both manual changes but also automatic changes. So manual changes that go through the cab, but automatic changes that were not, of course, going through a change advisory board. So one of the main aspects was to include the DevOps tool chain in the change control mechanism and to be sure to have a centralized register of all the changes that happen in the production environment. The second solution she decided to implement was to build a digital product backbone. So the digital product backbone is something that is recommended by the IT for IT reference architecture and that allows to compare what is actually implemented in the production environment, what we call the digital product instance with what is supposed to be in the production environment, which we called the desired product instance. So by comparing the desired product instance and the real actual configuration in the production environment, we are able to detect unapproved change and so that will really help to diagnose this unapproved change and that will prevent the same problem to happen again. So you can learn more and find how this has been implemented and presented in the book in the chapter 6 of the Turning Point novel. Thank you. Thank you. Thank you to Casey and Stephanie as well. That concludes the run-through today. So great job everyone and thoroughly recommend the book. As I say, it's very approachable. It's an easy read and there's a question in the Q&A as to where you can find it and Casey's answered, but you can see it on the slide that's up right now. You can find it on the open group in the library either by its document name G219 or you can purchase a book from VanHaren Publishing. So anyway, the details are there where you can find it and I thoroughly encourage you to get the book and read it. It's a great example of using standards together which I said at the beginning is what Toolkit Tuesday is all about. So let's have a few questions if we can. So Stephanie, you let us off. So I'll end this one at you because it's something you mentioned. What do you identify as core systems of records? You mentioned that in your presentation. How do you identify those? Well, as I mentioned, a lot of companies over time because of the silos that we've been in, we've tended to come up with a lot of redundancy and duplication. So it's hard when you're trying to build integrations to build a whole bunch of integrations to a whole bunch of all of these disparate systems. So what we recommend is that you take a look and see where that duplication is. Do the application rationalization and eliminate all of the things that you don't really need in your environment. Figure out what are those core systems of record that you really need to have in your environment and build your integrations throughout those core systems of records. And IT or IT really does help you a lot with the digital product lifecycle and figuring out what is the information that needs to flow all the way from your strategy into development through operations and then finally when you have to retire something. So I use it quite often to help me kind of figure out what is the core information that I really need and what systems do I have that provide that core information. Okay, great. Thank you. Thank you. Casey, if I can point one at one of these at you. You stress the importance of being agile and not just being agile in name only. But do you need to be an agile company or skilled in running agile practices inside the organization to be able to benefit from concepts like the strangle-a-fig pattern that you mentioned? Yeah, that's a great question, Steve. Actually, you don't have to be. The beauty of architecture is it helps you when you want to become agile. It helps you with the standards of what to do, especially the agile architecture as well as DP Box, which I mentioned. They're proponents of running an organization agile. But it doesn't mean that the concepts and the structures that are being provided and the solutions that you can apply that they can only be done if you're running agile. I mean, the strangle-a-fig pattern itself is something that you can do in any type of organization. And also in the book itself, arch-assurance is in a transformation itself, so they're becoming digital and they're more and more becoming known to what it is to be running an agile organization. And in that sense, when they start to apply some of those solutions, they're not even agile at that moment in time. They fail to become agile, and over time they actually learn how to apply it in more and better ways, including failures of the arch-assurance themselves. They sometimes fail in what they do and then learn from it and then improve. It takes a fail, surely not. Surely not. But it does happen. No, it's part of the digital transformation journey is learning how to do, what works, what doesn't work, and how to use that. Yeah, and learn as an organization from the mistakes. Exactly. So talking of digital and things, Silvan, you mentioned the digital product backbone. Can you say a little bit more about that? Yes, sure. The digital product backbone are a set of seven data objects that are part of the information model that is proposed by the IT for IT reference architecture. And these seven data objects are all linked together. And this allows to follow the complete life cycle of the digital product. So you are able to link the digital product in the first phase of its existence, in the strategy phase, and you are able to follow and to really record what happens during all the life cycles. So going from the strategy, going through the development of the digital product, the design and the development, and after going through the delivery of the digital product and finally to the production environment. And in the scenario we used two of the seven data objects that are the last two from the delivery phase and the production phase in order to be able to discover and improve change, as I said. Thank you. So we've probably got time for one more question, maybe two at the most, but we won. There are a number of standards that are referenced in the novel. Can you speak to what standards they are and why you felt it was important to include them? Whoever wants to take that one? We started out with we were going to write some guidance on ARCMA, TOGAP and IT for IT. So those are the primary ones that we wrote about in the book, but then as we got into it we found out about more open group standards that were relevant that we could actually use for digital transformation. So we learned a lot in the process. Yeah, that's great. And that's a great message because a lot of people know the open group for maybe when they explore a bit more, there is much more breadth there. One of the things that we will be working on increasingly is into next year and during next year is bringing these things together making them more usable in connection with each other. So that's great. Are any of the characters in the book based on anyone in real life? Apart from the fact that you very kindly created a character called Steve Nunn are any of the others based on anyone in real life? Apart from yourself Steve the other ones are all made up by ourselves as characters. I mean the experience we have is obviously used but it's not like you can recognize anybody and the real world is representing one of the characters. That's a real look from that perspective. That's great. I hope it's Kathleen actually on what I would like my career to be so cool. Well that's good, that's good. Well, Stephanie Kay, Silvan, thank you very much for leading us through today and as I say to as I've said before and I'll keep saying until somebody listens go download the book it's a great great example of how some of our standards can be used together for real business purposes and to make a real difference. So a big virtual round of applause to the three of you. Thank you very much and we'll leave that topic today. That's the end of the 10th episode of Toolkit Tuesday. Please join us again though in two weeks time, December 14th where we will be actually focusing on modelling. So one of the standards that is in the book, the Archimake Modelling Language, we're going to have a session on using the Archimake Modelling Language in real life examples led by Patrick Derde and Marianne Couvel. So join us in two weeks time meanwhile keep safe and have a good couple of weeks and go read that book. Take care of one. I'm Steve Nunn. This was Toolkit Tuesday. Thank you for joining us. Bye-bye.