 Paddy is STSM Chief Architect of Watson Care Manager Development at IBM Watson Health. He's an expert in the architecture and design of enterprise business applications, working across software as a service and on-premise solutions in healthcare and government. Paddy will use the software as a service offering example to illustrate how the open agile architecture practices such as continuous architectural refactoring can guide and as a service transformation. And please let's go to play Paddy's video and keep those questions coming in for the panel. Hi, I'm Paddy Fagan from IBM Watson Health. I'm going to talk about our experience creating a SaaS offering and how the practices we put into place helped us in doing that and the challenges we faced and how those map onto what we've described in the open agile architecture. And hopefully, you know, by illustrating this with an example, it kind of helps put it in context for people. Obviously, you know, there's a challenge here in that my example is not your example. But hopefully by talking through it, there's something of my example that will be helpful to you and sort of use something you can recognize in that. So, one day, some time ago, my VP asked us the questions. He said, how about we take our large monolithic application and make a subset of the features available to smaller customers? Now, that's not a question. That's not a surprise. Anybody who's familiar with dealing with these kind of situations will be used to that and will recognize in that world they're used to. And obviously, there's also someone knowns in there. You know, what's a smaller customer? Well, we're not really sure yet we figured that out kind of questions. And there were, of course, unfortunately for us, other questions as well. So, you know, it needed to be available as a service with low hosting costs. It needed to be in production really fast because it was competitors. It needed to have deep functional value because that was really important for the marketplace. It needed to be suitable for our HIPAA data and GDPR and EU. Consequent with that are all sorts of risks to the organization about fines and imprisonment for various executives and so on, none of which anybody wants to entertain. And it needs to align with our internal compliance rules. And again, I guess, recognizing that in large organizations, that's really important as well. But there's one thing about the externally defined rules, but there's another about the internally defined rules and we've got to be part of that as well. And now, again, not surprising anybody who's used to these kind of conversations. There was a final question. When can I have it? And we were cautiously or not so cautiously reminded that the correct answer was yesterday failing that as soon as possible. But, you know, these are the reasons why we're here and the things we get to take on. So there's this challenge in a good sense in this too. And I guess, you know, what I will say is that that's my story. Your story will be different. It won't necessarily be a VP. It'll be some other business owner. It won't necessarily be about taking monolithic applications to us as a service offerings. It'll be about something else. However, I think there's an element of that exchange, which probably hopefully at least resonates with you, with a lot of you, which represents, you know, a lot of people's experience in getting faced with these kind of questions and having to respond to it and what you do. And I guess what we're trying to bring out here today is some of the things that we've described in the open agile architecture and how they relate to what we did and how we made a success of what we did. Another way of describing of this is our experience of continuous architectural refactoring. And I guess, you know, there's almost a step zero before I continue, which says, given what we were asked for, what we were told, the obvious, you know, a thing to draw from that was that we couldn't design our architecture implemented and then bring it to the market. There really wasn't time for that. So what we had to do is set ourselves up for a world where we came to the market with an architecture and we evolved it and then it was about how do we manage that and what were the prerequisites, but also how do we set ourselves up so that we didn't trip over ourselves and moving forward. So let's get on to that a little bit. So mirroring the structure of the open agile architecture document. The first thing we looked at was was planning and understanding and reading in that, you know, it's about constraints and constraints are well obviously the list of things that we were granted on the first day from our VP. And but also, and it's about documenting and agree post excuse me, and which are really important because what you want to do there is make sure that all of your stakeholders understand those constraints and accept them, because one of the biggest things that we've seen go wrong in our experience is where constraints are misunderstood or misaligned and stakeholders have expectations that people feel they can't meet because of constraints. And, you know, from resiliency and words talk about come up with the limits and constraints within within which you work to ratify these your stakeholders and to me that's the key here right it's not just about, you know, everybody knows that we have to do X or we can't do it by it's about writing that down and getting everybody bought into that from the get go and fitness functions. Really powerful part of this from our experience about getting those really executable tests for non functional requirements and that ability to know that at any one point in time, our non functionals are satisfied because these fitness functions are passing. And you may decide that you know we'll live with breaking one of them for a while but you do that in a knowledgeable way based on an understanding of what the value is what it should be and what you're choosing to do for how long and why. And the final pieces guard as and that's really about lightweight governance right it's about empowering the individual groups teams architects, whoever they are depending on the scale of your organization your project to do things to make decisions and to move forward with the minimum of oversight but they need oversight they need to make the right decisions in the right context and they need to understand all of those things. And, but, but you don't want everybody to be involved in all the decisions or you're going to tie yourselves in a million different knots and I guess we've got a lot you're trying to say is, here's things that we are assuming you're going to do is quite the right word, but we expect you to do. If you're doing the things we expect you to do you document that you're doing that and you proceed. If you hit a point where you can't do one of the things we expect because of some constraint that you're facing, then come and talk to us explain the constraint you're facing the decisions you've made and what you've chosen to do. And we'll figure it out right we'll either go yeah you're right or we go no we don't think you should really do it that way or we'll amend the constraints or whatever it might be but you know those things are really important right because they're. They're that double age thing right by stating what you can do you empower people to do it, rather than stating what they can't do which tends to disempower people and that's really in my mind at least the way guardrails, you know can and should be structured for success. So moving on from that initial phase of figuring out what you're going to do and what sort of parameters you're going to place on it. We're not creating the right technical environment and I guess this is where a lot of us, you know, hit our stride this is a sort of a pitch we're very used to the sort of thing that we're very used to doing in our day to day lives or businesses. You know, for us in this kind of world continuous architectural factoring, you know, open agile style, there's really a couple of key things here like continuous delivery, being able to release everything all the time. It's really easy to say it's not so easy to live it. If you live it from the start and it becomes part of what you do the DNA of your project, then it just is and it works and it's there. The problem with it is sometimes it can be very easy to go well it's actually kind of hard to do that right now we'll just throw that for a little bit and suddenly it slips and it slides and it never quite comes back and that's a real challenge but it's something that has to be part of that and certainly from our experience it really does feature toggles, you know, that ability to switch things off switch things off because they don't work and you want to roll them back switch them off because the performance management and, you know, complications have come up and you need to change the system characteristics system, switch things off because you've got service related problems be it circle breakers or whatever else have gone off and you need to switch things off because the underlying services aren't available. Again, another thing that it's very easy to say, but it's harder to live right and living it requires a sort of mindset that lets you build things that way but test them that way and rule them that way and do it. And yet not, you know, die a death of having a product that has, you know, millions of different potential configurations with different things on and off that nobody can ever be certain what the net effect of switching the flicking the switches in a particular way is right so a real challenge but a really powerful thing and something that's, you know, really sets you up for success. Modernization and I guess certainly in our world because of, you know, we started with this monolithic application to start in really important right that and for me the message here is one of just because you start with a model if you don't have to end up with one or stay with it forever. You're not married to the model and you know, and they're the real power in this is the ability to say, we're going to take this thing we're going to use it because it's got a lot of value, but we're going to put a straggler on front of it or whatever other structures or patterns you choose. And gradually chip away and makes good decisions about how you're going to attack that over time and what the business returns for those attacks are. And as you'll see in the next slide is a bit more about that sort of stuff but how you go on that journey right it's about setting it on day one and saying well we're going to spend six months or a year or whatever it is taking this thing apart and putting it back together again, certainly wasn't for us it was certainly the structure of our project so we, we had to build the same as that. An environment that we knew we were going to be living with some time and it was going to be evolving for some time and then the final piece of this, you know, from my perspective and and again as it's described in the open agile architecture is creating the wrong right non technical environment and again. Sometimes this is one, you know that people like myself and possibly some of you tend to shy away from a little bit right this is a little bit more sales in one side a little bit more work on the other side, maybe a little bit of politics. But, but again, success relies on these things and so it becomes really important right so the first one is just to find that ongoing investment in architecture refactoring I guess what we're really getting at there from our perspective is that idea that, everybody except the constraints at the start and the decisions you're making. You need to have that roadmap because that has to be the reminder for all of those future dates where you're going to have separate discussions and go. Well, we need to do this now or we need to pay back this particular data or invest in the next to do why, and have that laid out have it laid out not just with the technical pieces but also with the business returns, you know, whether that is in terms of flexibility or additional improvement or productivity or however it may be defined. But the act of writing that down and ordering it and organizing it is incredibly powerful. It's really powerful for your stakeholders in terms of getting their buy in it very useful to be able to produce it and at a certain point down the road as well. But it's also valuable for the development teams to see that, you know, we're making short term decisions but that doesn't mean we're stuck with them, and that we have a path forward. We need to then turns into that architectural roadmap right and I guess for me with this you always make these plans knowing they're going to change and that's okay because because you make the best decision you can on the day and make them. But what you want is that sort of touchstone or guiding light or waypoint that you're aiming for and say this is where we want to go. We're going to do X and that takes us towards it maybe slightly way in a different direction, moving in the right direction then we're going to do Y and then Z. And maybe along the way we change our minds about what those are and that that obviously impacts you know the justifying your ongoing investment as well and you make different business decisions. But without those waypoints are guiding lights, it's very hard right because it becomes a point thing of we're going to do X for why and maybe that's the right thing but maybe it doesn't take you quite the right direction and what is the trade off and I guess. But for me, those two first pieces really come together to create those guiding documents or touchstones or visions that help you inform what you're doing and make the right decisions going forward. That's incredibly powerful and progressive transformation, you know, it's really about getting everybody involved and in figuring out what's good enough at every point in the journey. You know, perfect never going to be there for for lots of projects and good enough has to be good enough. And the question then becomes how do you test that what is the, how do people decide for themselves what that is how do they describe that others. How is that trade off played out. How do you do that at every point in the journey knowing that the variations are going to kick in as we execute on a roadmap and make different investment decisions. And, you know, it's about creating that information upfront, not because it's cast in stone or isn't going to change but rather so that it can inform the decision going forward. And then the final one, I suspect is both kind of, you know, something people are very aware of but something sometimes it's very hard to do which is inverse Conway, which is you know to say well if our architecture is going to be inspired in structure for the architecture that we want to get to. And it's easily said it's harder to achieve but it is incredibly powerful if it's done it's something that we found incredibly powerful. And it's something that you know we've seen in other places do the same. And I guess that sort of takes me to the end of my few slides about this I guess what you know what I've tried to bring out here is we went on a real journey with some real if so much willing requests at the start. And we did these things we didn't necessarily know as we did them what the right phraseology or the right way to describe them. You know that's something that's come in over time but we really feel that we've we've built the way forward and on the right things and that what we've done in our contribution to the open agile architecture is to describe that and make that available to the people and hopefully it's useful to you and others as well. Okay, thank you very much. And the question I have for you, Patty is actually about one of the last things you spoke about and you did a great job it said the inverse Conway maneuver. Can you maybe take a step back about what that is and one of the things you said was it's immensely valuable if it's done right but can you can you take a step back to explain what it is and and what the value is. So I guess the first thing to say is Conway's law as a concept hopefully most people are familiar with it maybe not, which says that ultimately your software architecture or indeed your enterprise architecture ends up mirroring your organization structure. And you can, you can argue about whether you feel that's true or not but unfortunately the general experience is that's what happens. The inverse Conway is that ability to step back from that and say, well, if our organization structure is going to influence our architecture, and we know what the architecture we desire is, how about we set up our organization structure in advance to ensure the architecture we want to achieve. And I guess, you know, the trick with as I alluded to in the video with doing it right is around that idea of saying well, you know, you're never going to be perfect right if your architectural vision has 56 components you're going to get 56 teams with just the right composition that's very unlikely to work in an organizational level. Would it may well be that you could say well these sub components we can hand to these teams over here and these sub components can go here and that kind of thing and that's really where you know inverse Conway kind of comes to life I guess. And is that something that that is a is a sort of scale thing is that is it something that's that's more and more important in a larger organization or is it something should have in mind in it even even a smaller organization. Yeah, I think it's interesting Steve I think I think you could argue it affects both and I think perhaps in a larger organization, it's probably quite clear cut right because you've got very large groups of people coming here and you will there are pressures so if you don't act something will happen, but actually, you know, taking a step back and sort of stepping back into my early career I worked for a startup for many years. And in a small organization, you're, you're almost more susceptible to without ever realizing that in an organization of 20 people and you randomly form into squads to go and address different problems. You know, so easy for each randomly, you know, form squad or dynamically form squad to create their own component or repository or architectural structure, and then just seed that to the rest of the team and you end up with with it, you know, with with a version of that sort of run riot, where as the organization has transformed itself every month or two, your architecture is getting read to the background without anybody ever, you know, taking a step back and going. This is the direction you want to go. Right. And I think it's one of those things you're, you're, you're subject to no matter where you are in the world, whether you choose to act on it and, you know, do things like inverse common is a different question, but I think everybody's subject to whether they know it or not. That's right. Yeah, I mean, I'll, I'll give a shameless plug at this point for one of our other standards in the open group for the, the digital practitioner body of knowledge which which kind of has this emergence model concept and addresses the types of things you need to be thinking about the different stages of an organization's evolution. Very much sitting very nicely with what you talked about, you know, it says there's a certain point in time when other things become much more important, but arguably they're there from from the beginning. So anyway, Paddy, we're going to, we're going to move on and save some other questions for you on the panel. So don't go away. And we will see you again soon. In the meantime, thanks very much.