 I'll save some time when I can. It's a pleasure to introduce our next speaker from IBM. Paddy Fagan is a senior technical staff member and chief architect for Watson Care Manager and the application framework at IBM Watson Health. He's an expert in the architecture and design of enterprise business applications and has worked across software as a service and on-premises solutions in healthcare and government for over 20 years and today Paddy's going to talk to us about a standard that we see as very important and an important part of the whole framework of digital standards, the open agile architecture standard. So warm, virtual welcome from the open group for Paddy Fagan. Welcome, sir. Steve and everyone else, good afternoon or good morning, possibly good evening, depending on where you are. I'm going to start again. We have people here, Paddy, for whom it's already Wednesday in Japan. So welcome. Good Lord, welcome from the future. Listen, thank you very much, Steve. And as Steve said, I'm going to talk a little bit about open agile architecture and how that sort of interlocks, I guess, with the digital first enterprise. Very briefly, as Steve said, my name is Paddy Fagan and I'm an STSM working in IBM Watson Health. I've been around enterprise applications for about, well, almost 25 years at this stage. So I kind of a lot of history to draw on, but hopefully that is the help rather than the hindrance in this. But yeah, so let's get on. And as ever, when I speak at these kind of events, I note that I'm Irish and I speak quite quickly. So if I am speaking too fast and people can't hear me, please just raise your hand or put a note in the chat and we'll see it and I'll slow down, I promise. I'm going to talk today about a couple of key topics around the OAA. I'm going to talk a little bit about what the OAA is itself, which hopefully is an introduction that might be useful. And then sort of expand on sort of two of the key topics within it, really that division between what the enterprise does and also what the enterprise is. So in that, you know, it's going to draw it on that distinction. It's one of the key sort of distinctions we document in the OAA and we feel it's important to this and how it fits in with things. And hopefully in drawing out that distinction, I can also sort of draw on those two topics and draw in a little bit more. And I am going to note the picture that's on the left-most edge of this diagram shows sort of two hands drawing each other with pencils. Now, ignoring for a moment the impossibility of such a drawing. And I guess the thing that's kind of key in this is a theme that runs through the OAA. And that's one of a digital enterprise and an agile enterprise being kind of co-linked. And I guess in our minds and from the perspective of the OAA, if you want one, you're going to end up with the other. Now, I'd argue that's not a bad thing, but I guess, you know, it raised that question of an organization approaching this and thinking that what they're doing is a digital transformation and finding themselves thrust into an agile transformation or vice versa. And I guess maybe that insight, therefore, is useful to people in terms of, you know, highlighting that the two are co-linked. And so when you start down the journey of one, you should expect to draw some of the other in. So onwards to what is the OAA. So the open agile architecture standard, long phraseology, but there you go, covers the digital transformation of the enterprise together with the agile transformation. So back to those two hands, right? And that's a key concept in what we're trying to address here because we believe in order to address one, we have to address the two. It's broken down internally into a sort of an OAA core, which covers the concepts and the structure, and then goes on to why you need this dual transformation, why attempting to do one without the other is going to generate issues and constraints. And then we have the OAA building blocks in the later sections of the document, which really develop on those key topics and structures and provide a lot more detail and some examples and various constructs, I suppose, to bring them to life, hopefully. It includes concepts or content from the perspective of what the enterprise does. So, you know, that's about product design or journey mapping to what the enterprise is, which is, you know, the project product architecture, the operations architecture. Indeed, your organizational structure or architecture, it might be. And I guess, you know, again, those distinctions sometimes feel a little artificial, but they're also kind of key to what we're trying to drive at here. And I suppose, I guess, you know, the key thing I would draw out is if we think about looking back up this slide across those divisions between what the organization is and what it does, the distinction between a digital transformation and an agile transformation, you need to take on all of these things or at least elements of all of them in our minds to be successful. And that's what we hopefully draw together in the OAA. So, hopefully with that introduction, having made some sense and let me move onwards. So, I'm going to talk briefly about what the organization... Sorry, I confused myself. What the organization does, apologies. And I guess, you know, at the key level, right, what we're talking about here is architecting the enterprise to innovate at speed and scale, right? And I guess what we're, you know, driving out here is to say that if you're going to undergo a digital transformation or in the throes of a digital transformation, you need to get to that innovation at speed and scale. And I guess a lot of this in some ways that I didn't quite expect interlocks with what Dave was saying as I joined the call, right? There's a lot of these kinds of things that we're talking about here are very much part of what Dave described in the way that the open groups kind of change how some of the standards are developed and delivered, right? But there are other elements to this that affect, you know, how the organization does things. It's about learning at scale. It's about architecting products for faster innovation or fast innovation. And it's about an operating model at scales. And I guess, you know, those two things together become particularly important when we start to talk about, you know, internet delivered or SaaS applications. And both the architecture and the operating model have to align to allow you to innovate quickly. And I guess, you know, the heart of digital is quick innovation. And so this becomes very much part of that. And you then have modular software systems. And again, I guess, you know, relating back to Dave's commentary in terms of breaking things down so that individual pieces can evolve more rapidly and that we can provide, you know, that faster route to feedback at an organizational level as well, it becomes important. And then the final one here is what's called an inverse Conway to shape the organization. So the Conway's law is an architectural or software law. Of course, none of these are, you know, written in statutes anywhere. That says that your organization structure will influence or inform your solution architecture or software architecture. And I guess what inverse Conway talks to is to say, well, if that's true and we believe it does, and I think we've all hopefully everybody on this call has lived examples where that has written through. Said, well, if I can control what my organization does in terms of how it's structured, well then perhaps I can organize my organization to generate the architecture I want. And it feels a little bit like the techies trying to take over the enterprise. But hopefully that, you know, makes some sense and resonates with people in terms of that understanding. I've talked in a little bit more detail about a few of these topics in the slides that follow. And so let me move on. And I guess the first one of these is, you know, bold learning at scale, right? And what we're trying to drive here is, you know, one of iterative innovation that allows us to, you know, do some research, do some product discovery, ideate it, test and learn from that and iterate on that. And refine very quickly, you know, up the slope of addressing more and more needs and iterating across solution ideas so that we drive to something that has the right value proposition and has the right product features. And as the killer UI, I guess, you know, you can all define that as you see fit. But what you want to be able to do is iterate on that process, not to sit in a darkened conference room or a darkened WebEx or whatever it might be these days and say, we're going to build the killer product for this market. It's going to do A, B, C, D, E and F. Never look outside of the room, go build that and see what happens. Rather, you know, we take the idea, we play it back to people, we show them, you know, whether it's mock-ups or whatever sort of presentation of it to show them what it might look like. We get their feedback, we iterate on that. We produce another iteration and we repeat that multiple times. And in doing that, we generate something with a much stronger value proposition with much better set of features and with a better killer UI or MVP key product characteristics. And I guess, you know, this is about, you know, the organization being willing to learn like this and being party to learn like this, but also being, you know, brought into it, right? And I guess, you know, part of what we all do is to shape organizational thinking as well as solutions and software and everything else. And so this is very much part of the process in our mind and it's one of the tenets, as I said, of the document. If I move on to the next slide and this talks about an operating model at scales and I guess, you know, if we think about this, we've got at the very left hand side here some fairly well understood blocks, right? You've got product architecture and I hope sort of for the sort of audience we're talking to, that makes a lot of sense in terms of what you might have in there. But you also have an agile strategy about how you want to be agile and how you want that agility to take form. And those two together sort of drive your operational objectives. You're okay, or is about how you want your organization to change or evolve or what you wanted to deliver. And then you have that operationalization of it, right? And those are, you know, journeys and value stream processes that sort of run across the top. But you also have people, employees who are probably a very key part of this, you've automation and that automation may be, you know, software automation, CICD pipelines or other components. But it could also be mechanical automation depending on what your organization produces, right? And you've got assets and those assets might be, you know, manuals or documents or standards in the case of death. The open group as Dave talked about, but they could be other things as well, right? They may be internal documents about how things are done or how processes run or how about refinements that might be made or could be made or whatever. And then at the end of that, you've got these operational outcomes, hopefully leading, you know, to product outcomes and the delighted client at the end, but also feeding that, you know, that circle back into the product architecture, into the improvements and redesigning the operations that let you iterate on this model and evolve in an agile way. And I guess that's the other, you know, key piece of this is that agility in the process. So if I jump on, I guess we're going to talk in the next section about what the enterprise is. And so here we have first up the inverse convoy. And so, you know, this is this idea that by organizing our organization, I'll phrase that terribly, but bear with me. And in a way that drives the agile transformation, like so that working teams are aligned to streams of delivery, right? If you've got business value arriving from this solution or component or product or whatever it is, well, then there should be a team aligned around delivering that and that the, you know, the architectural structure should work back from that. There will still always, of course, be what are described here as platform teams, teams who provide core features that are used throughout the organization or by multiple streams or value proposition, but equally, you know, that the focus should be around a shared purpose, shared consciousness, and then forcing functions. And I guess the key with those forcing functions that often in order to achieve organization will change, there has to be some, you know, I don't quite know what to, something to rub it up against in order to drive the friction into the organization to force it to change, right? Most organizations are typically not going to change very much unless something happens to force that change. And these forcing functions may be, you know, delivery deadlines, they may be organized statements about requirements, they may be, you know, changes to reporting lines or whatever it is, but there has to be some function that actually forces that change within the organization. And obviously that doesn't rule out, you know, having competency-based teams, right? So if you've got expertise in a user interface technology or in a backend technology or in, you know, some AI tooling or whatever it is, there's going to be teams who are competent in those technologies and they're going to deliver into different stream-aligned teams. But that doesn't mean, you know, barring that particular competency-based delivery, you don't have teams aligned around the delivery. And okay. And then I guess a little bit more on what the organization does. And I think this is probably not something that's going to be novel or different, but maybe a different way of looking at things you already see, right? If we think about how an organization plans and understands its activity, right? That might be a large organization as a whole or it might be one of those, you know, focus streams that we talked about on the last slide in terms of the inverse common way. Well, there are or there should be a number of things that influence their activities. There are constraints, right? There are perhaps a limited number of resources and a limited deadline, but there may be other constraints on that team or organization or group. And I guess the key here is to drive that they be documented and agreed, right? You know, everybody has constraints. It's not about trying to remove them, but it is about making sure that they're well understood, that the team themselves understand where the constraints are and what their, you know, span of control is. But also so that everybody who's interacting with them or has expectations of what they will deliver understand those constraints and how they affect what they may or may not see at the end of this because that's really important. You know, success is defined not just by the team working really hard, but by delivering what the business expects of it. And if there's a constraint that's going to stop that when you want that written down at the beginning so everybody can go on and hang on, that's not going to work for us and we need to find a way to modify the constraint. And fitness functions, I guess, are really important, again, something we talk a lot about in the OAA. They're objective, typically executable, tests for non-functional requirements, right? You would take it as given that there are executional tests for functional requirements. If we need to have a product that displays a screen that puts up the following fields, we should have some tests that enforce that, okay, not everybody in the software industry does those things, but by and large, I think everybody would accept you should. If we're going to produce a car, we should check that there are four wheels on it and they don't fall off and all of the other functional tests you should apply. But fitness functions are that objective, executable form of the non-functional testing about system performance or scalability within fixed resource or other non-functional characteristics, be they safety or anything else. And I guess the important thing here is making sure that those are objectively constructed, but also executable, so they can be validated at every point. And I guess the reason that's so important in my mind is that that's another driver to agility. If those things are encoded and executable, you're free to modify things and make changes, whether that's code changes or structural changes or deployment changes or whatever it might be, because you know that if you're going to break one of these fitness functions, you will be informed of that very quickly by this test failing. Whereas if these things are not tested, you get that environment of fear that stifles the agility, you know, because you can't necessarily make change because you're driven out of making the change by the fear that you'll break something that you've no way to validate. And then guardrails are really about a lightweight governance process. And I guess the key here I would say is that about empowering everybody to make decisions which are within their span of control. And the guardrails are almost a way of pointing that out to people, right? You are going to tell them also, you know, where they do need to go and ask more people for permission or for approvals or whatever. But largely what you're trying to do is drive out to people that, you know, you do have this span of control and encouraging them to make the very best possible use of that to solve the problems in the best way possible. And then finally in this section, I'm going to just talk a little bit about the right environment. And I guess from my mind, you know, the right environment is technical, right? So this technical characteristics again, a lot of these sort of resonate back with some of the things Dave was talking about, continuous delivery, feature toggles, the ability to switch features on and off without re-releasing software, you know, a key driver in terms of saying, well, we can't afford to put the feature out even if we're only 80% sure it's going to work. And, you know, we can switch it back off again. And then componentisation, that ability to break things down into smaller parts and to evolve each one independently. On the non-technical side, we've got ongoing architectural refactoring, which hopefully sort of speaks for itself. And I guess an architectural roadmap, right? That ability to say, you know, from the get-go, not that we're going to do all these things, but rather to have a guiding star, something that says, yes, this is the direction we're going to take and how it's going to evolve. Yes, tomorrow we might learn something new or we may face a new business requirement in that iterative world that changes that. But we can always change it, but you should always know where you're going even if you know that maybe ultimately we won't end up there. And then we talk about, you know, progressive transformation, the ability to iteratively evolve the architecture and your organising, you know, all of your other elements as you iterate through your product. And then the inverse convey, which we've talked about as well. So then, very finally, just because I know yesterday's session talked a little bit about COP26 and sustainability, I wanted to talk about this briefly. And I think in my mind at least, you know, as this applies to the OAA, we'll probably be more generally. There's really two key topics here, I think. One is the greening of IT, right? And that is using IT just to do things more efficiently in the IT system itself, right? So whether that's using more efficient resources and that's maybe moving out of a dedicated data centre to cloud hosted services where, you know, those cloud hosted services use computation, hence power and water resources much more efficiently. But also driving to use IT resources more efficiently. And I guess what I'm driving at here is the idea that if we design a new system or evolve a system or whatever it is, in doing that we may get more insight into how it's using resources. And again, taking the cloud consumption model as a good one, potentially moving from an on-premise environment where you can just see how much energy is being used by the thing as a whole, where you're using cloud resources, you're probably getting itemised billing for services consumed, disk storage, CPU and other API calls and things like that. You can drive the ability to use those things much more efficiently, which of course means you should be using less energy and so on. But then the other track of this is the greening by IT, which is providing people with IT solutions that drive more efficient use of resources in real life. So maybe that's about providing people with digital tools that help them better plan their journeys and make better use of public transport or whether it's about digital tools that help people avoid having to travel to do whatever it was and they can do it remotely and digitally and hence do it significantly more efficiently. I have a link embedded there. It's a Google sponsored, I guess is the right word, course about sustainable IT decoded. It takes a couple of hours to complete. It's not terribly long. Kind of interesting talks on these topics and talks and a few others, which I think it really kind of brings the green agenda into this, which I think is kind of important and hopefully sort of helps bring perhaps some of these to life in a way that can drive adoption in organizations and other perspective where otherwise this might be just seen as an IT type project. Okay, that's kind of me. So I'm going to stop talking and see if there's questions. I saw a few flash by. Thank you, Patty. Great great job. I know it's a lot to cover and I love the fact that you added the sustainability piece at the end there to tie into yesterday that was really interesting stuff. So one of the things you may have seen flash by was a comment from somebody very involved in creating the OAA, Frederick Lee, in the next version his suggestion is changing the term agile strategy to digital strategy. What do you think of that? It's an interesting topic. Hello, Frederick. By the way, I haven't talked to you in some time of late. Certainly something we're considering and we are in fact, as Steve knows, actively making some changes at the moment trying to get an update together over the next little while and so what I will do is I'll take the terminology change back. It's interesting because in talking to some other collaborators recently there's a dividing line there where I think some people in their day jobs or their normal life, whatever that makes about this one, but anyway consider digital to be a slightly focused statement and agile is a bit broader and then there's others for whom digital is that broad statement and agile actually suggests engineering and development practices. And so I think there's a real tension there. I'm not sure what we're actually going to do, I guess, but I'll certainly take the feedback on board and it is something that's very much at the forefront of our minds because I think one of the things I think we do feel about the way the OAA is structured right now is that there are some assumptions coded into it about our mental model for how these terms fit together and they don't necessarily match with everybody's experience. So we are going to try and make it a bit more accessible and open up some of that terminology. Thanks, Paddy. Good stuff. I think, well, we might come back to that one on the panel later on as well because I think there'll be some, as you say, some diverse views on that one possibly. But I think it is one of the challenges with the digital term is it's as with many other key terms it means different things to different people and it can be that very all-encompassing thing or or something much narrower. So nice one there. So another question. Is there any checklist for efficient IT resource or standard for it or anything like that? So it's an interesting question and I am a better million miles from an expert. I've done a little bit of reading recently because a collaborator brought it up as we were working on the updates to the OAA. There are international measures for efficiency. But the challenge with them is that they're often focused at the cloud or IT hardware providers. So they are about how many kilowatt hours are consumed per mips of available compute resources. And that's really good if you want to compare Google to Microsoft to AWS or whatever. But it's not so good for saying, well Patty's business application that has the following features and uses N, Kubernetes cubes and X amount of this API call. How efficient is that running on this cloud versus that cloud? It is quite hard to get those things down and in talking to some of my colleagues and collaborators the best thing that we've defined at this point, which is probably a little unfair, but I would argue it's probably the best available guidance is to say that if Amazon or Google or your cloud provider are charging you more money for something over something else, it is likely that the cheaper object is more efficient. And therefore if you can drive down based on cost, it is likely that you are driving down based on energy consumption as well. Interesting. We'll take one more question now Patty and then we'll move on. You talked made several references in your presentation to different teams different types of teams and some organizations are obviously very small and may not have lots of people to go on different teams. So the question is actually can you speak a bit to the applicability of the open agile architecture standard to smaller organizations? Sure, in fact I started my career in a very small organization so I've been there and done that and I guess what I'd argue is you know I think where I've said teams we could say role or responsibility and I guess what I would argue is even if there's two people in a room there is some division of roles and responsibilities between them and that's where this kind of thing still becomes important because you've got to make sure that the division makes sense and is giving you the outcomes you want even if there's only two of you but also that you've covered all the bases because it's very easy in smaller organizations in particular in my experience where you're reliant on that experience of those handful of key people effectively you make up your organization and if their experience doesn't encompass all of the domains you've got to cover well then you're likely to get a gap and that's hopefully where things like OAA and other standards help you look at your organization small as it may be in that you know through those lenses and say well now hang on we do have a gap here and one of us or whoever many you are needs to take responsibility for this piece of the puzzle as well or else we will call short I like that think of it as roles yeah so so you could potentially have people playing more than one role or wearing more than one hat they just have to remember which hat they're wearing at the time I guess yeah interesting interesting okay Paddy well we'll see you back on the panel for some more some more insights but meanwhile thank you virtual round of applause for Paddy Fagan thanks Paddy