 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. The sum 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 wherever you are in the world, and thank you for joining us on Toolkit Tuesday. As I always say on these occasions, I hope wherever you are in the world, you're safe and well. And obviously, our thoughts and prayers are with the people of Ukraine at this particular time, as they continue to endure the horrors and tragedies of war. Our thoughts are with them, and I'm sure we all hope for a speedy resolution to this situation, and just putting behind and getting back to normal for those poor people. Anyway, we can all talk for a long time about that, and just know that we at the Open Group are very thoughtful about the situation, and life has to go on, of course. And we have a broadcast here today, which is Why You're All Here, I hope, and we're going to have a slightly different session today at Toolkit Tuesdays. Just before I introduce that, though, we have something very exciting happening soon. We have our first face-to-face quarterly event of the Open Group for over two years, and very relevant to our audience here for Toolkit Tuesday. It's an architecture practitioner's conference. So it's being hosted in London. It's a hybrid meeting, so we will have a mix of people physically present and those joining remotely. And hopefully many of you here will be either there physically or joining us remotely. It's going to be a great event, and we'll have some interesting things to announce at it. So please join us. So for today, we are looking back at some of the questions that we didn't get to that have arisen on previous episodes of Toolkit Tuesday. We don't always get a chance to get through all the questions. In fact, we rarely get through all of them. We do our best, but we have a list of things that are hanging over from previous episodes. So please, I'll get through as many as I can. I can't promise that we will get to any new questions live today, but if you have something that's burning and you'd really like to ask our panelists today, then please do submit it in the Q&A channel. This is the WebEx Tool and the Q&A channel. If you can't see it, if you click on the three dots in the bottom right-hand corner of your screen, you'll see Q&A as an option to click, and that's where you should ask any new questions. Please use the chat channel, as people are starting to do, to give greetings from wherever you are in the world. It's a very much global audience here, and we're very proud of that. So it's great to see where you're all joining us from. So without further ado, I'm not going to risk not getting through these questions for a second time. So we have three panelists joining me today who will be taking a look at some of these questions, and it's a great pleasure to welcome each of them here. So in no particular order, Chris Frost, Principal Enterprise Architect Global Delivery Unit at Fujitsu. So Chris has worked for Fujitsu since 2005 in a variety of technical leadership roles. At present, he's Principal Enterprise Architect within the Global Delivery Unit, which provides standard services, technical guidelines, and support to the Global Fujitsu Group. Inside the open group, Chris has led the Togaf Agile Working Group during 2020 and is contributing to a number of current architecture forum activities, as well as doing some being co-chair in our digital practitioner workgroup. 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 software startup house called Shamrock Marketing. So welcome, Chris Frost. Our second panelist today, a colleague of mine, Dr Palab Sahar. Palab is the general manager for India within the open group, as well as Chief Architect for Southeast Asia and President of the Association of Enterprise Architects for India. Dr Sahar has been identified as a thought leader by IBM Smart City Connect and featured by Forbes Magazine. A MAGT NEGD Senior Lead Expert in Enterprise Architecture and a Visiting Professor of Digital Architecture at the Indian Institute of Management, Dr Sahar advises various ministries and states in India on matters pertaining to government-wide architecture initiatives and the scope of his work expands beyond India too, of course. Welcome, Palab. Great to have you back. And last but not least, Peter Maloney, who is Senior Engineering Fellow at Raytheon Company. Peter's long career path has taken him from developing and applying solid state technologies for radar system applications to his current role as a system architect. He became interested in enterprise architectures and particularly service-oriented architecture as a result of the ever-expanding need for providing access to increasingly complex data products to a diverse group of end users with the resulting needs for collaboration through management and security. Peter is a Raytheon-certified architect, which is a program accredited by the Open Group and a three-time winner of the Raytheon Excellence in Technology Award. He holds one patent and has authored more than a dozen papers. Inside the Open Group, Peter is the co-chair of the Microservices Project within the SOA Working Group. So, welcome back to you, Peter. Good morning, Chris. Good morning, Brian. Thank you very much. So, everyone's here. Great to have you all. And as you can see, folks, we're in good hands here for getting our questions answered. I'm going to start with the question that's probably come up the most regularly in one form or another over the episodes of Talk It Tuesday and, in fact, generally inside the Open Group. I'm going to point it to you, Chris Frost, first, because it plays right to one of the things you've been working on in the Open Group, in the Turguff Agile Working Group. And the question, the latest version of the question anyway, is enterprise architecture and agile. Are they fundamentally incompatible or can they coexist? Can you kick us off with that one, please? Sure can, Steve. Yeah, thank you very much. Well, I mean, the short and simple answer is they are absolutely compatible and must coexist. They need each other very strongly. Whatever approach you're using to build large-scale solutions and do all the good things with enterprise architecture about tying that back to your business objectives and helping that develop your business strategy, you need all of those same disciplines of enterprise architecture, whether you're using an underlying waterfall style of delivery or an agile style delivery or whatever you're doing. And you can see the evidence of that if you just simply look at many of the well-known agile-scale methods. I won't need to name them here, but I'm sure everybody knows and can think of a number of the popular methods for doing agile at scale and that need for architecture is explicitly called out in them. And of course, the relationship works the other way as well. If you look at the TOGAF standard, for example, it says, of course, that you need to do a certain amount of work and you need to plan that and you need to deliver that, but it doesn't say anything at all about the method of doing so, whether it should be a waterfall approach or an agile approach. So they need each other. You need the project framework in order to plan and control and manage the work and you need the architecture goodness so that you set all of those right architectural directions and make sure it's tied back to your enterprise strategy. So they coexist very well and they need each other very strongly. Great stuff. Thank you, Chris. Thank you. And we will probably hear more about that soon. I imagine it's a question that keeps coming up. It is. Not the last time you'll answer it, I'm sure. So I'm going to switch now. If I can take a question. I mean, I'll deliberately not ask the other panelists that one because we've got lots to get through, but we have a number of questions that arose from your presentation a while back, Peter, on microservices. And specifically the Togaf series guide on microservices, that microservices architecture that you helped author. So first question for you, Peter. Could you please give an example of a microservices architecture used in an organization? Sure. And I think probably the classic example is actually Netflix. It's certainly one that we studied as part of our work. They're streaming services based entirely upon cloud-based microservices these days. They have more than a thousand microservices involved in managing their operations. Originally they were a monolith and they embarked upon moving to cloud-based and microservices. Back in 2009, I think before the term microservices was even in common use and they migrated their entire ecosystem to in a current cloud-based incarnation over a period of about two years. And I think one of the testaments as to what that got to them was some years back the entire Amazon Web Services Northeast crashed. And Netflix was not actually aware of that until some hours later when their metrics told them what had happened because they remained up and running without interruption through the whole thing. So that shows the power of both Agile and microservices based architectures. Right. That's great. I can see how other folks are nodding on that one. And while I have you, Peter, and we're on microservices, I'll take another one early in this. One of the things that you referred to when you presented on microservices architecture was the concept of distributed business requirements. Could you say a little more about what they are? What do you mean by distributed business requirements is the question? Sure. That's a good question. What we really mean is simply that, and this I think ties in very well with the idea of domain-driven design, is that each business domain, and you can break this down to a lower level, obviously, has its own distinct set of requirements that, in large part, are not really dependent on requirements anywhere else within the business enterprise. They are really specific to that particular domain. Of course, you have to worry about, you know, intra-business interface requirements, and you have to maintain all those in common. But a lot of that activity is carried out within just the business domain, and it really ought to be the concern of only that business team to decide how those requirements should be met. And as I will talk and answer to a different question, distributed governance is really the key concept making this process work, because otherwise you're risking creating, you know, a very slow-moving model where you have just too many stakeholders involved to be able to make decisions quickly, and being able to make decisions quickly and implement them is really one of the key starts at this stage. Great stuff. Okay, well, we'll cycle back to that. Other panelists, if you do have anything to add, then please let me know. But otherwise, I'll carry on going through the questions, and I'm going to come to you next, Palab. We had a question that came in that was about the use of Togeth, specifically, or enterprise architecture more generally, in education. And are you aware of Togeth being used in the education field? And I know this is quite timely as a question, so can you take that one on for us, please? There are two ways to answer that question. One is whether enterprise architecture broadly and whether Togeth as a framework is taught within educational programs in academic settings. So for instance, if it is a course in some kind of a graduate or postgraduate level program. So the answer is absolutely yes. There are several universities across the world who do this, and specifically, as you mentioned, this is a very timely question. In India, we are launching the academic initiative with that very intent, basically, to introduce enterprise architecture, to introduce architecture thinking at graduate and postgraduate level courses. So this could be, for instance, part of an MBA program or an MS program or Master of Engineering or Master of Technology program. So the launch of that initiative is not to happen this Friday. So this is as timely as you were mentioning. So that's one part of the yes. The other part of the yes is, do we have enterprise architecture being adopted within the educational institution because even an educational institution is an enterprise, right? So to that, the answer is an absolute yes, because just two weeks back, we launched, we released a new case study, which is basically Spain higher education sector adopting enterprise architecture for its own universities and the entire education ecosystem. So this is basically applying to a gap within the enterprise of a university or an academic institution. So that's why I said the answer has to be from two perspectives. One is being taught as a subject and other is being university or an enterprise, university being taken as an enterprise and modeled in terms of, from a to that perspective. So yeah. I think you make an important point, Pada, but a university or an academic institution, it is an enterprise in itself. And so there's nothing that means that EA isn't applicable there. I mean, Chris or Pada, have you seen any being involved in any work that's aimed at the academic world? Certainly have, Steve. Yeah, a couple of examples that have personally been involved into varying degrees. I won't name the specific universities because they protect the client confidentiality. But certainly one example, a university in the UK where we were designing an internal solution for them. And of course we used as part of our standard architecture practice, Togaf to design that solution. And actually another example in Japan, because of course Fujitsu, who I work for, Japanese company, working closely with a large university in Japan. I was providing some sort of backup support because I'm afraid my Japanese is nowhere near good enough to be able to actually directly engage with the Japanese customer. But I was supporting some of our architects who were directly involved there where we were helping them collaboratively develop their enterprise architecture using some Togaf hands and in fact some ArchiMate modelling as well. So yeah, absolutely using all of this goodness to help the university define their own internal enterprise architecture. Yeah, that's great. And I think it's a sector that I think we'll see more and more case studies coming out as it impets a bit more and there are more courses taught and more use and more ability to talk about these things. What worked and what didn't. That's what everyone wants, isn't it? Of course. Let me move back to microservices architectures. You stirred a lot of questions when you were presenting last time, Peter. So you touched on this earlier about governance but the specific question that came in which I think is a great one is how much freedom should be given to teams to select anything in their technology? You know, there's a lot of talk about giving the teams a lot of independence a lot of autonomy here but how much freedom should be given to team to select anything? In other words how much governance is ideal? Yeah, and that is a great question and it doesn't have an easy answer, right? And part of this is relying on enterprise architects to create a set of enterprise guidelines for those items which really matter to the enterprise while allowing the individual teams to have a free hand in things that don't need standardization at the enterprise level. So for example, certainly purchasing decisions and company-wide agreements which can provide cost advantages at the enterprise level might dictate your choice of, you know, particular computing or storage technologies. Perhaps the enterprise wants to make sure that all of its users or its customers see exactly the same interface same look and feel as much as possible and they probably create a template for all those application interfaces and they want to mandate that for all external transactions. And so the important thing is, you know, those enterprise architects really need to think very clearly about which items are very important at enterprise level and create appropriate guidelines and a little bit of self-motion in our first paper for the Open Group on Micro Services which is referred to as W169. We actually provided a governance model that shows that and again that the team that owns Micro Services is really about having autonomy between what's in their domain, you know, what their boundary context is. Yeah. It's good to mention specifically the the white paper, the document because there's a lot of information on the Open Group website on this in the in the Open Group library and you can search by topic and there's a lot of good stuff there that folks may not be aware of. So, thank you for that. Any other comments for Palovo, Chris on governance as you've seen it. It's a topic that's very important and comes and goes and anything. Steve, you started off with a question about enterprise architecture and agility and you have the as I said the two coexist very strongly. But when you think about how do you need to perhaps adapt some of the enterprise architecture practices that we might have followed in the past in order to work in agile environments then the slide change a change in your approach to governance is one of the very concrete things you see typically in a waterfall style approach your main governance tools might be some sort of stage gate review. You see these sorts of things happen very commonly as a project moves perhaps out of a requirements phase into a design phase and then at the end of design phase you would probably organise large sort of normal stage gate reviews whereas one of the very concrete changes you have to make moving to a agile style of delivery is to do a much more continuous and consultative approach to governance and that has some challenges as well as well as the advantages of giving the greater agility but that coupled with the obvious things like working developing the architecture in a much more iterative style. Those things I think are some of the real concrete things that you have to change about your way of working so adapting your approach to governance is one of the things you need to do in order to work and truly get the benefits of an agile approach. Absolutely. Yeah Steve if you remember my session was on public digital platforms in November and in fact from a government perspective public digital platform is a great example of how agile architecture practices and microservice architecture that Chris and Peter have spoken about is actually getting implemented. Just to give you an example what we do is for instance we are currently having a platform for digital health and within that we have identified certain building blocks which is basically taking the solution building blocks identified and mentioned in the TOGAP so some of these reusable building blocks could be digital identity registry workflow management content management scheduling so these are all common capabilities that are required across sectors while I mentioned health they could easily be used in education for instance they could easily be used in transportation so taking a sectoral approach provides the ability to make this building blocks reusable across different platforms and platforms are open both to public and private sector entities and second is because they are reusable building blocks they don't have to so whenever there is a platform being developed they don't have to reinvent the wheel so by definition it becomes agile because that's the whole idea right there are these whole building blocks that are being available in fact within the government enterprise architecture workgroup we are currently in the process of developing a reference architecture for public digital platforms it's called GovStack so it's basically the technology stack for digital government GovStack and we are going to adopt in fact we have within the team we have referred to the ideas of our agile architecture publications and even the microservices architecture paper that Peter was mentioning about so we are actually putting in place you know putting in place in terms of how these concepts can be implemented and as you are aware and probably some of the people in the audience are also aware the intent here is that public digital platforms should work for countries with limited resources this is the only way to move forward it is not an endless pit that you keep putting money on developing you know digital capabilities across ministries across departments in a you know creating the same and you know wasting public resources the whole idea is to bring standardization at least in terms of certain common capabilities that can be used in a whole of government perspective but this is what we are currently covering and we are referring to the work that Chris and Peter have mentioned it's great nice to see it all coming together so Palav you mentioned the session you gave on the public digital platforms one of the questions that was hanging over from that is on those platforms and you've kind of just touched on it as well in your answer to the last question but a two-part question here do you create private clouds for government and separate clouds essentially for government and commercial enterprise or are they shared and I think you've touched on that but the second part of the question is how do you manage the concerns of confidentiality and intellectual property from commercial enterprises who participate in public digital platforms so generally these are shared infrastructures because the very idea that it is public by definition makes it a shared infrastructure digital infrastructure where both government entities and private entities can participate and come together and provide services in a way that is more usable for these citizens so that is the whole idea of and basically it's basically API based integration that MSA covers anyway so but in terms of confidentiality and anything concerning privacy this is basically governed with strong data rights strong decision rights data is very important for public digital platforms because it's basically the oil I mean I know it sounds like a cliche but that's what runs the public digital platform so there is a very strong element of data governance to make these platforms run number one and second is coming back to what Peter was mentioning distributed governance so in the government you can actually see this multi-level government entities coming into play so there are national governments there are state or provincial governments there are local governments and maybe in some large countries there could even be some kind of a rural government and in large countries they could belong to different political parties for reasons that we all know they would probably not want to share data for various reasons so therefore we have to ensure that there are certain data which is kept at the local level and only the only it is only made accessible to a higher level of government say from the local level to the state government to the federal government based on a need basis so based on some kind of consent so that's how it works so therefore what happens is we are able to bring certain data at the national level so for instance if it is a digital ID you know social security number in the US in India it's called Aadha right it has to be a national ID there is no need to have state level ID because then it replicates the whole idea you're the citizen of a country so that's an example of a national data so it's a national building block as was mentioning but there may be certain very department or ministry specific data which it's better left you know for instance in health in health domain data that is collected at the primary health center level it's better left there right there is no need for them to provide all the data it's only based on certain requirements in certain specific business processes that the national or the state level entity gets access to that data so this is how we maintain a federated approach basically to address the confidentiality and the privacy aspects that comes up when you talk of platforms excellent excellent answer Chris or Peter anything to add on on digital public digital platforms if not then I'm going to you thought about it Chris didn't you I thought about it Steve but also I'm aware of the clock of the time yes trying to be conscious of the time we have got through the questions as one here that if the panellists don't mind I will take because it's really a question for the open group and that is for me we get asked a lot what enterprise architecture tools does the open group recommend and the answer to that is that we don't recommend specific tools because we very much have as one of our principals vendor and technology neutrality what we do have is an official register of certified tools that the open group has comes up most commonly in connection with the archimake modeling language what tools are out there for that but also when implementing when implementing Togeth there are some really great tools out there that we have accredited over the years which if you're looking for a place to start then look at the register that's on the open group website for where you can find those tools so with that I'm going to be respectful of everyone's time and thank each of our panellists Chris Frost, Peter Maloney and Dr Palab Sahar for joining us again today thank you for clearing up those last questions great to hear your perspectives and yeah thank you and see you all some point in the future thank you so we're not done for this session though folks thank you to our panellists couple of plugs please join us again in two weeks April 19th when we'll have episode 17 can you believe of Toolkit Tuesday where the main presenter that day will be my colleague Roberto Severo who runs our Brazilian office and he'll be talking on the principles of an EA framework and the importance of adopting the Togeth standard so that's April 19th you'll see a slide that mentions that in our outro video and lastly a reminder for the open group enterprise architecture practitioners event coming up at the end of this month do look at our website if you're on our email lists you'll see more about that and you'll see a few notifications coming out over the coming days and weeks leading up to that fun stuff that we're doing in the build up to that conference so watch out for our social media channels there and we'd love to see as many of you as we can and meanwhile you can also participate through those social media channels of course so thank you for joining us today for Toolkit Tuesday that's it for this week wherever you are be safe be well and see you next time bye