that actually things like architecture and enterprise architecture in particular goes through this kind of seasonal type cycle. And I think I heard earlier, Steve sort of set me up and sort of stole the punchline. But the idea is we have these architectural winters and I think agility in particular is perhaps the latest of these. And that's going to kind of tee up why I think we need open standards still. So what do I mean by winters? Well, this is a picture that I kind of keep coming back to. I do keep threatening to turn it into something a bit more professional looking. But I think everybody keeps telling me they like the hand drawn kind of amateurishness of it because it kind of sums up really the spirit and the feel of it more. If I take a few minutes just to kind of fly through this in particular, what this is about is odd enough to have been involved in systems. I started working a company called Lucas Aerospace back in the 80s. They had computers then. So that was good. And I worked on a very bespoke point solution, handling repairs and spares. Around about that sort of time, people started connecting the computers up. And the problem was they realized that they didn't talk the same language and interoperability became an issue. And so enterprise architecture was born, the need for it was born. I think that's where the sun rose and we kind of all got warm in the idea that we needed to work out how to make all these things join up. And that's where the open group with its boundless information flow started to come on into that kind of thinking. I think things like packages, ERP, CRM, doesn't really matter what they're called, all started to come in and threaten as our kind of need. Do we need to be able to worry about what the data model is if it's already determined for us inside our ERP package, for example? But we quickly realized that all these ERP packages were written by different people. And guess what? They use different conventions, different naming conventions, different ways of connecting different frequencies and synchronization type techniques. So they left gaps and they clashed. So once again, EA came back out of a bit of a winter that we felt the warmth on our backs and we were important again. And then along came some integration solutions, everything from ESBs and the like to kind of actually how do we and Service Plus is kind of one of those particular areas. Everything could be plug and play with a term that some of us will remember. And again, we were forced into another winter, right? Why do you need to worry about enterprise architecture and end-to-end processes when it's all plugged in and you can just plug and play? Well, of course, what we found then harping back to Hollywood is that one ring doesn't rule them all. So that was the next sort of a sunrise that we felt where we felt the warmth come from the industry. And I think actually this sort of series of winters has caused a lot of the reason why the enterprise architecture community today still kind of has a lot of angst about its value, probably far more than a lot of other communities. But we're very keen to ensure that our value is present and I think it's probably because of these sorts of experiences. And then I think the most recent winter that we've experienced has probably been one of the deepest, certainly from what I've witnessed, where agile development projects, ways of building up using cloud technologies, containerization and microservices and proof of concept and things happening at great speed and not being able to do the kind of classic misnomer of a design up front, meant that we've kind of said EA is dead, we don't need it anymore. But what I've certainly found in the last couple of years is actually that great speed, that great agility, the creativity that's been unleashed has actually created an awful lot of interoperability challenges. And I'll kind of get into some of those on the next and final slide. But the point is all of those individual solutions are great, but we're back into that world of having, if you like, disjointed enterprises and disjointed ecosystems. So once again, we have the sun rising and enterprise architects can feel the sun in their back, but we are chastened by the need to be more agile, appropriate. So hence why I kind of underlined the word agile EA, meaning both enterprise architects are done in an agile way and being agile, appropriate. So just to kind of finish off and it is a whistle-stop reprise of the greatest hits, if you like, is, you know, we've emerged from this EA winter and architects have emerged and we have been chastened by it. We have an emphasis now on solutions and on outcomes. And a lot of that's been driven through design thinking and agile where we put the human, the end user, the person who is the consumer of our experience at the heart of things, not the process, not the technology. So that's it. That's goodness. I mean, and many people have always had that and championed that, but they can sit back and feel righteous now because, you know, that is really, really the kind of the primary focus around that requirement. They're also still, despite an awful lot of new kids on the block, a lot of large complex organizations that have spent an awful lot of money on it, you know, over the years, and they have big reputation. They have big reach and a big part of the play going forward still with that with, you know, massive amounts of data that they have the massive, you know, footprints and employment that they provide, etc.  And in fact, a lot of the new kids or relatively new have already grown to the point where they have scale as well. So I heard Randy mentioned Netflix in the earlier session. You know, they're the sort of people that are experiencing the same problems yet, you know, who'd have heard of Netflix 10 years ago, right? So, you know, the demand for professional architects is huge. I also heard earlier, you know, the 100,000 certified practitioner. That's fantastic. So, you know, and the numbers below around ageing, because they're always out of danger by the clock, of course. But we're seeing things like safe and the AD and other frameworks around agile, calling out the architect role as critical and vital to the success of the treatment of agile software delivery and agile business development. So, the point is, if you're doing a lot of agile stuff, if you're creating lots of minimum viable products, you know, if you're doing brief of concepts, if you're building these things in kind of garage techniques. Those are some people, other people silos, right? Those things create lots of great ideas and lots of great minimum products, but as you scale them and want to start to connect them. Unless you've got some connectivity type open standard, your interoperability is going to be a major challenge. So, the ability to be able to interoperate yourself is one thing. But the other side is the actual value changes that you have coming with new entrants coming across new sectors forming. I work with oil companies that are getting into electric vehicles. I work with, you know, vehicle companies that are getting into entertainment services, et cetera, et cetera. In other words, people are stepping across traditional value chain and they're interacting, they're collaborating themselves into new ecosystems. Those new ecosystems require multiple parties. Those multiple parties have to be able to communicate, they have to be able to exchange data, their workflows have to work end to end. That is business interoperability on steroids. That is huge interoperability and that needs to kind of continually modernize it, continually evolve and adapt. And that is actually something that is vital as we go forward. And we're seeing all those sort of emergent technologies around things like machine learning and whatever else actually supporting that. But that interoperability becomes even greater when you've got multiple parties and that's a new business model. So, we've got a necessity. We need a more agile architect approach that supports agile development. It is also more agile in its behavior. It can stand on the shoulders of established practice, good solid experience. There've been a lot of lessons learned and a lot of mistakes made and by I think I know I've made most of them. We don't, we shouldn't repeat them again. We can learn from those and build on them and use all the existing architectural knowledge that we have, but keep evolving as the industries in the business and everything else as well. So, one of the key parts is interoperability requires open standards both internally and intranally new work for you. So, that was my whistle stop wrap around all. Thank you. Thanks very much, Paul. It was always a pleasure and there's nothing wrong with dropping out the greatest hits. It's what the audience wants to hear. So, thank you for that. And we'll get to questions on the panel. So, moving right along next speaker on the topic of the new role of the architect, Mick Adams, associate partner at EY. Mick is part of EY's global architecture leadership team. He works in a variety of industries, including financial services, oil and gas in the public sector. Typically, Mick helps clients to solve challenging business issues with the help of technology. And Mick is the other co-chair with Paul of the Open Group Architecture Forum. So, good to you, Mick. Thanks, Steve, and good afternoon, everybody. Hope you're keeping safe. Yeah, just listening to Paul's presentation now that kind of triggered a few thoughts. I've been lucky enough to, over the last 20 years, have worked in most parts of the world in various architecture roles. So, I've done work in Asia Pacific, in Australia, New Zealand, Singapore, Thailand, Hong Kong. I've done work in India, Africa, Middle East, the Americas, and currently, I mean, Europe. And my first observation, just while I'm going to talk about what architects are doing, is that there's different paces of architecture work in effect currently. So, what's going on in North America is different to what's going on in Europe. It's different to what's going on in the Middle East. And the first point I'd like to make before I get into any slides is that as an architect or an architecture leader, you need to calibrate what your position is, depending on the culture of the organization or enterprise that you're actually working in. So, certainly working in Europe currently, the model is very much a kind of hybrid delivery of enterprise architecture type initiatives and large-scale solution architecture initiatives. We look down in kind of Australia, New Zealand. There's a lot of tool-based implementations trying to put together basic reference models where our organizations operate. Let me close it down for most of the audience, I think, on this call here. The North American market, certainly for the last 10 years, I've worked in there 50% of my time, has really been driven out by technology transformation. So, large-scale solution architecture work is being conductive rather than what I've called traditional enterprise architecture work. So, as I go through the various strands of what architects are doing, the new role of the architect, please bear in mind that I've synthesized up everything I know from an international perspective and presented that out here. So, I've identified a number of groups or there are a number of stakeholder groups with regards to architecture. First and foremost, the board or executive level of an organization, they want to know what to change to actually create value and mitigate risk depending on what they're seeing from a business environmental perspective. And the A response is very heavily loaded towards business architecture with regard to operating model design. There's a lot of work being conducted in various organizations that the architects are facilitating some of the time, some of the time they're giving insight, but ultimately the culmination of the work product is to create an operating model that's fit for purpose for the next five to ten years. The next area that's really kind of new and it's very, very prevalent in North America, sort of in the financial services area where I've worked, is the use of architecture to mitigate organizational risk, particularly with regards to cyber work. So, I was doing some work in a big financial service company in New York a few years ago. Basically, the team created a set of information assets, so it was an information centric architecture, and from that we did some subsequent threat modeling and scenario based planning with regards to cyber threats. And I've seen an increased amount of work globally to bring in cyber centric design thinking where I'll try to retrofit security architectures after transformations have been completed. Third area is technology innovation. I've got a stakeholder group there as a CTO, but that's basically technology leadership decision makers that are focused on deciding on what to bring into the enterprise from a technology perspective. Because there's so much information out there, it's become increasingly difficult for organizations to actually synthesize what could actually positively impact them. So, there is an increased use of application reference models, in part driven out by what I call partner ecosystems. So, companies like Poly can buy me a drink later. Companies like IBM are doing a great job in publishing kind of assets that can be used to view technology and how it can be incorporated into enterprise estates. Fourth area, which has been around in various forms over the last 10 years or so, is used for architecture to drive out commercially led procurements. Currently I'm engaged in one of the UK's largest public organizations on a multi-billion dollar project that will culminate in substantial spending in the marketplace. What is going on there is that we're helping the team come up with baseline cost models so that when procurement actually occurs, the client has a baseline by which to evaluate commercial responses. So, we've seen a lot of activity in that area. Tools frameworks, modeling languages like Archimage, Togaf, they really are geared up to actually get out good cost models. That's the first part of my presentation. One of my roles is as the co-chair of the architecture forum and we've had numerous conversations with regards to what to do next in the Togaf space that's going to create the most value. One of the items that we've discussed is the use of reference models in the business space. IT is becoming increasingly commoditized and the differentiation from a business perspective is becoming increasingly challenging. So, to have fleshed out just like we do in the IT perspective, the core capabilities that organizations use from a business capabilities perspective to have those written down in a standards-based form is very, very powerful and useful. So, there are a number of assets that are available. There has been shared between various organizations and a combination of decades worth of work that we're going to basically push out through the open group because we think it's perfectly the best forum in the world to actually create value for this type of work. A set of reference models to describe various market sectors. The first of which is a reference model for government and this is government in the broader sense and government operation in the broader sense. So, we've been doing some work over the last year or so to pull together what's effectively about 200 business capabilities that describe a government operation. We've used sources like the work that was conducted in India, Singapore, the US, EA, some work going on in New Zealand. Various reference models in Europe have been incorporated and synthesized to actually create a baseline model for government and we've also linked in the set of drivers from a business perspective that are affecting government transformation. So, hopefully over the next 6 to 12 months, you'll see that kind of published out and this will be the first step in creating a set of market-facing reference models for sectors such as banking, retail banking, investment banking, oil and gas could be upstream, downstream. We've already got work going on in the telco space so we may not leave that alone, but the CPG sector will be a good candidate. We've got basically quite a lot of material that we want to push through and I'll ask anybody that's interested and a member of the open group to get involved from a forum perspective. Basically put your hand up and start to contribute if you're interested. That's me done, hopefully that was interesting to you all. Steve. Thanks, Mick. Thank you. As I say, this will stop tour, but yes, keep any questions from Mick. Please put them in the Q&A channel and we'll get to them in the panel. Thanks once again, Mick, for your overview. Let's move to the next presenter, my colleague Sonja Gonzalez-Paredes, who is the architecture forum director for the open group and product manager for the Toga products. So Sonja has 20 years experience as a consultant in enterprise architecture, enterprise governance of IT and IT service management, information systems design and analysis, business process management, service oriented architecture and systematic innovation. And today Sonja is going to talk us through the open group architecture portfolio to face the new age. Welcome back, Sonja. Over to you. Okay. Thank you. Steve, can you all hear me? Yes. Okay. So thank you for that welcome. And thank you all you for attending this Toga user group. We have her great presentations all over today. So I'm going to wrap up a little bit showing how the open group and the architecture forum, the architecture portfolio, it's actually responding to that need to have this set of architecture portfolio standards to face the new age. So for first, I think it's something that it's important and has been discussed I think not only today, but also in the previous date. Right now everybody is talking about digital transformation and becoming digital. But at the end of the day, there's a certain kind of confusion in there. And I think one of the key messages is like it has to be one of the first priorities for the C level, not just a technology thing. So this is something like we cannot rely on in an internship like in this cartoon that we are showing up in here. So something that should be seen as an overview perspective of the enterprise. And right now, especially now with this situation, pandemic situation, we are facing now and now the need to be interconnected to give our services in a virtual way.  Sometimes you get points for doing that. Then you will receive an email confirming that your order is ready to be shipped. You will receive a WhatsApp message telling you that it's already available and you will send your location in case there's an express service for that. And even if there has been a mistake in your order, you will have the refund and your credit money again in your credit card. So all of this is possible to be done due to the old news technologies and all of the technologies but all the capabilities that are now available to fulfill this new digital world. So I have taken this drawing here from the Janie Ross. It's a very good book designed for digital. So I recommend you all to take a look at that book, St. Amerson. And she talks about digital strategy being beyond just being platform or beyond just going into the digitization of your information. So I particularly like this one because I think it summarized what we need to do. On one hand, you have the customer desire, the customer need that sometimes even not recognized and customers are not even aware they have that need. For example, Uber. Uber was created and people were not aware they may have that need but now it's a demand in the market. On the other hand, we have from the side of the company the need to design digital offering, getting this inspiration on new digital product and in the middle is the digital offering. So the capabilities that organization needs to deliver are handy and ready to be able to do this digital offering to the customer. And there are several topics in here and I think today and in the previous days of this virtual event some of these topics have been discussed and presented by our speakers. First, we need to have the customer inside, the customer experience. We need to know our customer what they need, what are their, the method they have and they may not have right now that may be in there and we should discover those needs. Having an outside in view is key in this. We need to be in the face of the customer, in the shoes of the customer to understand those needs and then it comes the innovation in this new digital offering, offering this new digital product. Of course, that implies other topics that are internally into the organization like the cultural shift. We need to change not only our platforms or technical platforms or services but also the way we serve our customer. For example, a customer representative is the first face of the customer now to have a good customer journey experience from a website, from a map or a mobile device is key now and that implies having new organizational maps. The way of working has changed now. It has to be more cross cutting different areas, functional areas and have these autonomous nodule teams that have also been mentioned before. And also to the couple and have more modular platforms to be able to fulfill that. We may have all these ready but if we don't have the proper digital platforms to fulfill this it would be very difficult to really deliver this value into the customer. So we can see something like this which is in a way trying to pick all different building blocks mentioned in the center. We have the customer with the good value proposition from that customer. Of course strategy which is one of the key elements that Enterprise Architects should support being available and there to support this level in proper strategic decision. The market trends, the competitors, everything that is outside in our ecosystem that is making an influence that need to make a shift in our business model and operational model which is in there. It defines our value stream, our business and organizational capabilities. To fulfill that is of course one key need now. And then to be sign this product and services that are now into the digital space and to be able to fulfill that with the proper technical and technological platform which is the other key piece in here. So what you will see in here is an holistic view of the organization. Therefore for those both of you that have been architects in the field will recognize this need to have this holistic view on organizational capabilities and there are others of course governances in there. We heard in one of the presentations earlier they need to have a guardrails and metrics to understand if we are really delivering value to the organization which is the final objective. The need to shift an organizational culture change is needed here otherwise it would be very difficult to introduce all these changes and to need to know how different organizational maps is also another key need to be able to really fulfill this. But coming back to the standards we see something like this and I put in this kind of like a puzzle on purpose because at the end of the day what we need to offer, what we offer has the open portfolio of standards is this kind of like a toolkit view in which for example if you need to construct your customer insight you may use the DP book which is the traditional body of knowledge which is a public standard. We also have certification available. We have a set of very interesting Toga series guides we share earlier the link to the file in which you will find all those set of Toga series guides. We also have the open business architecture standard mentioned earlier today which is also fulfilling that need to have this view of the customer. We also have the Azure architecture framework that was a snapshot that we published last year that now is working progress to also become a standard that has a lot to do with customer insight. Digital platforms again we have the DP book in there, Digital Strategy which is also connected with the Toga standard, OVA, the Toga series guide. IT for IT even though it's not exactly into the architecture portfolio it's part of the whole portfolio of open standards that we offer as open group. IT for IT we have a very nice presentation yesterday about how it could be used to deliver a value into the digital enterprise following the reference model and the different elements of the reference model and the digital business model again we have the DP book in there, the Toga series guide, operational models. They need to have metrics again comes to the standard with the Toga guide some metrics and also another very important topic that was mentioned earlier today the need and also Paul mentioned that I was talking about referred to the winters of enterprise architecture the need to have this ecosystem of partners to the third party external organization that we are connected with and if we don't have this partnership identify and recognize being able to communicate with them it would be very difficult and that's another beauty of benefit having open standards that you can communicate with your partners and your customers in this value change in a quicker in a more effective way if you are referring and using open standards and also open platforms. Also enterprise architects have to have a very key piece of this journey and of course the Toga standard as I'm going to refer now and I took this also for the Kajemini report that was also mentioned earlier today in one of the presentations that organizations now is more clear the need to have this holistic view that enterprise architect should provide to be able to understand all these complex systems and have a very clear view of these different interconnections that we have and now it's not only my organization it's also the ecosystem which I'm serving my customers and actually I found this quoting here which I have taken directly from the report that architects are increasingly involved in tactical and strategic transformation initiatives with 95% of respondents that in that they are a key contributor in the successful realization innovation efforts but our study also found out that enterprise architects must elevate their role by adopting agile value delivery and by becoming experts in new disruptive technologies and innovative thinking. I think this is a very powerful statement and I have to say that all the work that we are doing right now into the architecture forum and the architecture portfolio in general is precisely aimed to evolve the practice and the Toga standard to precisely cover those areas that are highlighted in this study which is we need to serve a digital enterprise to deliver EA in an agile way and supporting the agile enterprise and also to support innovation just another key element in there again coming back to Janey Rolls diagram in order to really be able to give a nice digital offering you need to innovate and you need to be ahead of your customer and be able to deliver products into the market that will create a need even though the customer is not even aware that they have that need. Now in terms of what we are doing into the architecture forum and into the architecture space have been said before the Toga standard is the factor standard for delivery enterprise architecture you have already seen on her from Andrew the numbers that we are handling right now in certification and the important milestone to be her reach recently so that talks about moral mode and the need and relevance of the standard in the market that's why we are working along with the members of the architecture forum improving these elements and features into the standard to precisely listen to the voice of the customer and deliver these new features into the standard so one of the more important pieces of work that we are working around is Toga standard and agile agile VA guidance we are going to have the next presentation precisely about that Toga standard supporting new technology trends that's a very important piece of work that is also under development right now into the architecture forum it's a very interesting model and how you can make an assessment of new technologies and realize if they are really a fit for your organization considering a series of factors and also the need to support the digital enterprise there's also another working group that is delivering guidance precisely to cover that specific point and the members the authors of the DPP are also part of that working group to be sure that we are providing consistency in that so this is another view of how we are connecting the different elements into the portfolio like I just mentioned Toga, agile VA there's a very interesting set of backlog topics in that delivery that is working progress into the forum the one that I mentioned the Toga standard supporting this digital enterprise we also have several joint activities into the architecture forum with other open group forums for example the IT for IT forum there's a very nice story that I hope you will soon see published which is about how you can use the IT for IT standard the Toga standard, the Archimate standard the DPP book and also elements of the agile architecture framework snapshot to precisely deliver value into a digital enterprise which is something that is key and trendy it's in the form of a storybook so you will find it very interesting that it's working progress also we have work around with Archimate standard how you can deliver both, use both of Archimate standards to deliver EA I think this is very relevant because also in another presentation earlier today we learned that relevance of having a good repository a good set of EA models and pools that are interconnected it's not anymore having this big upfront model that will be out of date very quickly it's having something dynamic and in order to do so you need to have the proper tooling in place and of course the proper modeling notation which in this case is fulfilled by the Archimate standard and also we have other interesting work around that the Serotrust architecture reference model which is also we talk about security on Monday there is also another activity along with the security forum to cover that need and another work around the token standard and microservice architecture and cloud which is another a key relevant topic that has been mentioned in the previous days and so we are also delivery guidance in that specific area as well this is the way that we are framing this so you will also see some improvements in the way we present this in our public website we have now this view of capabilities coming out of the token standard like again this view of this toolkit in which you can use different pieces of the standard I think we have also learned today that you don't have to use the token standard per the book to just use whatever you need and you adjust it and you use it along with other frameworks and epidemiologies so we have the fundamental content which is the one that you will find in token 9.2 and the separate series guide is working around providing guidance in other areas like agile information architecture is another key topic element into the forum activity reference models of our information architecture and data integration we have a very valuable set of business architecture guides we posted in the Q&A chat the link to the set of series guide they talk about business model information on map I'm sure you will find that very interesting also supporting different verticals and integration with other standards like IT for IT there is also another very interesting document especially if you are in the financial space how to use the token standard and the archemy standard along with the buy and reference model for banking that's a very interesting piece of work and we also provide the models which are delivery and archimage of course we are working around how a more practical application of this because people are asking okay very nice how do you do that so we are also working around having more case studies that should be able to provide you very soon in our open group library so this is what we are doing right now and again we are very keen now on keep a closer view of the market to understand more those customer needs and to listen the voice of the customer this is another example we are fulfilling this agile delivery view into the standard and we are going to go deeper into this because we have the next presentation to cover that but this is a way to how and I think someone mentioned that today on response to one of the questions that you can use for example the ADM, some faces of the ADM or all faces of the ADM depending on the approach for example to identify some high level user stories some epics for example to create your product back load if you are using also that agile methodology how this is Togaf ADM and Togaf has a standard and it has a practice come also support an agile delivery and that also has a consultant on supporting role into an agile initiative addressing especially interoperability which is one of the key topics you may have a very interesting agile delivery but if at the end of the day there are being delivered don't connect to each other and don't integrate at the end of the day you will have issues so that's another important element that you will find in the practice and into the Togaf standard and finally also supporting this I think we need to recognize that has every practice and every knowledge we need to evolve in time and so the role of the architect besides the important notes that Nick Adams just made about it is to become also the strategic support that always has been the role of the architect but now it's even more than ever for this quick decision taking innovation is another key area now for example using design thinking you will find by the way a very interesting blog in our open group blog channel that it's about their new role of the EA in the form of the story how to integrate different working teams different working groups which is also a very important topic in here a closer view on the product management not only having a project view but also a product view on the value that we are delivering governance following a more dynamic approach I guess like architect need to be present you may have seen in the Gemini study in all the different initiatives especially the ones that are about transformation and innovation and of course essential the ability to present this big picture and solve these concrete problems in complex environment the more complex your environment is the more you need enterprise architect to fulfill that and of course the role, the practice and the standard and whatever tool you are using is to be adapted to your partition specific situation, your needs your organization and culture and context and your maturity level so it's not a one side recipe you need to adapt that another task for the architect to be able to adapt the capability to fulfill this specific needs so this is what I have to today it has been clear what we are doing at the open group I need to also think some of the panelists are active members of the architecture forum so I want to thank you for all your contribution and work towards this and now back to you Steve for our next presenter Thank you Sonia, as you've conveyed it, there's a lot going on in many, many areas so thank you for that keep the questions coming in on the Q&A channel please folks I've seen there's a couple coming into the chat I've picked those up but please if you have questions do put them in the Q&A channel and we'll deal with them in a panel right after our final presentation of the day I'm delighted to introduce Chris Frost, the Deputy Head of IT Systems Technology Division and CTO of the Global Technology Group at Fujitsu Chris has worked for Fujitsu since 2005 in a variety of technical leadership roles Prior to his current position, Chris had been the CTO for various business units in Fujitsu, UK and Ireland on large outsourcing contracts for several Fujitsu customers he also sits on the governing board of the open group Today Chris will present the latest developments of how the two fit together within an overall framework of digital transformation so a warm welcome back from the open group Chris, I'll hand over to you Excellent, thank you very much Steve and I hope the audio is coming through loud and clear Thank you very much Okay, well hello everybody as Steve just said my name is Chris Frost and I'm with Fujitsu I'm going to talk about a piece of work that's been going on in the open group for the last few months looking at the very particular issue of how do you do agile delivery within the TOGA framework So I'm going to start off with actually something that I mentioned when I presented on this topic at the previous conference but it's a really important point architecture is vital for any large scale project and the need for that architecture doesn't disappear just because somehow the project is being delivered in sprints and if you want some proof of that, if you want some evidence of that just take a look at some of the popular frameworks that are out there for how to do agile at scale and you'll see they recognize the need for architecture and if you look into them you'll see terms like intentional architecture emergent architecture architecture runway so that need for architecture is clear but that shouldn't be taken to mean that nothing needs to change things do need to change and I think one of the important things that needs to change is this switch not doing the big design up front but just doing just enough architecture because you clearly need to do some architecture ahead of the construction of whatever system or solution it is you're doing and the picture of the leaning tower of Pisa on the left hand side there I think is a great example of why that is because I like to think that probably as the builders were starting to work on some of the upper levels of the tower there and it was starting to slump over I'd like to think that somebody at some point probably thought do you know what I wish we'd done a little bit more architecture work on the foundations of this tower but hey we live and learn and let's see what we can do with TOGAF in this modern agile delivery world as Sonja and others have already touched on earlier in this session there's already a number of bits of guidance from the open group in the open group library about agile in 2019 there was a white paper using agile practices in enterprise architecture then in the TOGAF standard itself actually chapter 18 of the main standard there's a piece about applying iterations to the ADM which while that's not the whole story of agile far from it it's nevertheless an important part and there's the agile architecture framework that's also been mentioned recently in this session which a snapshot was published well just about a year ago in July 2019 and work on that is continuing to develop into a new standard and where this piece of work fits in is that this guide that we're developing now adds further guidance which is specifically about the TOGAF standard and how that fits in with agile delivery so we have a TOGAF agile working group and I'm leading that group we started work early in 2020 a few months ago and the purpose was very simple to produce a TOGAF series guide on how the TOGAF standard can be adapted to agile working now the point we've got to right now is that we do have a draft guide it's currently going through an internal review process within the working group and as a matter of fact that's almost in real time as we speak because while I've been on this session I've been seeing two notifications coming in about people updating the GitLab repository as we're actually in the middle of this session so work is literally in progress right now on this and the next stage for that will be for an updated draft then to go forward into the next stage of review which is the company review at which point it goes out to members of wider review by members of the open group I hope that will happen within the next few weeks so for those of you on this call and I expect there's quite a few members of the open group and in the open group forum architecture forum you'll likely see this draft coming around on review very shortly I think it's also notable that in doing this we've used the modern agile tool set that's being used within the open group and some of the other things that are currently in progress that being based around GitLab to hold the repository of the documentation the document itself is written in ASCII Dock and we're using Slack as a means of communicating amongst team members email as well sometimes but Slack also is a great tool to communicate amongst members I do want to emphasize while I'm here that this has very much been a team effort I'm here talking about it as the leader of the group but it's far from one person's effort there's been a number of people volunteers from the member companies who've contributed to this I expect some of you are on the call now in fact I've seen from the chat messages that at least one other member of the team is on the call now so to team members who may be out there I'd just like to give my thanks and look forward to your contributions continuing in the future so I'm going to move on now to talk about some of the things that are in that draft guide and again coming back to a pointer made in an earlier presentation on this in the previous conference but it's such an important point Togath is not a waterfall thing there's nothing in the standard that defines a strict start to finish of the ADM phases there's nothing that says you have to do all of phase A before you start phase B and then all of phase B before you start phase C and so on yes you must start the phases in that order and that very obvious really I would think that you would have to start your business architecture before you could go on to do your information systems architecture in phase C and so on and so on and you must also finish the phases in that order and you can clearly see the risk if you thought you could finish your information systems architecture in phase C before you'd actually finish doing all the business architecture in phase B but within that the phases may overlap and may iterate so for example with the diagram in the slide there it's perfectly possible that you may do a little bit of work on perhaps the architect division in phase A then maybe do a little work to elaborate some of the business architecture then pass on to phase C information systems architecture file and then you might iterate back you might return back to do a little bit more business architecture and so on iterating between B and C so there's always been there within Togoff I'm sure many people have perhaps informally worked that way but it's worth saying because I still certainly hear sometimes people saying Togoff is waterfall it seems to be one of those enduring myths that's quite hard to get past now I've mentioned the draft guide a few times most of what's in it falls really within categories and on this slide I talk about the first of those and that is how you can apply the ADM in that sort of iterative sprint sized increments that's necessary to deliver in an agile way and so it described in the guide ways that you can divide up the architecture effort and that's largely by dividing it up into the different domains in this data application technology or in different levels the strategic architecture segment architecture capability architecture with the emphasis being on doing just enough architecture at each step to enable work to proceed then on the next phase or the next level whatever it might be and importantly to be able to gain as quickly as possible useful feedback because that point about getting rapid feedback goes really to the very heart of agile delivery so really you want to get as soon as possible to that first capability level architecture the lowest level architecture before you go into the actual design and solution construction activities get to that as soon as possible so that you can enable the downstream solution construction and also of course enable the feedback back into the future architecture increments and then thinking about governance, again a theme that's been taken up in a number of the other presentations today the style of governance needs to change it's something that's done more through continuous interactions not sort of periodic stage gates that you might do maybe architecture review boards on to months or have architecture reviews at certain key milestones of the project needs to move to a much much more continuous interaction the much more consulting and advisory type of role yes you need to set the guardrails sort of set some of the important constraints about how systems need to be developed and as architects you need to create that runway for the solution to be built but the emphasis is on this continuous interaction and not the sort of more more sort of periodic handoffs between architecture and construction so having said what's in the guide falls large into two categories this is the second of those categories on this slide and this is kind of almost looking the other way around this is looking at how some of the techniques that are popular from agile delivery and in particular from agile project management how some of these techniques can be useful within the ADM and some of the things we cover in the guide for example are design thinking great way to explore key design features and come up with innovative solutions very valuable in phase A for example jobs to be done analysis helps you sort of focus in on what the real need from the customer is by focusing on what is it what is the job the job that the customer is trying to do again usefully applied in phase A when you're trying to get to the what are the real requirements here business model canvas great way to identify the real key characteristics of a business proposition gotta be honest bit of a favorite of mine I've used it a few times very valuable in phase A really understand the business fundamentals of what you're doing okay all that subjectives and key results way of really defining the high level business objectives and the way that those will be measured and the targets associated with those that's probably something you do in phase A maybe B when you're doing the business architecture but interestingly these are they could also come back in later phases G and H when you're concerned with the implementation and change control because it's a way to just sort of cross checking back to make sure that the solution as you're implementing or changing and maintaining now is still consistent with the original business objectives that you set and then finally one of the things we talk about is the concept of architecture as code so that means things like actually using things like markup languages in fact just as we have done in the construction of this guide using things like ASCII dark or mermaid to describe diagrams using that to describe your architecture documents that the artifacts that you produce and that brings with it a number of benefits by using the same sort of tool sets then for your architecture that is being used later in the solution construction you can clearly see how that helps the dialogue right through the whole development effort and means that everybody's talking the same language and just makes it very easy then to talk between the architecture and construction activities that's generally applicable across all of the phases really so that's just a quick look at some of the things that are covered in the guide and I want to close off by really coming back to some of the points earlier and why are we doing this agile is undoubtedly king in the market certainly from where I sit in Fujitsu we see it very commonly in customer requests now new project proposals the need for agile delivery is everywhere and it's very clear to me and I hope to most people certainly on this call that doing these sorts of agile deliveries at scale needs architecture and we are perhaps very fortunate that in Togaf here in the open group we have the number one architecture framework and so a way to think about it is that this guide is going to help us learn how to apply all of these things that we've learned through some of those skills and experience that we've built up how do we apply those to agile projects and if you want to sort of take it right down to the what's in it for me question then a way to think about it is this is the way to keep your skills as architects and in particular perhaps as Togaf certified architects how to keep those relevant in today's agile delivery world and so to come right back and sort of almost complete a circle that was started in this session with Paul's presentation about the architecture winters in this case I'm pleased to say winter is not coming we are rising away from that winter and I think the future for enterprise architecture and Togaf is very much sunny and I think I'll finish on that point Steve and hand back to you for the panel session I think is next absolutely thank you very much Chris it's a great a great upbeat point to end any presentation on yes the future is bright so thank you again Chris it's a great great summary what's going on and thank you to you and the other members of the workgroup there and the effort that's gone in in quite a short space of time actually so we're going to get some great results from that so we now have a panel session with all of our speakers from the Togaf user group so if you could all be available I think I can see you all there I guess I can so those of you who want to use video please do if you're answering a question if that's going to strain things too much then stay hidden or if the lockdown look isn't what you want to share then stay hidden too please so first question and take you all back to your school days where you had a statement followed by the word discuss and I'm actually combining two statements that are coming from the same attendee today the first statement was agility and innovation is enabled by design not trial and error and he followed it up with EA is still largely focused on the system excuse me that's followed it up with 20 years ago we were focused on the significant cost of rework and the benefit of getting it right at the origin agile has elevated trial and error to an art form and we can no longer tell our business partners what they will get and when they will get it and how much it will cost anyone like to dive in on that one I'll I'll make a start on that one Steve I recognise a lot of the things that are written in the question and I think the I think the thing to focus on when we're sort of thinking about those trial and error cycles just think of it in terms of rapid feedback yes of course we want to minimise the amount of work we do on those things that won't eventually survive and that comes back to the point I made in the presentation about trying to do just enough up front just enough architecture and design and planning up front while still enabling that very rapid leap to the first delivery so that you can get into these feedback cycles as quickly as possible but yeah I do absolutely recognise what you mean around not having such a tight view of scope perhaps about what is it that will come what will be the final form of what will come out and where in the dollars but we're moving into a world I think where we're kind of adopting these rapid feedback cycles and time boxes as a way to scope what we're doing rather than that's an inevitable consequence of moving away from doing the sort of big design up front I would like to add to that I think that is also important to recognise that even though in many cases we need an agile approach it's not always the case so it will depend on the particular situation and I think there are certain variables that you need to consider for that for example complexity the more complex your environment the easier is the way that you will lose money if you go to watching to agile and the other was how willing is the company to risk how much money can you have available for experimenting that's the other one and again like supporting what Chris just said what is my minimal viable product so for example if you are working towards innovation you want to position new products you need to have shorter cycles and agile to experiment in knowing with the measure risk of course and allocated a certain budget to that it's not just doing it for the sake of doing it but on the other hand we use this example for a bank in a bank you usually innovate in the channels or in the face of the customer but sometimes you need to keep your legacy systems or your big platforms supporting in a more traditional way so I guess it depends on what you want to do and how willing are you to put some risk on some money or some resources in experimenting and I guess at the end of the day it's a best position in my view that's another role of the architect to be able to provide advice to the C level saying okay this is too risky to have an agile approach this is more appropriate for an agile approach yeah it's a Mickey I think to a certain extent victims are around success success I think one of the main challenges that we're seeing is that the expectation for from a client architecture stakeholders has exponentially increased and the ability of architects to kind of manage that scope with this way really kind of expanded universe of thinking with regards you know stakeholders has become a real real challenge and I think you know architects to a certain extent have got really manage expectations a little bit more robustly and used to where know a little bit more often with regards what they can and can actually do in a given timeframe I think one of the things I like to add my camera won't work I'm hiding my lockdown beard it doesn't seem to want to work the technology is keeping you safe from the pain of my beard but just to kind of answer the I think it's a fascinating area because for me architecture comes back to two words and whether solution architecture or architecture anything else you are looking for the viability and validation those two words are absolute magic ingredients for me so the first thing you're trying to do is what you're trying to build viable and can you validate that it's going to do what it needs to do when you put it out in the wild so those are the two things that you're fundamentally trying to do with you're an enterprise architect, solution architect any other form of architect so to me what agile allows you to do is when you've got lots of unknowns you can sort of chunk it up and try things out and you can sort of pivot back and you can try stuff out and you can do that that's great it works really well especially in functional areas so to kind of oversimplify if I want to show you something say do you want it to look like this do you want it to feel like this you can give me that feedback and we can quickly update it and go forward brilliant as soon as you get into non-functionals that gets a little bit harder I'm not saying it's not possible but we're tending to find what is the mean time between recovery mean for somebody to be built into how long they're willing for something to go out of business you can't trial and error mean time between recovery you know that is a requirement that you have to flesh out and then work out how are you going to address that especially if it's some kind of safety critical or brand critical or related environment so you've got to be able to have different things to the solution in different places I don't think things are all agile or all waterfall I think everything is in the mix of the two and that's why we need humans in the mix right exactly there's a comment come in while you've been talking in the chat that in a complex environment it can be hard to if you do everything up front it can be hard to deliver value in the short term and agile can help you decompose the problem a bit and pretty much what you were saying Paul you know it can help in a very complex environment but there's a place for each approach of course Steve have I made just one point because I can't pass up the opportunity for a shameless plug of the draft guide in fact one of the things that we do cover in one of the sections of the draft Togo agile guide is a discussion on choosing appropriate delivery methods because while it is a guide about agile delivery do recognize that it is not the only way to do things and it is right to consider what is the appropriate delivery style for a particular situation and it is one of the things we cover right excellent thank you Chris looking forward to that going through the process and getting published as a draft guide um question came in earlier you mentioned Mick in your in your talk about reference models and in particular starting with the government reference model question come in does the government reference model align to the US government federal enterprise architecture framework yes it does like all good architects myself and the team plagiarized very very heavily from the best of what was available out there in the world and the US model of thief as it's called we have incorporated the best parts of it and thrown out the things we didn't like basically which yeah so we've taken that approach so what you see is basically a bit of a kind of compromise so if you've been working on the fee in the US at federal level you know the introduction of a different reference model may not be that useful to you but the intent here is from an international perspective to get some consensus going with government operation so it'll security services for example can start to have a bit of a more uniform conversation with regards alignment of capabilities for example yeah okay yeah and I'll make a plug in particular for the work the India standard the work that's gone on there is really quite something in India and they've you know starting with Toghaf at the core and involved that into really quite a stunning piece of work and they've just the government of India has just released an agile version of it too so it's a great piece of work next question EA is still largely focused on the system side of the business system how do we get the business to recognize the need for process and data structure design as the starting point for technical development it's time to be followed by some comment yeah interesting one I think part of the problem might be there that it can be difficult to articulate exactly what the need is for some of these things like data structure design and these sorts of things I think the best way to do that the best way to do it actually is with simple example and just walk people through simple examples to illustrate what does this mean and why it's important and the sort of things that go wrong if you don't get it right yeah yeah I'd second that I think it's more a case of really demonstrating the value of architecture in practice rather than talking about the theory and what it could do yeah certainly a number of organizations have conducted large studies in the system integration world with thousands of projects and it's statistically demonstrable that the use of architecture techniques mitigates project delivery risk manifold so the argument is over with regards to the value that it can bring I think the challenge from a particular stakeholder conversation perspective is whether you want to sell to that person or actually do some good work for him and say oh yeah by the way we use some architecture tools and techniques okay let's see the question comes describes itself as slightly off topic but I'd say not really does the open group offer any avenues for mentoring new EAs especially around implementing the TOGAP standard mentoring is something we get asked about a long time and building teams I mean we certainly have published some great white papers on how to go about building the EA capability the world class EA series is a great one to go to that's available but I'll stop answering the question and let you guys do it okay Steve I would like to comment on this I think like it depends on how you take the question I guess for example one thing that we are keen on having and I mentioned this in this presentation is having examples and real case studies so and that is not always not also for our members is for the whole community for example any of the attendees is interested in sharing some information with us in the form of a case study or particular implementation we'll be more than happy to publish that we have done in the past so we only need to they only need to reach us and we'll be able to move forward because it's a very good way to show in value you know this is specific implementation of the standard in a real case situation that is something that we can decently do and support and you also mentioned that we have valuable content in the open library and the library that could also be around how you can implement in the standard as well so that's another interesting one also I'm not sure if we in a certain moment we can remigrate that but we used to have this kind of academic program in which we will connect with our academic members to precisely engage students in this in some kind of mentoring or work in progress from students and going precisely into the into the practice so those are things that of course can be done and I'm sure can support us. Yeah and certainly I remember mentoring has been a big topic over the years in the open professions certification side of things the open CA certification we used to have a certain number of mentoring mentoring partners because it was being a skills and experience based program rather than knowledge based program it was important that people had some guidance on how to follow that follow the right path and take the right boxes now we've helped a lot with the evolution of the program as Andrew mentioned earlier we now have it as milestones so it's easier it's an easier more straightforward path to walk down but still mentoring is important to you know to anyone's career so it's good to think about how we can do those things I don't know if you can hear me now Yes Oh okay so I was going to pick up on the previous point about mentoring being involved in the open professions, the open CA in particular one of the attributes of getting certified is being able to demonstrate your own giving, your contributions to your profession which includes mentoring of other people You can see that the virtuous circle built up in the open CA process itself because mentoring qualifies you to be able to apply for the next level up in terms of architecture credentials so to be a distinguished level open CA I can't remember the precise number but you have to demonstrate mentoring of several people so the professions part is very keen on it and it's useful to do so the best way if you want to find somebody to mentor you is to find somebody who is going through the open CA process and go through the association if I may That's right I was going to mention as well Paul that the association of enterprise architects is also a good source for mentors anyone who is certified is eligible to be a member of the you are invited to join without cost for I think two years now and the AA has a whole its whole reason for being is to build and help the professionalism of the discipline of architecture and there's some work going on there it's a great source for mentors and as you say Paul the open professions program has adopted it as a key part of what is required to get to the highest levels before I go on Paul did you want to I couldn't hear you before so maybe you had a comment on the previous it was just a lesson learned actually and I think it still applies so I still kind of wheel it out it's when I used to be the chief architect at Royal Mail Post Office in the UK I had to consider myself with business architecture something I picked up as an extended scope during my time there and I've got a lot of pushback from the business kind of saying your IT and etc etc the kind of thing that we all know alright and so I found the way forward was not to try and persuade them up front I think a bit like Mick was saying not to kind of try and win people over beforehand nor actually to try and tell them I knew their business what we actually did as a team was just hold a mirror up to the business and reflect what we saw and we captured it in architectural terms whether that be processes or information however you want to say it we held the mirror up reflected what we saw and we used that to help the design of the technical solutions and we went to the business and said this is what we see we are very likely to have seen it wrong because you're the expert but bear in mind if you don't help us develop this and improve it we will build the systems that support the wrong vision so it's in your interest to correct it and that approach actually kind of just worked really well because we weren't trying to be the experts we were just literally reflecting holding a mirror up to the business so that we could design our systems that's proven positive many many times since yeah I bet it's a good thought and that thought unless anyone has anything to add we are going to draw a line under the session we are at the end of our time for today and I know some people are dealing with very early mornings or extremely late nights but hearing nothing and seeing nothing I will draw a line under it thank you to each of our panellists and presenters today really big I wish we had you could hear the round of applause but I'm sure it would be deafening but thank you for joining us and thanks for saving us from the beard pool we will leave it there so just to wrap up thank you all for attending today thank you for your questions and it's been a great three days today itself has been wonderful to see the interest and please keep the tweets going at hashtag OG virtual as we have done the last couple of days we will leave the chat channel here open for maybe five minutes after we formally close in case you want to give us any feedback or say hi to the other attendees we still have a lot of people still on here and thank you for sticking with us we're delighted that you did and you chose to spend your time here please keep active keep looking out for the architecture products so they're coming out of the open group and stay safe and keep healthy and sane and we will see you all very soon that's again thank you Steve bye bye everyone