 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 recognized 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 organization 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 program. Welcome to Episode 6 of Toolkit Tuesday, presented by the Open Group. Glad to have you here today, wherever you are in the world, I hope you're keeping safe and sane and I hope that there are some signs of life returning to something more normal than it's been recently, wherever you are. But the most important thing today is that you're with us and we're delighted to have you and we have a great session today, Ask the Experts. But before I get there, just one thing I want to say, something we're quite proud of at the Open Group. September 30th, so just 12 days ago, we celebrated 25 years of the Open Group and we'll be continuing to celebrate 25 years of the Open Group, particularly at our event later this month. So do look out for that, but a lot's been done over 25 years and we'll have a little retrospective look at what we're currently doing and look forward from all around the world, as this event will be. So we're very proud of our global reach. So just a few housekeeping things to make sure that you get the most out of today's session. You'll see in WebEx there's a chat function. Please use that to chat amongst other attendees. One of the fun things we like to do is just have people say where they're joining from. That's always interesting and anything else you want to share there. If you want to share a question, you can also do that in the Q&A panel. But today, I'd rather you actually went to a different way to ask questions, which is slido.com. It's not an app. It doesn't require a download. Any internet-enabled device will work. Go to slido.slido.com and enter the event name is Toolkit-Tuesday. So Toolkit-Tuesday and that will let you in. You'll be able to ask questions and polls. Obviously, we only have a limited amount of time. So I can't promise everyone's questions will get answered, but we will certainly do our best. So with that in mind, I'll move straight to introducing today. Oh, one more thing. Sorry. Just to get the biggest impact or to be able to see and hear the panelists correctly. If you look towards the top of your screen at the layout, there's an option to see or not see participants without video. If you make sure it's not checked or clicked, that way you'll be able to see just the panelists and the people who are talking today. So without further ado, I'm going to introduce our panel of experts. Those of you who've been attending the series earlier will have seen some, if not all of these. But I'll start the introductions. First up, Terry Blevins. Terry is owner and operator of EnterpriseWise LLC, where he provides strategic enterprise architecture services. He's worked in the computing industry for over 40 years now and is currently a director of the Open Group governing board and a fellow of the Open Group long time contributor. Welcome Terry. Glad to have you here. Next, Chris Frost of Fujitsu. Chris has worked for Fujitsu since 2005 in a variety of technical leadership roles. At present he's the principal enterprise architect within the global delivery unit at Fujitsu, which provides standard services, technical guidance and support for the global Fujitsu group. Inside the Open Group, Chris led the Togafajah Working Group during 2020 and is contributing to a number of current architecture forum activities. Before Fujitsu, Chris worked for EDS, which is now part of DXC, on several large contracts for the Ministry of Defence in the UK. And in earlier years, he worked for Ford Shell and a small startup software house called Shamrock Marketing. So welcome Chris. Glad to have you back. Next up, Paul Holman. Paul is an IBM distinguished engineer and chief technology officer for the industry sector clients in IBM global services. Responsible for technology, strategy and industry architecture for the automotive, aerospace and defence, oil and gas, electronics, industrial products and construction industries, wide range there. Paul also represents IBM on the Open Group governing board and is co-chair of the Open Group architecture forum. So welcome Paul. Glad to have you here. Next up, Chris Ford. Chris is CEO of the Association of Enterprise Architects since 2016. He's based in Shanghai, China, and he also holds the post of General Manager Asia Pacific for the Open Group. Chris is also responsible for enterprise architecture services in the Open Group as vice president of enterprise architecture, including our Togaf and ArchiMate standards. Chris has deep expertise in enterprise architecture as a member, representative and chair of the architecture forum in his past. He is instrumental in driving the successful development and launch of Togaf 9 between 2007 and 2009. And last but by no means least, Andrew Josie, VP of Standards and Certification of the Open Group overseeing all certification and testing programs here at the Open Group. He also manages the standards process for us. Since joining the company in 1986, Andrew has been closely involved with the standards development, certification and testing activities of the Open Group. He's led many standards development projects, including specification and certification developments for ArchiMate, Togaf, POSIX and UNIX programs. He's a member of IEEE, USENIX, Floss UK and the Association of Enterprise Architects. So we have our experts, welcome everyone, and we'll start off our reminder questions. Please go to slido.com and they should come to me and I'll see them. But let's kick one off with, oh, here we go. Okay, so here we go with the first question. So maybe I'll direct this towards, let's see, Chris maybe with your AEA hat on and perhaps your Open Group hat on. What type of skills do you want to see in successful enterprise architects? Is it familiarity with new technologies or the ability to abstract them and present them or the knowledge of frameworks like Togaf or something else? What do you like to see? I know the AEA is involved in the professional development side of architects. So what do you see there if you can kick us off, Chris? Hi, Steve. Thanks for the opportunity. We recently conducted a survey of the AEA membership in partnership with McKinsey and the Henley School of Business. And one of the interesting things that came out of that survey was, yes, all of those things are important depending on the nature of your role and the nature of your company. But one of the things that came forward in that survey was the need for flexibility in the enterprise or the architects, no matter what role or specialization they have. But also the development of soft skills, the ability to communicate, to relate to others' situations, and to synthesize problems and solutions. That's a great summary. Thank you very much. Anyone else want to add anything on that? No obligation to because we have limited time and multiple questions. But what skills do you like to see in architects? If not, then I'm going to go to the question that was bound to come in and one we've covered to some extent. Maybe Chris Frost, I can name this one at you first. How does the TOGAF standard and traditional enterprise architecture play with Agile? Yeah, thank you Steve. Questions that grapple with quite a lot. So I mean the short answer to that is very well indeed. These things play together very well indeed. I presented on the topic a number of times and the points I often sort of open with is that any sort of large project, no matter what you're doing, needs some sort of architecture, whatever that might be appropriate to that particular project. But it's having those sort of patterns agreed up front as to broadly how are you going to structure this solution? What are the major components? How are they going to interact together? And those are the sorts of things that we would define in an enterprise architecture for an IT-led solution. And whether you deliver that in an agile way or in a waterfall way or whatever form of delivery you're using, you need a certain degree of architecture up front. And it's very interesting that most of the agile at scale methods that there are around things like safe and disciplined agile sort of acknowledge that quite explicitly. So yeah, these things play together very well and architecture is just as vital and enterprise architecture and things like TOGAF are just as vital now in agile delivery as they always were. Thank you. Thank you. Anyone else on the agile topic? I'll join in if you can. Okay, I've had to switch camera again. No, you're looking at cool. Okay, great. So just sort of following up on that. I think one of the things that we've noticed a lot over the last few years has been that constant question of how do you work with agile delivery in solution development in particular? I mean, there's business agility and how do you do architecture itself in a more agile way of course as well and all those things are topics that we pick up and have some guidance around. But if I just focus in on just solution development, actually architecting and good practice in architecture is kind of a constant thread. What really changes is probably the way that you do it and the amount that you do it and when you do it and how you engage with the teams that are doing the delivery. So it's much more of a people, a behavioral change than it is a content of method change. So so there's plenty to learn from on all sides, I think. And but the actual content adapts really well. You just have to learn how to sort of make make that work in the organization that you're working with. Great. Great point. Great point. Thank you. Next question. Yeah. Okay. A slight switch from from Togeth but still still enterprise architecture related. You know, maybe it's one of you, Andrew, I think I'm learning how to use alchemy and I've heard people mention the exchange file format. What is that? And how could it help me? Okay. Well, this is a way to basically when you create a model, it's a way to be able to share your model between different tools. There was always a challenge when we set off with with the argument language and other other similar tools is how you if you actually put a lot of effort into investing in model development, how do you you preserve that investment? And this is one way that you can do because it actually frees up the that investment so you can move between different types of tools. So for example, you might start and many people do start with the the free open source argument tool that's out there called Archie and perhaps do some modeling there and then start to move the tools to move the models say sorry to commercial tools. It's basically to preserve the investments. If you are modeling in the argument language, you know that you're not going to have to re invest each time I always used to think of it as before we had the exchange file format. It was like cave painting. We could basically do our models and it was but it was like painting on the walls of a cave. We had to sort of hack the cave down or something. He was the rocks out before we could move them but now we can actually take models from tool to tool and you can share models. That's the great thing you can now share models. We're starting to see models shared in repository. There's the argument community that's formed out there now so people can go and exchange literally as it's called the exchange file format. It really is about exchanging models, exchanging ideas. There are also other things that we've seen other other applications using the file format to analyze models in different ways as well as actually sharing them between tools. It's a great enabler really everybody's starting to share tools you'll start to see from the open group as well you start to see example models that come out so there are no longer just paper standards. We've got a model that you can download what we call an executable standard now that you can actually say for example with the aviation, the commercial aviation reference model we've got. Not only is that a paper standard but you can actually download the corresponding argument model same with several cases that is we've got banking, arch-assurance, argumental, we've got several industry sort of models that you can download and I know that we've got more in development all the time. So it's about basically making standards work as we say in the open group is actually getting more out of our standards. Yes we do. It's been our tagline for a while hasn't it. Great summary thank you Andrew. So next question I'm going to go to you on this one Terry if I may. I see the benefits of enterprise architecture. My manager has pointed me at the Togaf standard. Where do I start? Okay so number one where you start is to make sure you're fully educated in the Togaf model, the architecture development model. But where you start within an enterprise working on architecture for your boss is I would say implement or execute the business scenario method. The business scenario method helps you identify the major pain points in your organization and gets you right there working on those pain points and getting an agreement with all the constituencies on those pain points. And starting that way working on people's real pain makes you relevant right from the get-go. Right. Great answer thank you. Anyone else want to chip in on where to start? It's a common topic I know that involves all sorts of things. Steve I just pick up on one thing just to build on what Terry was just saying. So absolutely right sort of starting in that business layer and starting to look at what the sort of business problems are. And one way to sort of help you through that is I don't think that the questioner said what particular industry they were involved in. But there are amongst the open group standards a number of reference architectures that have been developed for various industries not for all it's true but for some. And they can just be a great way to sort of think through you know have I covered all of the aspects of this particular industry that I'm in this particular organization that I'm in. Really just to make sure that you don't overlook any important aspects. And in particular if you're in the actually in the IT industry itself as part of an IT services organization perhaps then of course we've got the IT for IT model the IT for IT reference architecture. And that's absolutely fantastic way to sort of methodically work through the whole organization and start to look at what capabilities we've got in different areas what might be the pain points what might be the gaps where do I need to work on where do I need to focus on. Yeah, you know it's true that the reference architectures have certainly been something that our membership in the open group has been keen to work on over the last probably decade or so it's the logical next step from the the more sort of generic industry and technology and not stick approach of togaff it's a good point, good point. So, next question. Why does togaff not suggest use of any specific tools. He wants to take that one. No volunteers. I will go for it Steve. Chris is all trying. Good. Excuse me. Well fundamentally to be a hell of a long list. Togaff provides you with a framework to us to assess and execute on solving a set of problems whether they're technical business oriented, a combination of both or, you know, information, whatever, whatever the problem spaces. And while there are clusters or centers of gravity around tooling in enterprises. The framework isn't prescriptive about that because if it is what it may be being prescriptive about maybe the wrong tool for the problem in the situation you're in. So, the, the assessment phase leads you to a set of conclusions if done effectively that identify the nature of the tooling or the approaches you should be taking without presupposing those things up front. Now, of course, you do have an inventory of those things. Everybody does. Okay. But trying to assess that is really the key point rather than saying, here's the laundry list of things that you need to, you need to have classes of tools are much more likely to be addressed in that way. If you agree with that. Chris and then I think Terry is wanting to chip into. Yeah, so I think that the point I'd add to that is I'm very glad actually that toga doesn't isn't prescribed against any particular tool because you do need that choice depending on the type of problem that you're facing. The reverse is is different in that there are great many tools out there that implement or enable toga in various ways have got various aspects of the framework embedded within them. And there's a lot of these tools out there just go on to any search search engine you can quickly find plenty of them. And really part of the skill is in figuring out which is the appropriate tool for my particular problem and my scale of problem because just like any set of tools, depending on the scale of the problem you're tackling, you might need a different tool. So if you're tackling something quite small and simple, then quite small, simple tools will do. You're tackling some immense organizational problem with lots of businesses involved, lots of activities, you might need a top end and therefore probably quite expensive tool. So you need to bear to make those choices. So I'm very pleased actually that toga isn't prescribed against any particular one. And as Andrew said, people often they might start with a less sophisticated tool, maybe an open source tool and then move to one of those more, more robust commercial tools with more functionality. Yeah, that's a great comment. Terry, you wanted to comment. I just wanted to simply say a quick answer is why not because by design we chose not to at least in the early evolution of toga. And it was kind of for all the reasons that we're stated above, but mainly because we knew the tools were going to develop over time and they're constantly getting better and we want to enable that that competition. But no, we don't, we intentionally decided not to recommend tools to be tools agnostic to enable open competition. Right. And we do have some, some certification accreditation programs inside the open group. We do. We do. Don't we, Steve? Shall I just talk about this? Yeah. Yes, we do have tools toga for nine tool certification also argument tool certification. If you go to our website and go down through the certification tab, you can find a register of the tools. And it's interesting when you look at the register, they all have a very detailed conformance statement because, as I say, a tool could be for, for, for a little or for a lot of that what's covered by the standard. So you can actually go and evaluate each of the tools that is on on the register. A very detailed conformance statement you can look at to make your own assessment of which tools might be suitable for your problem. Great. Thank you. All right, we'll move on from tools. This one's got your name all over it. Mr. Holman. Do you have an EA mantra? So I call it a mantra. Actually, it's just a tiny little checklist. And anyone that's ever worked with me will be able to tell you what it is to be honest. So I think that's why it's probably recognizable. So, so my mantra is in enterprise architecture space. We worry about three things V I E and they stand for viability integrity and extensibility. So the mantra behind that is that everything else. You shouldn't be worrying about as much. And the reason I put that in is I actually. And, and, you know, Mayor Culper, historically, see an awful lot of people working in enterprise architecture roles who have a huge amount of experience. A lot of knowledge have probably, you know, learned through experiences, good and bad along the way. Try and actually end up redoing solutions that they see coming their way. Try and actually impose their thinking. And often it's that could be good because they're thinking is better, but that's not really what they're there for. In my view, that's what the solution architects there point to work with them, especially when we come back to that agile question earlier. The things that you can worry about over and above that that don't get picked up at the solution level are just one. Will it work viability to integrity? Will it damage anything else when you put it in? That's kind of you're worrying about the entire estate and extensibility is. Well, nobody else actually is checking if all the sufficient doors are left open for that kind of future need across the piece. So that's my mantra. Just worry about those three things. And genuinely, there are people that I've worked with who printed out those three letters and stuck it on the wall above their desks when we used to have desks in offices. So I put that as my mantra. Good for you. Thank you, Paul. That's a great, great explanation as to why as well. Anyone else have a mantra? Terry. Architect for value and enable those that make decisions. Great. Simple as that. Always a good one. Yeah. Yeah, easy to forget sometimes in the, in the scope of some of these projects, but great one nonetheless. Now, let me see here. This is probably going to be our last question. And I'm just trying to call it up here and it's eluding me, but from, I just read it and I think it was how can one, how could one use the Toga principles to can't find the question. Come here. To streamline stream line processes across an organization, multiple processes across an organization. How come when you use the Toga principles to streamline processes across an organization? Anyone want to take that? Great. Terry, off you go. So that would become a principle for a given organization. And I think the original text said to standardize process. You're quite right. Thank you. And so one would create that, that principle for that organization and how you would implement it would be through the, well, how you sell it is through good rationale for doing that. And how you would implement that is through the implications of those principles. So the implications might be that every organization must have their processes. There must be some governance to ensure the standardization of the processes existed. But you would go through the method behind Toga principles to implement that for an organization. Great. Thank you. And essentially it's what it was designed to do. So that's great. Anyone else have a comment on that? In answer to that question, a quick one from me and I think this is just a gentle sort of corollary to it is. As soon as you ask the question, one of the things when we were tying it back to one of the questions is about where do you start and adding to that I would put context in because when somebody asked me to standardize processes, my first question in my head is why do I want to do that? Because the first thing I want to check is, is it actually the right thing to do? Because with the standardization can be beneficial. But what is my motivation and my rationale? And that's how I would use the principles is to genuinely go back to the, what is it I'm trying to achieve? And then and then why to make sure that that standardization, which sounds like a good idea on the face of it, actually is honoring the intent. Right. Great point. Great point. Anyone else want to chip in? If not, then folks, we are going to leave it there. I always feel with these panel sessions that there's so much, so much more we could ask and so much more you could you could impart but but we have to be respectful of people's time and across across the globe. So, thank you to our experts today. Paul Holman, Terry Blevins, Chris Frost, Andrew Josie and Chris Ford. Great job guys. Thank you very much. And importantly, a great thank you to everyone who joined us live and if you're watching this afterwards on demand, which many people do, then thank you for taking the time to do that. So, basically, that's that's it for for episode six, but please join us in two weeks time. That's November 2nd. So you don't have to work that out where my colleague Dr. Palab Sahar, general manager for the open group in India will be leading a session on digital government strategies and citizen centric EA. And if you haven't heard and even if you have heard about the great work that's being going on there and enterprise architecture in India at various levels of government, then Palab will help us through help us through some of that. It's a it's a great, great story and and guess what a lot of it's based on our Toga standard. So we've reason to be very proud of that. That's it for today, folks. Thank you from me. I'm Steve Nunn, President CEO of the open group and delighted you could join us. Have a great couple of weeks and see you on November 2nd. I hope take care and that was talking Tuesday. Bye bye.