 Paul oedd o'r gweithio'r cyfnod o'r ddechrau ar y tawgaf i'r busnes ar gyfer y gweithleidio. O'r gweithio'r busnes, y busnes, y gallu ddau, y bwysig, y gallu'r informacio a laethau. Paul, rydyn ni i gael, ac mae'n dda i'r bach. Ddweud. Ddweud, ddweud. Gweithio'r gweithio. Dau, mae'n ddweud, ac rydyn ni'n ddweud ychydig o'r gweithleidio busnes. I'm sure when I was asked, can you do the talk about business architecture, I said, yeah, as long as it's not first thing in the morning after I've been drinking Guinness, but I'll let that one slide. Yeah, so I'm going to give a talk about the work that's been going on through the business architecture updates into Togaf. Something that I'm quite excited about and actually have had quite a bit of interest in. Mostly, and why this is a bit cheeky, because I've been a consumer and a user of this. So I've really kind of very small person, I feel like, stood on the shoulder of giants and I'm going to give a credit to a few people, not everybody, but a few that have been involved in the core working group and led some of the work streams to kind of do that work. And I won't read them out and name check them and there are plenty, plenty more and it's not meant to be exhaustive, but certainly I wouldn't want to stand and take the credit away from these people. So business architecture, what I'm going to go through is a little introduction just to kind of set the scene of what has happened and where it sort of fits and then talk through a few things. Overall, what are the improvements, the areas that we're focused in on and what's been produced and I'll give a couple of kind of illustrations as to how that's useful, hopefully. And then focus on three main areas, business modelling, business capabilities at value streams and information mapping. And then wrap up just to kind of segue back to the credential piece, which is a really nice, neat way of demonstrating the value that we're just talking about there. So I want to kind of go through each of those just to kind of highlight, obviously I thought the best way to do that was to walk page by page through the standards. I'm joking, right? Just see if anyone's paying attention. So, yeah, a bit of background. First of all, you know, the togaf stand of version 9.1 published back in 2011. So business architecture, whilst it's been around for a long time, if you go back then a lot of business architecture was fairly loosely defined. It was kind of referenced, it was in there, but in terms of actually what you did and how you did it, there's a lot of different ways. And you could argue that either that wasn't clear or it competed or, you know, exactly what should you do about it. One of the things that I used to sort of say, and in all honesty, my own perspective on it has moved on, is I used to reference that it's, so just to kind of set the scene. As I said, I used to be the chief architect at Raw Mail, sort of wearing that badge inside that organisation. It was before I joined IBM, so I was actually kind of there, wore the t-shirt, set it up and then paid the price for all the decisions I made because I was still there for several years. So I've got all the scars, I've kind of carried it, I haven't just kind of come in and gone away again and a bit like grandparents feeding their children sugar and going away and not worrying about the consequences. I actually had to stay there and worry about the consequences and do some work with it. And at the time, I had responsibility for business architecture and I used to describe it as holding a mirror up to the business. So in other words, the architects needed to know what was going on in the business in their own language so that they could interpret and work out what was going on. Now that was unapologetically a mostly IT focused perspective, but that's where I sat. That was my need, so I'm not trying to say that's what's appropriate for everybody but that's what I was doing. So for me, business architecture at the time was about reflecting what the business needed and finding some way of codifying that, some way of being able to capture that and understand it. And the simple argument that I had in discussion with the business was, well if this is wrong, if I haven't understood it, you're going to get the wrong IT. So it's useful to do that. Now that's quite straightforward and I still think that's valuable in itself, but of course when you look at what's going on since I was doing that and that was 15 years plus ago, actually adding value to an organisation requires you to understand the value propositions. And we heard a lot yesterday about topics and we hear them all the time about things like agile. Now if anyone actually digs the underneath what agile is about and lean as an example, it is ruthlessly actually about adding value. One of the key principles in agile, if it doesn't do add value, don't do it. I don't know if anyone remembers that one but that's the key basis of it. And therefore, if you want to be able to be agile, you want to embrace any of that kind of thinking as an example, you need to understand what the value propositions are and that means you really do need to reflect and be able to understand the business architecture more than just hold a mirror up. The other thing that was mentioned a lot yesterday, and apologies for the ones that weren't, but I'm kind of giving you the highlights if you like now, is a lot about innovation as well. Now to innovate you clearly need to be able to understand what innovation has value, where that can come in and what the greatest sort of responses are, the best pieces to put it in on. And that innovation again helps if you understand where value is added, you understand what are the things that your business does and what it needs to do well to support it. So those kind of forces have helped, sorry, those forces have increased the need to be able to understand business architecture and being able to better map it beyond just that holding the mirror up. So to me that's kind of raised the demand and the need and the profile of it. So I'm very glad to say a load of work has been done by the architecture working group and published some major improvements in 9.2 last year, and I'm just going to kind of highlight some of those so that you can see where they are and hopefully I'll set the context as to why that's relevant. But also to give reference for people so we can kind of advertise and you know they're there, right? So that's always one of the things I think that's hard is actually knowing what's available and what's out there. So the key advancements. So I question whether I should start with a model because that always kind of sets people, some people get excited, but this is really key because essentially there are three things in there that you'll see repeat. So those that were familiar with the meta model before there are three key additions, business capability, value stream and course of action. They're circled there. And I put the model up because these are going to get referenced and mentioned in the advancements work as we go forward. And just to kind of set within the TOGAF ADM, most of this stuff, not exclusively of course because anyone who knows it understands how it all feeds through, but just to kind of give the major focus areas. Clearly as a load of stuff happens in phase A around architecture vision, it's relevant to this. So the whole idea of trying to join up the difference between strategy and the actual architecture by having something in the middle that creates a course of action. Sort of that bit that sort of stops it being from the strategy just being a kind of fire and hope that it happens kind of approach, but actually kind of getting that connection. And it's where the initial idea around value streams and capabilities is introduced and then works through starting to kind of expand on that basis. But clearly a lot of the stuff fits in phase B, the business architecture phase. And in this area it ties it into another or other set of activities, things like planning cycles within organisations, but actually adds and expands the things I said around things like value streams and business capabilities, where they fit, how that sort of sits within the architecture piece. What I think makes this really, really useful though is as well as those changes having gone in, there's a number of series guides. Now these series guides stand alone, they supplement the standard, and you can look at them and read them and understand what that is about, and it helps explain it in a much sort of a modular digestible manner. And the four that exist, as I said before, business capabilities, value streams, business models and information mapping. And if nothing else, it's just an advert that these are things that you should or can use. So business modelling. So the first one is about business modelling. Now this to me is highly valuable and talks about how you might actually have a common framework, talks about common business models, partly because I don't know about anyone else, but I've always been frustrated by, nowadays I talk with client organisations, but before when I was working with an organisation, and I would have people say to me, I just want one simple A4 picture of my business, as if that was an easy thing to achieve. It was going to be one picture that everyone was going to instantly recognise and kind of go, that's my business, I'm not ever going to argue with it and that's fine, and you can create some sort of magic. But the idea of trying to, because the problem behind that was for me, was actually that one model. The reason why that was always hard is because there's so many different stakeholders have so many different needs from that one model. I went from a strategic point of view in a boardroom where the executive directors might be looking and kind of going, what do we want to do, what can we do in terms of innovation, through to people trying to reorganise the way that they're actually setting about going about new major programmes, or even as much as kind of what are our major processes and what are we trying to do for certain achievement. Therefore, there were always going to be clashes from those stakeholder groups as to what they sort of saw as the models. So there's some useful part about how to kind of work with that and what can be done. And the link to strategy, you'll see on the right there's a whole talk about a whole sort of part around the blueprints, the different types of things that you can use and how they sort of fit together and how that relates to delivery of strategy. And referenced to quite a few different industry models, including things like some external ones that we've had presented to the open group in the past. I can remember, and I'm going to get the name wrong, but it was Alex Ostermeyer. Did I get that right? Ostervoldau. I was close, yeah, presented on the business canvas. So one of the key ones, business capability. Now this is a fascinating one and I'm very glad that this series guide was produced because a lot of ambiguity around the term and so there is a definition that's been created by this work. It defines what that concept is. I've not put it up. I'm amused that it's produced by somebody who's got a very similar surname to me, but not quite the same, which is unusual. Ulrich Holman, a homun, it's just got an extra N in it. And no, absolutely no relationship as far as I know, but yeah, it's a nice little segue. But actually talks about how you go about identifying and presenting capabilities. Now this is something which some people, I mean I was always a big fan of these back in my Royal Mail days. I can remember reading some papers from Forrester and Gartner, but in particular Forrester who produced capability models and talked about them being something that was necessary. But there was a lot of quiet around it for a long time in terms of actually seeing them and exactly how they would be defined. So I think the concept's been known, but it's been quite hard for people to get hold of those. We certainly produced one inside Royal Mail and the Post Office, the UK Post Office. And to be honest, we created it from scratch, which was quite entertaining, but perhaps a waste of time in the end because there should have been quicker ways of doing it. And when I joined IBM, I was quite glad to find out that there were a bunch of industry ones, some of which we got and some which came from different industry groups. For example, I know of an insurance industry one which is run by an insurance consortium of organisations. And those capabilities basically give a start for people to be able to define what the abilities of those organisations are, those things that that organisation can do. Huge, valuable construct and very glad to see that it's now kind of been baked in and exist here. Now, I always define the capabilities, the ability to do something, is a simple kind of cheating way of thinking about it. And it's very useful from an architectural point of view to think about capabilities because if you think about some of the other business models, they're often tied up with organisational constructs. And one of the things about capabilities is that they're organisational kind of agnostics, so they're not fitting down purely what the sales director says or the operations director or whatever else. So there's some useful pieces in there. And the other part about capabilities is the capability persists, provided that's something you want to still keep doing, how you provision the capability will change. And that then becomes the planning choice. You can decide how do we as an organisation want to deliver this capability? Do we use different people? Do we use different processes? Do we use different information? Do we locate it in a different place, the classic kind of piece? But the capability is still the capability that you have to have. The other part just to kind of give a few living examples on this and why I always lean back on this one as a major one and I'm very keen on capabilities is when organisations change and decide they're going to do something different or new and I'll give an example. I did some work many years ago with an energy company, an energy utility company who decided they were going to start doing some trading. They were basically going to start betting on the weather is the way it looked like to me, to be honest. And it's fairly commonplace now. But at the time it was new, so they were going to have to set up a bunch of new things to do as an organisation. But actually by them working out what those new business capabilities were that they needed, they could splice that into their business model and they could say, okay, we are about to do some trading. That means we have to have these capabilities and they didn't work out how are we going to stand up those capabilities? How are we going to make sure we have already got some of those capabilities? Do we need to bring some new ones on board? Do we need to stand up, et cetera? So it allowed them to think about that in a non-organisational way. It wasn't a fiefdom debate. It was a debate about were they prepared, what did they have to do? And clearly from an IT point of view, that meant that behind that you could say, did they have the information they needed? Did they have it in the right places? Did they have the technology to be able to perform it to support those capabilities? In case anyone's been wondering what on earth the capability looks like, this is a very simplified model, but it's taken from the guide to illustrate that there will be multiple levels and different types, so you might have strategic and core. And these are deliberately shown as components, so hopefully people are familiar with these kinds of things. And if you're not, then it's a very good guide to introduce you to the concept. Value streams, now this is interesting because I think I mentioned already about agile and lean and the fact that agile, when you really boil it down, is actually about adding value, which fundamentally asks the question of, you need to know where the value is added then, right? Because if you don't know where the value is added and you don't know what, then you can't actually subscribe to that. So the value streams guide defines what a value stream is. It talks about the significance to and from the business and enterprise architecture sort of world and then provides some guidance to actually develop in those, along with key scenarios. And for example, one of the sort of things it does is the value stream concept is to kind of say, there's a name, a description, who may trigger it off and what the value is that it's adding. So why does that add value? That's a key element. And then those can actually be mapped to capabilities. And that's one of the key things about value stream. I know there was a lot of discussion and debate about the difference between value stream and value chain, and we've clearly settled in through the work that was done through the business architecture worked on value stream. Value streams can be decomposed into the elements that map to capabilities. So the idea is that each individual component demonstrates some kind of value add piece, as opposed to the value chain, which is a connection where the end outcome is the piece that adds the value. There's a lot of commonality, and it's a nuance, but it's a valuable one when you're talking about individual capabilities. Now, information mapping. It's interesting because when I first started looking at information models within enterprise architecture, it's often layered just as another layer. In fact, actually, information, as we know, really runs top to bottom. So it's useful in the business architecture piece to understand what the key information entities are for any business. Now, if that is, for some people, that will just be a statement. They'll recognise completely others, maybe kind of furrow the brow, and kind of go, why is he saying that? Apologies, some people will get this straight away and will kind of go, yep, fine, carry on. But as an illustration, we all know if we work with certain industries, there are certain terms that, when you throw those in, become the key term to any debate. So I do a lot of work in engineering, and I did a lot of work with a business architecture for a British nuclear submarine builders quite a few years ago, who presented in a plenary session in Edinburgh a few years ago. And there, the word part is absolutely fundamental. That, as a key business information entity, actually is one of the prime things to worry about from a business architecture point of view. It's not a data thing, right? Because part means so many different things to different people. Now, that may sound either completely obvious to people who have been immersed in that world, sorry, a site of pun there, or it may seem completely puzzling as to why that may seem so odd. And I'll give you a little bit of an insight to that and why it's relevant. In a submarine world, and this is true in a lot of engineering situations, when you do the initial design, you identify a part, and a part at that point has a purpose, and you're just defining it saying, I need to have a pump, and a pump needs to be able to do this, right? And you're defined in that way. Much later on, that part has to be procured. At that point, it is a specification that has weight fittings, kind of all loads of other information about what it needs to be able to do to be able to perform its function. And that may sound fine, but actually later on, when it's being actually assembled or fitted, it has a bunch of instructions about actually what it's going to be doing to kind of put together that's far more precise, because its location is important as well, right? So that's all to do with the kind of balance and the weightings and stuff within, say, a vessel like a submarine. And then when you get into any kind of on through life part, sorry, through life element of the journey, part has another completely different meaning. So basically, if I walked in and talked to the head of engineering or I talked to the head of operations or I talked to the head of procurement and I said the word part, they might all have roughly the same idea in their head, but in terms of what they needed and what they meant and what it meant for them and the level of definition and the way that they actually looked after that thing was completely different. And therefore, the enabling in terms of data models in terms of systems, in terms of processes, were completely different. And just to kind of illustrate why that's key, it takes a very, very long time to design a submarine. And I'm just using this as a great example, because it is such an unusual thing to have to do, it kind of exaggerates and makes a nice point. But these points exist in other places. And when you first design a submarine, let's take that part, I might say it needs to have a specification of 40 something, 40 units. If that's BA, I'm not going to say anything dodgy, don't worry about it. So it has to have a specification of 40 units. And I'm not even going to try and pretend anything, I'm just going to say, if you'd bear with me, just let it be a random abstract reference. OK, but they have to have a specification of 40 units. That then basically says, OK, let's go to market and find something that's within these tolerances weight-wise, size-wise, performance-wise, that can cope with 40. Now, funnily enough, the market only has pumps that do 30 and 50. OK, so the procurement department go, it's going to have to be a 50 then. That then raises a whole bunch of engineering change requests that go back into the business and says, right, we've now got a pump that does 50. That's fine, it takes five to seven years to design a submarine 10 plus to build one. So once it's out in service, 15, 20 years after the original engineer has specified the part of that pump, that pump needs replacing, the original company that made those pumps is unlikely to exist in its present form or previous form. So somebody's going to turn around and go, we need another pump. Oh, that's funny, because that organization was bought by this organization and they do pumps and it's similar weight and size and we can kind of cope. But they only do a 40 and a 60. Well, that's OK. Obviously it's replaced a 50. Well, we can't replace it with a 40 because that would be suboptimal, right? But the original design would have said actually that was appropriate. So that's why certain things within your business architecture like key information absolutely relevant. Just to throw another one in, I do a lot of work with construction companies and construction work at the minute and the word plan is equally as fraught and I'm sure in all your industries you could find a term which somebody would say, what about this word and you'd all kind of go, that's our magic word, that's the one which creates angst amongst us all. So that was just sort of setting up that obviously we need to worry about what those key information is. So this is a different level from data. This is trying to work out what are those key information pieces. There's some work around this in terms of information mapping, another series guide sits with the others and helps with that kind of vocabulary and that kind of idea of how you use it, where the process is set. And some examples here that were taken from a world which I know nothing about in finance. I'm not going to take any questions on this whatsoever. If it isn't material, if it doesn't dig, fly, think under water or float I'm kind of not that interested I've got to be honest. Ever since I was a small child it's where I've focused. So that leads me to I've mentioned the four different sort of guides that have been produced, there's some great work going into the specification. One of the problems with work going into the specification is obviously you need to know it's in there and where it is, right? So this is his purpose and this is to kind of call out that it's in there. This was a big, big change in the last release. But as well as that these four series guides really help kind of focus and talk about those things as separate parts and are completely aligned. So it's useful to know. And then just a small kind of piece of work there is obviously the TOGAF Business Architecture Level 1 Credential that Andrew and Steve talked about at the beginning that builds on this body of knowledge uses the stuff that's in the TOGAF standard specification to actually help provide that to kind of show and demonstrate what is for me a very important credential we're certainly seeing from an IBM point of view a lot more people wishing to certify and be interested in business architecture. There's always been a few people but it's actually become quite a key career path for a lot of people who are working and starting as business analysts and wanting to get into business architecture and see that much more relevant to innovation supporting, as I mentioned before these are the epics and the story development around things in Agile it's quite a key and valuable role. So that is everything. Thank you very much. Okay, so the first question that came in is about modelling. Where do you model, where or how do you model this in a UML tool an Archimate tool or God forbid PowerPoint? So, interestingly I've always been I've never been averse to using a pen oddly enough. So I think there's a number of answers and clearly it's a loaded question from that point of view towards the end. A couple of things that I'm going to say and my views and be interested from a business architecture point of view whether anybody else thinks any differently, but I always wanted to to this is my position so as when I was a chief architect at Royal Mail we set about using tooling with a couple of misadventures. So I still have the scars what I call what the whole team called an EA Vault because you could create models I won't tell you which vendor it was but you could create models and you could put them in there they were very safe but no one could get them back out and the problem was we did that and then we had another go and went okay what are we trying to do here and we realised we had made the classic classic mistake that we'd been telling all of our customers in the business not to do which was buy the tool first and then work out what our requirements were so I don't really want to say here is the answer now go away and work out what you want to do what I really want to do is kind of go what are you trying to do first so if you are trying to model the architecture from a business point of view in order for your own understanding and keeping that going then I think there are options I've used I think that's a great way of doing it UML I've seen used I have seen PowerPoint used of course but if however you are communicating to an exec board what their one single picture looks like for the organisation then I wouldn't be scared of using whatever works best for that audience so it is the two reasons you model for your own understanding and you model for communication and modeling for communication has to take the form of whatever message you are trying to get over to those stakeholders so I've cheated slightly with the question I appreciate that but I think that's my personal view and what I would always advocate is the best way to approach it the point about the modeling for communication goes with anything that you are trying to communicate that needs to be understandable by the audience doesn't it typically what roles should work together to define capabilities value streams and information mapping successfully the roles so in terms of the so we do a lot of stuff these days we're using design thinking techniques a lot of people are familiar with design thinking and design thinking focuses very much on personas trying to understand people's journeys whether that's customer journeys in my world where there's a lot of B2B so a lot of business to business type engineering organisations employee journeys are often seen as key as well and one of the things that's and again a little bit of a truism but one of the things that's often missed I've seen even in design thinking sessions where people talk about customer centricity or person centricity is it still becomes quite easy for the person that you're actually talking about not to be present and that may sound quite daft but I was going in and looking at some employee murals that have been created by somebody else and they were very nice the graphics were fantastic on them that illustrated what somebody on a shop floor would have to do to be able to do certain capabilities and so this that was kind of the mural was the first part of understanding what they did and then therefore what the value stream was that sort of went behind that so that could be then broken down into what capabilities were being performed and then basically what resources were needed underneath that which is why this links back to that piece but the gotcha behind all of that was actually when you kind of dug into where that journey had come from it was still a view of the pretty much the IT function and a little bit of the operations head office function as to what they thought that person should be doing rather than actually getting those people in the room and asking them themselves so there's still a disconnect there in terms of things so clearly the roles require all those kind of skills somebody who can understand the business processes understand the industry somebody who can understand what that means from a process point of view classic skills are useful typically we see those as architects because we've got those skills inherently not exclusively but that connection back to the person who actually has to do it if it's a real customer as opposed to a surrogate customer or a real employee as opposed to a surrogate one is the key to all of that other skills you can stop them and depending on the case I remember in the example you were talking about of submarines there was an exercise involving an awful lot of staff and post-it notes and all sorts of things that people who wouldn't normally get involved in this kind of stuff got involved in really getting those requirements from that level and very very much so I still remember having the sessions and people with overalls coming in straight off the shop floor and they'd walk in and they had an expression called swath in their boots which was the actual the pieces of metals off the lathe machines and the oil and everything was on their boots and wearing the overalls and the personal protection equipment and putting it down and the only thing I had to do was to make sure that the notes we took didn't contain all of the language that was used frankly but it was the most education on eye opening session and really really valuable because there's so many assumptions and misperceptions and to that very point even the head of operations there who considered themselves to be very close and understanding of what was going on said well they won't these people won't want to be to use phone devices and stuff like that because they're busy and whatever else and they're not familiar or whatever there's a lot of assumptions in there and we had not only when we had the sessions with these people coming up with ideas about what to do with the tablets and phones when we had the breaks they were all getting their phones out and doing their various updates it was like well they will do it anyway right so that may sound obvious but until you actually see it and see that exercise that link can be easily missed right okay see you said you were a fan of capabilities what's your kind of personal favourite or what do you think people will find the most useful of the series guides well okay that's a bit like asking who's your favourite child I suppose right nice that you think of them that way yeah I suppose of course they're all valuable and they all connect and that's the great thing I think is when I look at the specification what I think is great is these things have gone into the overall standard but sometimes because the standard is a large body of knowledge rightly so it's difficult to be able to pull certain pits out and that's what these series guides do they help you highlight some of those key things I am a massive fan of capability modelling it has always always been something which to me has been surprisingly straightforward but incredibly valuable and one of those things when I don't think I can think of a single occasion where I haven't used that technique that capability and it's not been a friend or an ally you know it's just one of those things whereby it's fairly simple it's fairly straightforward most people can readily get to it and understand what's going on there and it becomes if nothing else a good capability model becomes I like to think of it as a washed out wallpaper where all of the thinking and the discussion sits on top the capability model itself isn't important the dialogue and discussion that sits in front of it absolutely is how do you keep the models fresh okay no that's an interesting one so this comes back to the philosophy about how far you're going things like a capability model that can be at an abstracted level shouldn't change too much that's the beauty of them unlike say process models whereby you've got continuous process improvement and therefore you expect processes to be constantly improved and constantly updated otherwise the very name doesn't work and similarly with organisation models when organisations change, merge, acquire whatever else and again you expect those to change capability models as an example and key information models shouldn't change as rapidly at a certain level there's no abstraction but there is a need to keep up with those obviously I think what's important and this isn't just true for business architecture I think this is across the piece you only need just enough that it's for when something is going to be consumed so dropping a level lower you've always got to be very wary of not trying to create something which is going to be out of date at the point of consumption so currency is something that is you've got to be aware of so why you would be creating I mean I'd always ask why you've got the luxury of updating something that isn't about to be used is an interesting challenge and I don't think people have these days so actually the point is you only need a level of business architecture to which you are going to support your overall roadmap so you do just enough just in time and you have to have some visibility over that Paul we will leave it there thank you very much for your thoughts and your work on business architecture in the open groups