 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. GJ, just enough architecture just in time. The idea that you only create the architectural guidance you need just as it's about to be consumed. Almost a truism. Anyone who's actually worked in large all EA efforts knows it's like sweeping up leaves in a forest. By the time you've reached one side, your starting point needs doing again. So you have to have a coping mechanism and for those who are seeking to use AEA guidance, they need to be able to rely on it being absolutely bang up to date. So, why is it so hard? Well, when I used to work in manufacturing, we called it just in time, just too late and that's what we have to avoid. So, the trick is, how can we know what to architect and when it may be needed? Answer, it's all about demand and forecasting the supply to meet it. We need an EA backlog that prioritises an EA work plan based upon captured demand with burn down rates and release schedules. Those sound like future topics. Good morning, afternoon, evening, everyone, wherever you are. Thank you for joining us today on Toolkit Tuesday. I'm Steve Nunn, CEO and President of the Open Group and I'd like to give you a warm welcome. Thank you for joining us and it's now, I think, number three or four. I'm having so much fun. I'm not sure in the series of Toolkit Tuesdays, but I'd like to thank, before I go on, I'd like to thank Paul Holman there, who you just saw on his EA Minute. Paul Holman of IBM, a great contributor to the Open Group over the years and the current co-chair of the Architecture Forum, in fact. So, thank you, Paul, for that. Paul is one of our panel of experts here at Toolkit Tuesday and you'll hear more from him in future episodes. But it's a great reminder of what just-in-time really means and how important it is. So thank you, Paul, for that. I hope wherever you are, those joining us, that you're safe and well. Just a couple of tips for getting the best out of your WebEx experience today. If you can make sure that in your settings, if you go to your layout, in your settings that you have the automatically hide names when not speaking ticked or checked, whatever your preferred word, please have that highlighted. And please make sure that you have unchecked the show video when not speaking. So that will give you the best experience. You are able to adjust the size of the panelists here for the speakers. But without further ado, we're going to press on with our main topic today. And today we're addressing not for the only time, I'm sure, in the series, but we're addressing the great topic of enterprise architecture and agile. And today we're going to look at the evolution of enterprise architecture and agile approaches, the fundamental challenges they present for architects and how and why these approaches need to adapt. We'll also consider how the tools from the open group can enable enterprise architects to benefit from the partnership of enterprise architecture and agile. And you'll get a clue from there that we very much see this as a partnership, not two things that just are not compatible with each other, which is sometimes suggested. To do this today, I'm very happy to introduce another of our panel of experts and another great contributor to the open group over the years and currently, Mr. Chris Frost, who is the principal enterprise architect for global delivery at Fujitsu. Chris has worked at Fujitsu since 2005 in a variety of leading technical roles. His present role provides standard services, technical guidelines, and support for the global Fujitsu group. In the open group, he led the Togaf agile working group during the course of last year doing some great work and contributing currently to a number of current architecture forum activities. Before his time at Fujitsu, Chris worked for EDS, which is now part of DXC on several large contracts for the Ministry of Defense in the UK. And in earlier years, he worked for Ford Shell and a small startup software house called Shamrock Marketing. So we're in great hands today to hear more about enterprise architecture and agile methods. A warm virtual welcome to Toolkit Tuesday for Mr. Chris Frost. Over to you, Chris. Welcome. Okay, thank you very much, Steve. Just give me one second and I will start the sharing so that everybody can see my slides. Okay, we should be good there. Okay, so thanks very much. So hello, everybody, and thank you very much, Steve. My name is Chris Frost and as Steve said, I'm with Fujitsu. I'm part of our global delivery architecture team. And as Steve has already said, I am going to be talking today about enterprise architecture, enterprise agility, and the Togaf standard. I want to start off by looking at the history of some of these things because I think it's through that that you can best understand how these things have developed and what it really means to use these things together. So if I start off by looking at some of the history from enterprise architecture, you can really trace the development of this back to around about the middle of the 1980s when a couple of important things were published. The Zackmann framework, which I'm sure a lot of you will be familiar with and will recognize, is the thing called the Prism Research Report. And they were both really looking into this problem of how do you do large-scale business change related to business needs and do that in a sort of logical organized fashion. And if we move on to the early 1990s, an important thing there from the enterprise architecture point of view was TAFIM. TAFIM enterprise architecture method was created and published by the US government. And importantly in the history here, this is really the first time at which you see the term enterprise architecture used as we know it now. And for those of you who might be Togaf historians, you'll know that from TAFIM you can trace the direct line to Togaf Version 1, published in 1995. And then since then, we've had a number of versions of Togaf. We're now currently at Togaf Version 9. Major Version 9 was first published 9.0 in 2009. And we're now at 9.2. If we turn to agile methods, again similarly you can trace those origins back to the early 1980s because around this time there was some study into this problem of how do you make software development a little bit more predictable and a little bit less uncertain. And there's this thing called the spiral model published in the middle of the 1980s, 1986 I think. And that was really putting forward this idea of starting with a small core of working software and then gradually building on that, going around cycles of development and planning and sort of the notion of expanding out in spirals. And these ideas led on to rapid application development. RAD published in 1991. Chuck called James Martin, which was then sort of introducing this idea of these regular reviews with business representatives and doing these short feedback cycles. And then a major milestone in the development of agile methods, 1995 publication of Scrum from the paper by Jeff Schweber. And this really introduced some of the fundamental concepts as we know them today, the idea of the sprints and some of the sprint ceremonies and the sprint planning and so on. Interestingly in the Scrum paper you won't actually find the term agile at all. That doesn't really come along until the beginning of the 2000s. And in particular we have the agile manifesto in 2001. Moving on from there, really the study has turned to how can we apply some of these ideas at scale, moving up from the idea of the single software development teams. And how can we apply them to more things than just software development? So for example we had Safe published in 2007 from Dean Leffingwell's book and Disciplined Agile, DAD by Scott Amdler 2014. So there's a couple of things in particular I want you to take from this piece of history. First of all, these two things from Enterprise Architecture and Agile are pretty much the same sort of age. Any notion that somehow agile is the new kid on the block is actually not factually correct. You can see that histories are very similar. And in particular, by coincidence, 1995 happens to be Toga version 1 and the publication of Scrum. So these things are similar ages. But through most of this the development of these two things has been essentially separate. And that's because really they're looking at different fundamental challenges. Enterprise Architecture is really looking at that question of how do you tackle large-scale business change, business change affected by IT and doing all of those system design things that you need to do. And doing that by linking the IT change to your business strategy and then decomposing those large problems into smaller pieces that you can actually tackle and solve. And then how do you organize your solution development process to essentially reassemble all of those pieces back into one big overall solution. So it's that sort of at scale that's the key there. Agile methods have really looked at this question of uncertainty. How do we reduce uncertainty software development cycles by these ideas of the rapid learning and feedback cycles, short incremental development and the collaborative working in autonomous and multi-skill teams? And these two slightly different fundamental challenges really point the way to how we need to adapt these things if we want them to work together. Now you might ask why would I want them to work together? Why is that important? Why would I want to do that? And that's an excellent question and I'll come to that in the next slide. But just for a moment think about how we would adapt these things. From an enterprise architecture standpoint what you've got to be thinking about is how do I develop my architecture in an iterative way? And then from that architecture when I'm thinking about how I would govern the solution development doing that in continuous ways incrementally with the development of the solution development and very importantly prioritizing the delivery of the first working system components as soon as possible. So descending through the layers of architecture or through the design getting the first working system components out as soon as possible. And if I look at things from an Agile viewpoint then I need to accept the necessity of some design up front. Not big design up front but some design up front. And coming from that the architecture guardrails that you see commonly talked about in agile methods and trusting those guardrails they are there for a good reason they are there to help us succeed. So I mentioned the importance of adapting. Why do we need to do that? Well I think if we don't there are some very genuine risks. From an enterprise architecture standpoint there is a risk of building the wrong system. I don't have any doubt at all that by correctly executing all of the processes you will build a system that works. But it might not be quite the system as the end user really intended it. I'm sure a lot of us will have had those moments where you've got the business owner perhaps right in front of you and they'll say yeah okay I can see yes you can tick off all of the functional requirements I gave you but it's somehow not quite what I wanted. And I would also say there's a risk of irrelevance and don't use the word lightly irrelevance in digital transformation programs because unless we follow these agile approaches and doing these rapid iterative delivery we risk just simply things too slow because in digital transformation the emphasis is in responding to disruption or new market opportunity and so speed is the key and these agile methods gives us a way to get working results out more quickly. From an agile standpoint when we're talking about doing things at scale if we don't use some of these enterprise architecture techniques then there's a very real risk of integration failure with those large scale systems in particular where you've perhaps got multiple teams working on desperate aspects of the problems if you don't have those sort of overarching architectures those patterns and those principles that everybody needs to follow then there's a risk that those pieces just simply will not fit together. And another one is breaching non-functional requirements because when you're following a development essentially led by end user interactions by business owner interactions the focus very naturally tends to be on the functional behaviors the things that you see on the screen the buttons you click the reports are degenerated and sometimes it's rather too late in the development cycles that things like capacity come out oh by the way there could be a million of these things a day or oh by the way you need to be able to support 10,000 concurrent users and those come too late in the development cycles you can have a serious problem and broadly speaking these are the sorts of problems that emergent architecture alone can't solve so if I'm an architect what are the sorts of things I need to be considering as we go through these different stages of the architecture development while I'm developing the architecture itself while I'm in the architecture project the sorts of things I need to be thinking about are how am I dividing up the architecture into sprint size increments that I can deliver incrementally through the ADM cycles and of course TOGAF gives me some ways to do that straight out of the book very easy to see how by dividing the work up according to those domains of business data or application in technology or by the levels of strategic architecture segment capability that obviously gives me some very easy ways that I can divide that work up into chunks of work that I can deliver it effectively and as I mentioned before getting to that first TOGAF calls the capability level architecture the lowest level of architecture as soon as possible so that in turn I can get on to the parts of the solution development as soon as possible and be producing those first working components of the system showing the business owners the first working components showing some business value and of course starting those cycles of learning and feedback and when I'm then as an architect thinking about what sort of things do I need to be doing as we're working with the construction teams the build teams developing the solution then it's those things of building the architecture, setting the architecture guardrails, creating the runway and governing not through those sort of fixed stage gates, not by asking the development team to come to some big architecture board review in two months time but by continuous interactions working with the development teams on a much more continuous ongoing basis and doing things like joining possibly joining in some of those agile ceremonies as you go through the development process then when it comes to the operational end of the life cycle the sort of things I need to be thinking about as an architect when I'm thinking about the solution operation is how is this solution going to be agile in operation and in particular I'll single out functionality and capability and capacity so how do I make this solution agile to adapt to changes in functionality how do I introduce new functions or change functions and it's these sorts of concentrations that often lead you down the path of perhaps microservices architecture and that sort of thing and canary testing and all these sorts of things and how do I make it adaptable to capacity, how do I scale up how do I scale down and the techniques that there are in design and construction to enable easy changes of capacity so the good news is the open group is working on all of these things there is a Toga Fajal working group which has already published some things and continues to work it is very much a team effort new members always welcome as it says on the slide and seriously if you want to get involved if you want to contribute we would welcome you joining in these efforts the group leader is Richard Gnitski from full stack architecture if you google Richard Gnitski full stack architecture you will find him and if you are interested in joining then by all means get in touch with Richard he would welcome your contributions and as an example of some work in progress something that I've been working on myself I've been looking at the problem of agile documentation because although documentation is very much the output of what you are doing in architecture by making sure you do that in an agile way it sort of sets a certain cadence right through the whole approach and so like everything it is about developing the documentation incrementally and using tool sets that support collaboration and automation in what you are doing and finally don't forget the needs and access where you've got where you've got your documents stored in some sort of agile tool set or some DevOps tool chain that's great during the development program but think about how would I access that perhaps in five years time if I've now got some sort of archive copy of that database but the tool chain has moved on three or four major versions of software how sure am I I'll still be able to read that stuff in maybe five years time so think about perhaps exporting to proven stable file formats something like a PDF so I'll close out by saying there's already quite a lot of useful information in the Togov library about all of this there is a very good white paper using agile practices in enterprise architecture the core Togov standard documentation that's there now version 9.2 has an entire chapter on implying iterations to the ADN and there is the open agile architecture standard and these little codes I've put in bold on the slide here these are the document code numbers and if you go to the Togov library and put that in the search bar that's the quickest way to get to these documents happy to say there will be additional guidance published soon about about agile working things like I mentioned like MSA how to introduce new technologies and many other topics that are relevant to DX so embrace these new approaches and I would say be more Jedi and that isn't an appeal to some sort of mystical all-encompassing force that is just enough design in front because that's the real key of this agile approach doing just enough at each stage to enable the next step so embrace these new approaches be agile be more Jedi and with that Steve I will hand back to you Chris that's great stuff thank you very much for leading us through there there's lots in there and people will get the slides in the chat channel you'll be notified when the recordings and the presentation is available so thank you very much for that Chris we don't have loads of times for questions but we will take a couple of minutes if we can now the question come up in the chat about documentation and you mentioned it as needing some and the agile manifesto of course stresses the importance of working software over comprehensive documentation so what's can you kind of go back to the documentation point and say what's the your suggested approach on documentation here really said you need some yes that's right people often do point back to the agile manifesto and what it says there about valuing software over documentation of course that's entirely right because at the end of the day it is that working software you want but if you go on to read the agile manifesto it does acknowledge very clearly that there is value in things like the documentation and if you again if you read the history of the agile manifesto it does explain that it's not an anti-documentation thing so the trick is to always just do the minimum necessary to enable that next step that next iteration but do make sure you do that minimum because it's all too easy to kind of undershoot it's a tricky balance to strike but it always always that principle of doing just enough right thank you Chris one more quick question which is you've mentioned that Scrum goes back to kind of the same data as the first version of the TOGF standard we've heard a lot in recent years recent times about SAFE and here at the open group we've obviously had TOGF for a while now and it's being constantly maintained and updated and the open agile architecture standard you referred to so why are we working on those I think I know the answer but for the audience why are we working on those when we have Scrum and SAFE Scrum and SAFE are very excellent project control mechanisms quite generalized talking about how you organise your work and organise your people and even going right up to the sort of strategy side of things but they are not architecture methods so Scrum and SAFE both acknowledge the need for architecture but they do not tell you how to do it whereas by contrast for example TOGF is very rich in all of those things there are many many guides available that tell you how to do business architecture how to do application architecture and all of those things that are in the ADM cycle so it's really that slightly different emphasis that TOGF clearly and things like that OAA focus on architecture which are necessary and acknowledged in these other things like SAFE and Scrum but not covered in detail in things like SAFE and Scrum Well we'll leave it there Chris in the interest of time but again a warm welcome warm thank you for your presentation today and we will be making the slides available as well to answer a question in the chat I think somebody's already done that but for now we'll leave it there thank you very much Chris for us and right now before we wrap up folks we will move to another of our panel of experts Terry Blevins who if those of you who were present last time around on Toolkit Tuesday will have seen the first of Terry's Toolkit Tuesday tips so today we have the second so Terry Blevins from EnterpriseWise we will hear him talk about a highly valuable but often underutilized tool in the Enterprise Architects Toolkit business scenarios over to you Terry Hi my name is Terry Blevins with the Toolkit Tuesday tip so you have been asked to work on an Enterprise Architecture and you are wondering where I should start that's a great question and to be honest I have seen fail because this question didn't get the deserved attention up front well if you don't know the TOGAF standard has an excellent approach for addressing this it is called the business scenario method the business scenario method helps you understand where the organization is feeling the most pain so your work as an Enterprise Architect could be focused on real issues the business scenario method helps you and the organization itself get a better understanding of the high level requirements and constraints that need attention the method also helps you understand how to bring in the right people in the organization to pull out the real pain points and the ramifications of not dealing with those pain points getting development operations and management people together helps build trust generate a shared understanding of priorities and establish bridges that down the road will make it easier to implement change getting people on the same sheet of music usually does generate a better performance the business scenario method is used to generate insights and agreements of the desired outcomes and capabilities as well the method helps you understand the value chains involved and the value propositions facilitated by addressing the pain points all of the above adding up to a better understanding of the real no kidding requirements motivating the Enterprise architecture which will enable change within the Enterprise the business scenario method helps you provide the necessary Enterprise architecture capability of understanding real requirements which you can provide through a service delivery model by implementing the business scenario method your Enterprise architecture efforts will be dealing with the right issues of course for more information please check out the TOGAP Library keep architecting for Enterprise value thanks for watching thank you again Terry Blevins for that yes for more information about the business scenarios you can find that in the TOGAP Library at the open group website that is it for today folks for today's episode of Toolkit Tuesday please join us next time two weeks time when we'll be hearing about the seven levers or levers of digital transformation depending on your preferred pronunciation of the word the seven levers or levers of digital transformation it's a great we have a white paper on the topic presentation that you'll hear from Dave Hornford of Conexium so please join us two weeks today for the next episode of Toolkit Tuesday in the meantime keep well, keep safe and keep architecting for Enterprise value as Terry left us with that closing thought so we'll see you in two weeks meanwhile I'm Steve Nunn thank you for joining Toolkit Tuesday