 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. Minute EA, give me a minute and I'll think about it, just one minute. A minor or minute detail may seem unimportant, but precision and small details can often be easily overlooked. They can also make a massive difference, think marginal gains in all those sort of 1% adding up to make a big improvement. So in 60 seconds or thereabouts, I want to provide a smaller or minute thought that could lead to a big idea, maybe sow a seed, gives us something to think about at the back of our minds throughout the day. I'd love it if it gave us some inspiration or food for thought on a parallel topic, or helps us to see something from a different angle to solve a problem that we've previously been stuck on. My one minute thoughts are going to be mostly around architecture, architects and architecting, but hey, isn't everything? Thanks, I hope you enjoy. Welcome everyone, welcome to Toolkit Tuesday. That was Paul Holman from IBM. Many of you will have seen Paul at some of our earlier sessions, so we're continuing his season of EA minutes as we go through, so watch out for more of those. He's got some great stuff to offer us. Wherever you are in the world, thank you for joining us. We've got a lot of people signed up for today, and our main theme today is microservices architecture. We'll get to that in just a moment, but just a couple of things that those of you who are regulars will probably tire of me saying, so I apologise, but not everyone is. We're using the WebEx tool today, as you'll know, if you've got this far, and the way that we would ask you to do questions for our main speaker today is through the Q&A channel. That's the Q&A channel rather than the chat channel, so if you can't see the Q&A channel, if you go to the three dots that are in the bottom right hand corner of your screen, you'll be able to see the Q&A channel, click on that and that will bring it up. That's where you would ask your questions, please. We do have a limited time for questions, but we'd love to get some, and that's where to get them, please. Please use the chat channel, as I can see some have started already, as is our tradition. It's nice to see before I mention it. Use the chat channel to communicate with your other folks on the broadcast today. Typically, we let people know where we are, where we're joining from in the world. It's very much a global audience, and we love to see all the different countries and places in the world and anything else you want to share with your fellow attendees today. Without further ado, we're going to move to our main topic today, microservices architecture. To talk to us today, we have one of the major contributors to our recently published series guide on microservices architecture, and that is Mr Peter Maloney. Peter is a senior engineering fellow at Raytheon company, and his long career has taken him from developing and applying solid-state technologies to radar system applications to his current role as a system architect. He became interested in enterprise architecture and particularly SLA 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 throughout management and security. He's 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. He's also currently the co-chair of the microservices project within the Open Group SOA working group. So a warm welcome from the Open Group on Toolkit Tuesday to Peter Maloney. Are you there, Peter? Yes, I am, Steve. Thank you very much. Can you hear me? Yes, I can hear you clearly. Thank you. So over to you and then we'll come back for some questions. All right, very good. So as Steve already indicated, I'm here today to talk about the Togaff series guide for applying Togaff to microservices architecture. This guide took about a year and a half to develop. It actually was just published a couple of weeks ago, and I've got a reference to the guide number at the end. So again, thank you all very much, and glad to have you here today. So the intent of the guide is basically, of course, we're trying to contribute to the Open Group mission of bond-related information flow, and particularly we're trying to provide some guidance on how the architect can use the Togaff standard for developing, managing, and governing microservices architecture or any architecture or MSA as part of the scope. And that's actually an important statement, and I'll come back to that in a couple of slides. I've actually been involved in the microservices project since about the summer of 2014, I think. It's gone by pretty quick. While many of the characteristics of an MSA are very similar to SOA, in fact, our official position in the services project is that an MSA is a subset of SOA. This particular guide is dedicated for MSA only, and so I'm going to really focus on the differences in characteristics between the two. So the agenda today is, for us, I'll just briefly define what a microservices architecture is. Again, it's a distinct item from a SOA. I talk a bit generally about the use of the Togaff standard and how it applies to MSA, and then move on to enterprise architecture in a distributed world, and that is the world in which we find ourselves living today. Increasingly, cloud-native or cloud-centric, increasing numbers of users and also developers in a global environment. So that means we have to really look at the implications on the architecture and the architecture development process in that very distributed environment. So I'll go through some of the impacts that doing an MSA will have on that, first on the role of the stakeholders in that development, and look at the individual types of architectures within the microservices, business, information systems, and technology architectures, and finally, I'll turn to the question of governance. Governance is very, very important, of course, in any sort of application and architectural development. It's going to be even more important in a microservices environment, again, because of the distributed nature of everything, and then I'll sum up and we'll have some time for a question and answer. So first, what is the microservices architecture? So in the microservices project, we've defined it as an architectural style, defines and creates systems through each or small self-contained independently deployed services that align very closely with business capabilities. So we've come up with three key features we think distinguish an MSA from another type of SOA. The first and really the most important of these is service independence. Each microservice has to be independent of all other microservices and all other microservice instances. So each type of microservice is developed, deployed, and it can be changed independently. Going along with that need for independence is the concept of single responsibility. So each microservice is mapped to a single atomic business function or activity for which it is responsible and it's not responsible for anything else. And last that goes along with that is self-containment. So microservice has to be self-contained. It has to be able to access whatever data that it needs to carry out the particular function or any other resources, knowledge of business rules, etc. And the reason why this is important is or these characteristics are important is that what that does is allows you to put together is services that are because they are independent, they are also gives you resiliency and scalability that you really can't achieve any other way. The important thing is because those instances are independent, so I can scale them up and down as needed by my business. In the event of failure, I can simply spin up another instance to take over for the one that's failed with minimal interruption or other interactions. And again, this is what really gives me a resilient architecture capable of staying up regardless of what's actually happening to any particular individual instance. It also means I have technology independence because I can develop those services independently as the development team best sees fit. I can deploy them very flexibly, the same reason, and they are also reusable once I've defined and developed the microservice since it's independent and self-contained. I can go use that in another context if that's the easiest way of meeting my business needs. Okay, so Togaf and the MSA, so obviously the Togaf architecture development method is still going to apply to MSA. The details will be different in a few areas, and I will go through some of those on the slides that follow. The most important thing is right at the beginning in this preliminary phase, you're going to make the decision to use the principles of microservices architecture. And that's going to be the independence, the single responsibility, and self-containment. And you really have to decide those are the principles you're going to lie upon and enforce. Even if you're enterprise, it's already service-oriented. Again, the independence, particularly in single responsibility, a thing that you have to take into account as part of your architecture and make that commitment to. It also has some organizational impacts, which we'll discuss a little bit later. The other thing that goes along with MSA is typically these cycles will be shorter than would be the case in a more centralized or monolithic type of architecture. We are trying to in a microservice project remain agnostic to development methods, so we're not prescribing the use of DevOps or agile development or any of that, although those both align very well with microservice architectures. And of course, one of the things that comes out of that is the planning and development intervals can come very fast. You're talking about in agile, you have sprints that are a couple of weeks to a week or a couple of weeks and maybe a month at most long compared to a much longer development cycle for waterfall type development. So we have to bear that in mind as well as we go through this. So the role of stakeholders in MSA. So coming back to what I said initially, kind of a spoiler alert, microservices are not going to provide your complete enterprise architecture. MSA brings you a lot of wonderful things. Principles of independent and self-containment mean I have scalability, I have resilience, I'm able to recover quickly in the event of failures, but that also limits your ability by capabilities at higher levels in the enterprise. For example, choreography of microservices. You cannot use microservices themselves to do any sort of choreography. If you do that, you're going to introduce dependence upon one microservice upon another one. As soon as I have dependence, I'm violating that principle and I'm running the risk of cascading failures in the event of a single instance or single microservice fails. So if you need to do choreography, you're going to have to do it at the application level or some higher layer in your enterprise architecture. What MSA does give you gives you a very highly reliable and scalable set of capabilities. There are a subset of that overall enterprise architecture and coordination and alignment with those stakeholders across the enterprise is going to be even more important than you thought it already was. Okay, so looking at the role of stakeholders again in MSA, so the decision to use an MSA to meet your business requirements, that's an enterprise level decision by the enterprise architects. The actual implementation of that MSA and the technology choices that go along with that is the responsibility of the project architect and they have to keep that all in context. So a typical set of stakeholders is shown here in the stable. So the project architect is responsible for the implementation of that particular capability but they always have to obey the guardrails that were laid down by the overall enterprise architects and reflected in the architecture review board. So if you need to violate one of those defined architecture principles, you need to go to the architecture review board and explicitly ask for a waiver for this particular case. So you can't allow anything, any deviation from that if it's not given a waiver by the ARB because if you do that, you're going to simply open the doors to technological chaos and incompatibility. So those architecture principles that are going to laid out, that's going to be part of the documentation that you're going to produce coming out of preliminary phase. And again, the architect has a free hand within their domain but they have to remain within the guardrails that are laid down by the enterprise architects. Okay, so as I said, so in MSA, each microservice is responsible for implementing a single atomic business function. In order to get to that point, you have to take your business processes and your capabilities and go through a process of decomposition that arrives those atomic functions. Getting to the point where they cannot be, whether you're irreducible and you can't break those down into one or more additional functions that would be carried out by additional services. The requirements that go along with those functions are more likely to be distributed in an MSA implementation as well. And typically you have a federated organization as well as a federated architecture. I forget whose principle it is and said, you know, a system architecture tends to reflect the organization of the enterprise that's creating it. But it's going to be, the reverse is true as well. If you really want to have an organization that reflects the system architecture in this case and federated is going to work best in this kind of environment. So the information data system architecture, architecture is really is broken down into two other architects, sub architecture is the data architecture. The application architecture are not really going to dwell on the application architecture here. That's not terribly different from a SOA, for example. But the data architecture is constrained by the data necessary for that particular business function that's being supported by the MSA. It's also possible you're providing data to other functions or you're being supplied with data originates externally, whether on an occasional level or constantly. But in the MSA, most of that data is going to be distributed. So the data distribution models have to reflect that. And again, you're going to be relying on resilience and scalability. So your data needs to do that as well. Have those characteristics, as well as your microservices, or you're going to lose the benefits of doing an MSA. And again, this is from a purely architectural standpoint. You can always choose to violate one of these principles. If it's necessary for your particular application, you just really need to keep in mind deliberately that you're doing that. But for example, if you've got a third party database vendor who's guaranteeing you seven nines uptime, and you're going to rely on that as a central point of failure, that is a decision you can choose to make. But you have to be aware of the implications that go along with that. So technology architecture. So of course, the decision to use microservices provides some or all of your capabilities is a technology decision. And the scope of that, the functionality, the use of your data, the requirements, the architectural principles, the patterns you're going to implement, and whatever standards you're going to enforce upon yourself, as well as the deployment mechanisms and what you're running in for an execution environment. That's all going to define what your technology architecture ends up being. And that's all covered in TOGAF phase D in pretty good detail. Again, the independence of these services and the idea of a federated architecture. So you can have independent development of your microservices. So your development teams and your project teams can make decisions about what programming language they want to use, what libraries, tools, et cetera, they're going to use, how they're going to deploy. And you can leave those decisions to the development teams and the project leader, project architect, as long as they remain subject to the overall constraints of the technology and enterprise architecture is defined by the enterprise architects. And finally, governance, right? So an MSA is an inherently distributed architecture. So the government's requirements really have to reflect that, even compared to a regular service oriented architecture, which isn't necessarily distributed even though it's using services. So really a federated governance structure is likely more successful than a fully centralized one because you really want to allow those teams to develop their own rules for governance and their own processes without having to reach back to a central authority every time. And the way to do that without having chaos resulting, of course, is that you really need two parallel tracks for this. So each team has a self governance path that they are applying only to their particular service within that MSA. But there also still has to be an enterprise architecture governance tracks which supplies the guardrails that are established for that enterprise. And again, if that team has a really, really good reason for violating one of those principles, they need to ask for a waiver and be granted that explicitly. Because you don't do that, you're really running the risk of now you've set up an organization that's institutionalized the process of technological chaos and instability because they are not required to adhere to an overall standard and you run the risk of incompatible tools, incompatible communication mechanisms, incompatible deployment, and things will get ugly in a real hurry. So finally, so just I've tried to go briefly through here some of the highlights of the key differences from the use of the regular Togap standard for an MSA as opposed to a SOA. And this is really about helping the architects achieve their final objectives, developing MSA solutions that effectively can divide ads or responses in being able to meet the needs of their specific business capabilities. And just a brief advertising here. So the guide which was just published, the series guide, is G211. It's available for publication in the Open Group Library. We have a couple of additional publications we put out. Our foundational publication I think was back in 2016 on microservices architecture goes through the derivation of how we came up with these three key principles and other principles that go along with that. That's W169. We published a paper on the benefits of DevOps methodology for microservices solutions. Again, not trying to prescribe it here, but it is undoubtedly true that distributed architecture and the DevOps techniques go very well together as well as agile development. And we published a, which is actually also another guide on microservices architecture for the Internet of Things that's also available from the Open Group Library. So thank you very much for coming today and I'll be happy to try and answer any questions in the time we have remaining. Peter, wonderful job. Thank you very much. A big subject and a lot to cover in 15 minutes. So thank you for giving us that overview and the pointers to the guides themselves, the documents. So very easy to find on the Open Group website at the Open Group Library. So several questions coming in and not much time. So I'll go straight to one, Peter. You talked about governance a bit, obviously towards the end, but at the beginning about choreography. And the first question is, at some point, some choreography from a higher level cannot be avoided. How do you cope with that as part of an MSA team? Yes, and that's an excellent question. And you're right. Again, why I said that an MSA can only provide part of the solution to your enterprise architecture. At the application level, you are undoubtedly going to have to do choreography. Typically, doing it at the application level is the easiest because, again, you have to keep those individual microservices independent from one another to allow for individual instances to fail, scale back up, scale down in response to what your demand is. So typically, you handle that at the application layer. And again, this is part of defining a communication with microservice through an API. It's the simplest thing to do and rigidly adhering to that. Can you say a little bit more about what you mean about distributed business requirements? What are they? So really, what that amounts to is, when you look at it, a federated organization, all I'm really trying to say is that each of those business organizations that is developing their part of an MSA or their MSA needs to have the responsibility and authority to create what their own requirements are. And, again, it's about federating that responsibility and not forcing them to constantly reach back to a central authority in order to get permission for requirements development. Again, not prescribing the methodology, but in order to respond quickly, which includes your requirements development for your microservices, you have to push the responsibility for those requirements down to as low as level possible so the developers are able to work at a local level with a requirements team as well. If this all really comes down to system and software engineers ought to be part of the same team. I don't know why we feel they need to discover that over and over again, and then ignore it next time around. But that is an absolute tourism in this business which we suggest. Yeah, no, absolutely. Absolutely. That is an often learned lesson. Again, on governance question, how much freedom should be given to teams to select anything in their technology? In other words, how much governance is ideal? Yeah, that's a good question. I'm not sure I have a really good answer to it. Part of that is the degree of compatibility that you can maintain with different technologies. Obviously, if at an enterprise level, you've selected a particular distributed database, for example, whether that's CacheDB or any one of a dozen other rival candidates, that's going to have to be everybody's choice. You can't allow that sort of flexibility. At some point, there are some things that are going to be necessary for each one to adhere to. Other than that, there's not a simple answer to that question, I'm afraid. No, sure. There are obviously lots of variables in there, lots of variables. We do have a ton of questions coming in, and I'm afraid folks, we're not going to get to all of them, but if you could pick one thing, Peter, what would you think is the biggest advantage of implementing an MSA in a system? Yeah, I'd say the single best advantage of using an MSA, again, is because of servicing independence, is the resiliency that it gives you, particularly for mobile applications where connectivity can be up and down, you have the risk of connections hanging up, instances failing, you really have a hard time beating an MSA in terms of the resiliency of that architecture. So when instances fail, you simply spin up another one, and you can continue almost seamlessly without the user, who's the person we're really trying to hear, ever being aware that something went wrong in the interim. I think that's the most important advantage that MSA gives you. Okay, and one last one, and apologies to those whose questions I don't get to, but domain-driven design, do you see that as bridging the governance function between MSA and enterprise architecture? I think it can. I think domain-driven design is a valuable technique, and again, part of the ability to federate these decisions includes breaking it up into the key domains, and particularly since requirements will tend to align along domain boundaries, I think that can be a very valuable technique in allowing this sort of federated, self-governed activity to take place. Right, I appreciate that. We'll leave it there, Peter. Clearly, this is a topic where there's a lot of interest and a lot of questions, and we may need to do another one of these on the topic and get some of these answers. But in the meantime, Peter Maloney from Raytheon, I appreciate your contribution and your guidance on MSA. Thank you for joining us. Well, thank you very much for having me, Steve. I really appreciate the opportunity to spread the word on this, and it's been a lot of fun and very educational, so thank you again. Yeah, it's great to hear. It was fun along the way, too. Okay, folks, that's the end of Peter's presentation. We're going to have another short video from another one of our resident experts on here on Toolkit Tuesday, Terry Blevins. Terry's Toolkit Tuesday tip up next. My name is Terry Blevins with the Toolkit Tuesday tip. I have given many messages about ensuring that you as an architect focus on real-world customer challenges, and of course, I stick by that. But having said that, you as an architect must also deal with issues that are not exposed directly by listening to high-level customer challenges. These issues are often in areas that customers overlook because they don't directly relate to their business functions. You as an architect not only have to ensure these issues are dealt with, but you may even have to convince the customer of their importance. These issues are often referred to as non-functional requirements. A few non-functional requirements are present in the open group vision of boundless information flow achieved through global interoperability in a secure, reliable, and timely manner. There are, of course, many more, and your job as an architect is to make sure these requirements are dealt with as appropriate for a given scope. Another important point is that these non-functional requirements are often at odds with each other. For example, security is often at odds with performance and usability. It seems like I might be opening a can of worms, but you're asking, what's the practical tip here? Well, here, there. First, don't ignore. Use your experience to identify those non-functional requirements likely to pertain to a given scenario, and do not ignore the temporal nature of those requirements. For example, interoperability issues come up over time as new things come into the enterprise. Second, do explore. Use trade-off analysis to identify how these non-functional requirements interact or interrelate, and use risk analysis to identify which have priority. Third, model to demonstrate how the non-functional requirements directly impact the delivery of functional requirements. Make it tangible for the customer so you can get their buy-in on the importance of dealing with them. So you wanted to be an enterprise architect? Well, these are the kinds of issues that you have to deal with. For more information, please check out the Togaf Library. Keep architecting for enterprise value. Thanks for watching. Thank you, Terry. Thank you. A consistent message of keep architecting for enterprise value, an important one. That's it for today, folks. A quick word about the next one I could see in the chat. There was a question, when's the next talk? It's Tuesday. It's nice that you're interested. The next one is on February 22nd, so two weeks today. We generally run them every two weeks. And the topic there will be modular open systems architecture, which is another style of architecture. It's being greatly picked up and endorsed, particularly in government circles in some of our activities there in the open group, but more broadly applicable too. And to present on it, we have a real expert there, Dr. Steve Davidson of MITRE Corporation. So do join us in two weeks' time for another toolkit Tuesday. Meantime, take care wherever you are, and we look forward to seeing you next time. Thanks for your participation and giving up your time today. Bye for now.