 So, good morning everyone and welcome to the third Togaf user group and looking around the room there are some unfamiliar faces and some What I might refer to as Togaf royalty here We do have I know an asked the expert session in the second half of this morning So we certainly have some of those in the room But just to introduce myself, I'm Steven and I'm the president CEO of the open group and it's a great pleasure to have you here Thank you for making the effort to come and How many of you do not use Togaf Okay, so it wasn't a pre-qualification for being here that you actually are a user But it was a good clue that you might be interested if you are so You are one of 57,000 nine well 57,987 People are certified to Togaf as we stand here now And the rate at which that's growing it's quite possible that by the time we leave we will have crossed the 58,000 Barrier it's that kind of number and that kind of take up of Togaf There's way more people using it than are certified, of course Many are trained and not certified many just get asked by their management to go figure out what this Togaf stuff is Give me give me a Togaf give me one of those things So there's a huge community out there Togaf is used in a Very large percentage of the world's top companies and and I mean the world's top companies all around the world Wherever we go, there is demand and interest in Togaf. So You are part of a very large community Togaf is a standard here at the open group that is evolved By one of our groups called the architecture forum the open group architecture forum They represent a very small percentage of that huge community. There are there are a lot of them but As a percentage of the whole it's a very small group so one of our motivations for doing these meetings is to try and hear from people who aren't necessarily Living and breathing the standard itself in terms of evolving it and maintaining it over the years But those of you who are using it in anger in your day jobs Hopefully not too much anger, but certainly those of you who are using it for real what you what we're interested in your experiences what you've learned from using it and Any ways that we might be able to tell you we'll talk more about this shortly But anyways that you might suggest that Togaf can be improved What you think is really great about it just your impressions any of that stuff that comes out will be of value to us In terms of what we hope you get out of it Hopefully have you have your own ideas coming here today, but certainly I think the opportunity to share What's worked what hasn't worked with other people using it in different organizations? Here having the opportunity to Talk to some other people who have been working with this for a long long time now and do know the standard inside out You'll have that opportunity and really just to also try and have some fun The the debate format that we we have this morning We did that for the first time last three months ago in London. It was both very entertaining and and I think very well received So it's a it's a relatively short agenda, but I know everyone's busy and we appreciate you taking time out of your Your day jobs to go. I'm not going to take up any more time except to repeat really genuine welcome to the open group This morning and I'll hand over to your emcee for the day Terry Blevins Well, I want to repeat what Steve mentioned. Thank you very very much for taking time to come out and share in your experiences hopefully get enlightened and and engage in the process of making Togaf more useful for you because this is this is really about How we can capture some information that will help Togaf evolve in a direction that makes it a better tool for you and Better for the businesses that you that you support the proposition is business architecture and business Architects should be within the business side of an organization. Well. Good morning everybody Chris Armstrong with APG And I am representing the proposition that business architecture should be owned and governed by the core functional or operational capability leaders such as the CEO CEO functional unit managers and the like and You know, I guess I'd like to you know really start the the proposition may be more for from one of fear uncertainty and doubt Namely if the if the business does not own business architecture I will claim it will be unsuccessful and unsustainable. So I'm going to kind of be making a Contrary argument to some extent and you know starting with You know, maybe just a you know replay of history, you know, how many people here have heard of this claim of a misalignment between the business and IT All right, I Believe and I'm not trying to be necessarily just controversial provocative here I believe that's actually false. There is no misalignment absolutely none IT built what the business wanted exactly the way the business said they wanted built They didn't care what we had to say about some of the consequences and side effects because I said, oh, that's just all IT stuff So so I again, I sincerely believe that the business got exactly what they wanted Except they were surprised with how perhaps inefficient and ineffective some of their investments have Unfolded and when we take a look at the the spread of the landscape across the enterprise So I think you know a big part of what we're seeing is really just the the maturation Of this business and our profession, you know over the past so many years, you know back in the day You know, we call this stuff what computer science, right? You know because it was all about the computers and having to be you know very scientific about it Then we kind of moved into an era of data processing you guys remember that sort of stuff and then we moved into you know More information technology and now we're moving towards Kind of pass a now, but you know the service oriented approach, right? But what we've I think what you know all those things represent is a narrowing of the proximity between these two artificial boundaries within an organization And of course where are we at now in? 2016 we are in the era of digital business, right? And so I believe in the future there will be no distinction between the business and IT and in fact I think many organizations And you know this may be an interesting topic for a future debate might be What is the future of technology architecture? I kind of believe as a you know a startup organization my company I You know took me a while just because of where I came from of Not really having you know comfort of you know not knowing where the servers were and who I could call when things broke And who I could go beat up, but I've you know gotten over that you know paradigm shift where it's like why do I care? What technology sales forces on and boxes on and our learning management, you know I still care about interoperability Informations of a great concern so what what I kind of see is it again? This really represents, you know kind of flipping things, you know upside down I think technology is big it could not can become completely irrelevant because there's still people have to make all that stuff work But what what's gonna supplant it? I I believe is business architecture, you know That is the key essential thing, you know that we've been missing to really connect the enterprise and You know the the things that I've heard from both business and IT people I was at one organization that actually forbade someone in IT calling themselves a business architect Because how could you be a business architect if you're not a business person now? Of course, and so they basically said you could call yourself anything else you want So IT came up with an interesting name called process architect That was kind of a little bit off, but it was really a business architect in function not a name But I think that you know the key thing here that the the the big thing that we've got to help our partners Overcome is not so much the word business, but the word architect And I think in some ways and we've got something I think we got some soul-searching to do within the profession here is Whenever, you know, I've noticed that whenever you mentioned the word architecture people start shaking and trembling and You know hiding behind plants and changing the subject and so there seems to be this this disdain and in a fear of architecture And I think that comes out of a lot of you know good and bad reasons of historical experiences So I think you know, you know what we really need to do is to help you the business Really be responsible for itself because that's really what I think business architecture is all about I mean ultimately if we take a big step back, what is business architecture really trying to provide to the enterprise is? transparency What is going on in the business and I believe you know the big issue with this Presumption of misalignment between the business on it is actually not again between business on it It's between the business and itself The left hand doesn't know what the right hand is doing. We make you know unintentional Redundant investments in the same, you know capability without known this, you know necessarily added value or benefit And then the business gets surprised when they're finding they're spending ignorant amounts of money on something They don't think is very important. So I think you know that that business architecture needs to be on the business side for a couple of reasons A have any of you also noticed that enterprise architecture as a overall profession tends to have an ebb and flow with the economic times Right. So when the economic Downturns a little bit. What's one of the first groups of people that get downsized or completely eradicated Enterprise architecture. It's a non-essential sort of service But what as many of you may know, you know a lot of organizations, you know, are you know trying to respond to you know changes in their Ecosystems and their customer bases one minute and We need the ability to be able to respond to that, you know in a real effective sort of way But if we don't have again that transparency across the enterprise about what's going on I think the business is going to continue to make Find themselves their own worst enemy as as someone said in I think the plenary from Pogo You know we have met the enemy and he is us I think the other thing about it is you know ultimately we need business support for continuity funding Ownership and at the end of the day I just really think it's time for the business people to grow up and you know and join you know of the real world and take Responsibility for really, you know Scientifically and rigorously managing managing their enterprise And so one of the things that I'd also propose is maybe calling it business architecture isn't very helpful The way I look at it is it's really enterprise business intelligence. How can I possibly not if I don't know What's going on in my enterprise? How can I make intelligent investment decisions? And I think that's the reason we need to have the business architects on the business side Well done. Well timed boy Press you ready there? Thank you. So good morning. All right, so I'm gonna start really I always feel so this is a second of these debates where I have Faced off to my worthy opponent mr. Armstrong. I just feel gently intimidated by His is highly skilled and competent presentation to start off with And I also this time seem to be stood on a trap door And I just want to know where the handle is what happens to the loser. So yeah But anyway, so so current so business architecture the proposition So I wanted to take the proposition and just turn it a slight little bit on the dial because actually I don't believe when we're talking about what we want to do with toga from business architecture that the thing we want to debate is Where do the business architects live within an organization? Who do they report to that to me is an organizational construct? I think really and you might have seen it in some of the converse that some of the strap lines Business architecture Where is it owned and governed from within a business actually has material consequence? For an organization and for the way that you do enterprise architecture So so that's where I'm kind of coming in and thinking about and and just to kind of unpack that slightly you know What I mean by The ownership part isn't a possession belonging thing You know who owns it who are the only people that can touch it who are the only people that can sort of say say that this is our thing I'm really talking about the responsibility who's responsible for worrying about this stuff right making sure that it makes sense It's coherent. It's comprehensive. It kind of does what we need it to do and I'm talking about the Practice of doing or exercising business architecture in this case clearly we are saying and what are the consequences for a standard like toga in that case as well So for me if you think about business architecture clearly that's a business-wide asset Wherever I put that asset and say somebody somewhere is going to be responsible for it Somebody else will have a different view potentially. So there's no one Obvious answer end of there's always going to be some ambiguity around that but You can say the people who create the architecture who are the people who produce it are the people are going to have to own That going forward. So there is an element of of development now Today I see business architecture as part of enterprise architecture You know enterprise architecture is incomplete without business architecture So, you know, I don't think anyone would say that enterprise architecture if you took business architecture out would be as valuable to the business So in that sense, are we really saying as part of this notion that we'd want to separate them because you would separate them By trying to treat them differently using different standards to do that And you know, would you would I no longer be able to say I am an enterprise architect If I don't do business architecture, would I have to be a everything else but not business? It gets a little bit kind of tribal for me in a lot of ways and One of the key things if you think about enterprise architecture is that's focusing on business architecture, but actually information architecture a key part of of any of the things that we look at wherever we are is a business asset and Extremely hard you couldn't leave it behind So if you took business architecture out, you'd take information architecture out as well You'd have to it'd be part of the whole fabric of what you were creating in the enterprise the processes use information That sort of thing so you'd end up with with well, we're not a lot left actually So it kind of gets a bit sort of where does this cleaver come down on this this concept? And the other part is you know the thought of rewinding toga specification back to seven It's quite awful actually. So I just leave that But so One of my main Concerns with we're thinking about business architecture as a separate construct that's created by different people Is around governance now? I've been in enterprise architecture for a long time I've practiced as a as an enterprise architect before a joined IBM in so I've got the real world scars if you like and Governance was the big part. It's all right creating stuff But if nobody respects it if nobody uses it if nobody knows how to use it then it's just paperware Right or wherever you store it nowadays. So governance is absolutely key. I Cannot in my mind reconcile how you govern With two separate constructs Responsible for end-to-end governance because you know, how would that work for a project if I was a project? I mean, you know as projects get more and more agile and if you want to know about that one Then go to our previous debate But if you want to go perhaps it's become more and more agile they want in a an easier lighter touch with governance if any and They are essentially the customer of Architecture is the way I think about that now. How do you get a trade-off? How does a business? architectural design authority Understand what it can concede to a project what a project should be doing if it's not Doing it at the same time that you're worrying about what the technical architectural authority that you've created separately is doing So there is a need to kind of do all that in one place To say nothing of of of how do you reconcile to feuding? Gods like a chief business architect and a chief technical architect that just sounds you'd have to have something over the top of that so The other part is as well, and this is really because so many other things are moving on technology And and the pace of change and agile from an architectural point of view You know our existing enterprise architecture capabilities have skills. They have the framework They have the capability to have the experience in an enterprise-wide perspective already Reversing on that would mean that the architectural world would it be would take longer to catch up with the rest of the world And what that needs in terms of projects and technology. So That would be my main point and we'll take questions As long as time print permits and we have 45 minutes Allocated so please someone stand behind this gentleman Thank you And then after which we'll close the floor and we'll go on to the next part of the debate, please start ready Okay, hopefully everyone can hear me. There you go. Well, my name is Gabriel Gonzales. I work for BMC software and We have been using togaf and this is where this question comes from And my initial stance is with you that business architecture needs to reside in the business You bring up a very good point and that there's got to be this overarching entity that looks at business architecture as well as information as well as Technical architecture and that's exactly the way we do it at our company, right? So we go into customer sites We have enterprise architects. They look at the business architecture Therefore they're looking and talking to the business architect and then we look at domain architecture And therefore we're talking and looking at domain architect so How do you reconcile that because to me the logical thing would be that there's an enterprise architect Looking at the entire landscape and if I look at the ADM, that's exactly what the ADM represents It's a complete circle that has business architecture technical, etc So to me I'm still with you because the business architect is the guy that I'm gonna eat or girl I'm gonna be interfacing with and I need to have this overarching governance body around the entire thing so to me I think that both of y'all are Sharing similar ideas But I feel the business architect needs to be in the business architect and on the business side this because that person knows that Information more than anybody else and the EA needs to be able to interpret that and then apply it to whatever strategies Or I'm sorry, whatever initiatives the business has and then trickle that down to the technical guys, right? That's kind of the way we do it. So any comments on that and Well, and I think my you know my again respected opponent talked about You know that we need this holistic, you know end-to-end, you know sort of view And that there certainly could be some governance challenges of having some separation of concerns But but I think It's gonna test a little bit as as this profession continues to mature You know, what is the difference, you know, because I'll admit it's not real clear to me sometimes To me enterprise architect, you know, the the qualifier enterprise really represents span of influence right and so again Togeth has a taxonomy that has you know Strategic and segment capability perhaps different flavors of the extent of influence that we had in business data application technology You know those represent specializations in particular domain. So then we get into some really interesting, you know word games Are you an enterprise business architect? Are you a segment business architect? I've heard you know people use enterprise solution architect One of the things that I you know that I find particularly curious about the architecture profession in this regard is I know of no other Profession that goes to such extent to differentiate itself from its peers, right? I mean do we see business project managers application project managers technology project managers to business analysts have this Differentiation so they're something really kind of weird going on. I think in the architecture Profession, but one of the things that I do think the Togeth ADM does a disservice to and this may be again reflective of ancestry and pedigree is You look at the bubbles right architecture vision business architecture IS architecture and technology architecture My opinion based on experience is that the business architecture has the scope and even more complexity Than the entirety of the IT architecture yet when we look at our methods It appears to be a smaller portion as it relates to the other three phases So I think that's something that's not particularly well represented I think ultimately, you know, we need to have the business architects being integrated with the business because I Just think there's it's inherently risky and we need to be careful and check our you know our arrogance at the door That that we feel that because we have this enterprise architect label that just because we come up with value streams and capability models But the business is going to believe and buy into that so it's got to be driven from the business side We're actually going through that process right now. And if you could comment if you want to I'd love to you've got free Well, it's up to you Okay, thank you very much. So when I was running the architecture office, right? Deliberately use that term in in the UK Post Office Royal Mail. I Wanted everybody to call themselves an enterprise architect Not a business architect or a process architect or a security architect or whatever else They had strengths specialism sweet spots and there were people who were way more comfortable and way more, you know Way better at technology or information or whatever else and they had their kind of preferences So you still had those people that were really got the business maybe came from the business had their Relationships with the business got the bit and we're able to talk to people outside and say that this is how we do stuff And whatever else but but that team that group that office of the architect the office of the chief architect was enterprise wide that was that that perspective and The point for me in that role and and I've said this for one of my favorite kind of anecdotes by this is I wasn't I was the chief architect, but I was not the biggest architect in the building. Okay? My job was about enabling the processes of enterprise architecture Including for example, what standards should we operate? How do we face off to different sets of suppliers the customers the whole ecosystem part? How do we do governance that sort of stuff? You don't want that set up with two different things You know imagine you've got a chief business architect and a chief technology architect Decide they want two different standards How do you reconcile that within your own organization let alone across the ecosystem of all the other partners and suppliers you're dealing with so so for me the You know Chris is absolutely right. We're ridiculously tribal, you know I'm an infrastructure architect. I don't do that. I'm the whatever right? But in fact actually enterprise architectures a discipline is it has to be kind of for me Managed and structured from one place. So that's that's where I'd see it Thank you very much. My name is Tony Meiji. I've been in IT for 15 plus years as an architect And my question is I just wanted a little Clarification about the debate for example, are you like Focusing mostly on the business side and are you focusing mostly on the technology side? just a little bit of clarification because sometimes like the difference between enterprise and Business it's almost the same because a business is an enterprise So what I'm asking specifically you are you are more focused on the technology side? And you and can both of you clarify exactly what the debate is about so that Okay Nuance between technology and business and now I pretty much understand clearly what you were saying, but I was a little bit Not clear on the difference between the technology side that you were saying if you want clarify. I appreciate Yeah, yeah, sure. Absolutely. Well, I'll kick off then if that's so Apologies for the confusion then so So absolutely not not focusing on just one domain. So the fact that I'm putting it all in one place So it's not about technology. It's not about application functionalities. Not about integration in certain whatever for me it is about the entire Set of domains that make up enterprise architecture all in the same place all looked at from the same perspective And I gave as I've got the floor I'll give you a small example why and I haven't yet heard the dinghy thing. So maybe I will whatever the dinghy thing is called I Me and my team as an example where I sort of mentioned the UK post office We would get called into business strategy meetings Because we were the only people in the business other than the chief executives themselves Who had a true? Side-to-side perspective of what was happening at any one point in time Even the chief marketing officer was worrying about new product development new kind of services You know advertising branding, but wasn't aware of the way that we were opening and closing the branch network for example I say opening and closing the emphasis is on the last word and But You know and but the chief operating officer was worried about the weekly sales targets the weekly Performance the network of operation the flow of cash that sort of thing. So actually I Used to get a phone call from the chief exec saying I need you or one of the people to come in because We're about to do whatever it was right some program in the rule And I need to know what the implications there are of that on all the existing in-flight projects and programs We've got on what that means whether we're going to be able to do it or not work the challenges that will bring and As I say, we were the only ones with that kind of perspective and my fear is that if you Divide any of it up You lose that perspective and that's the value that an enterprise architecture approach Brings to an organization. That's why to me a corporate body Invests in that unit. We may get lost along the way as to why what we actually do But that's the principle of what we should actually be doing I'm Wayne Boer with the Texas Department of Transportation And I think this might be his follow-up question somewhat. We don't do IT We build roads and so we're not as not an IT group We struggle with the same thing and so my question for Paul is You brought up that one of your premise was that if you have your people creating it Creating your architecture. They need to own it in our position. That's a role we would outsource and then have somebody come in and tell us how to build an architecture what's complete and How we should govern it and then we would take that over so how would that fit into Your model if we don't have ownership and then the flip side is How could we do that where we have business going out and doing an architecture and IT going out and doing an Architecture and it's owned in different places and have something that works together and is complete You know so I guess you know there certainly are some risks with some separation of concerns But I guess I would you know ask us to possibly be reflective that separation of concerns is an architectural way of thinking right Again, don't separate things just because they can you know try to have you know high cohesion and loose coupling right And I think as we've been moving through this We've been kind of taking it from a slightly different tact And I'll confuse you issue even further By suggesting not only do I believe business architecture needs to be owned by the business I believe enterprise architecture needs to be owned by the business and that we just happen to be in an interesting state in the maturity of our profession where I believe and and mr. Holman, you know kind of You know brought this up that we are really surrogates for the business We are doing what the business should be doing, but they don't know that they're supposed to do it They don't know how to do it and I'm trying to you know parts of some of my cynicism and pessimism at time Business people are not dumb people I mean if they were dumb people they'd be out of business Right, but they don't have the tools of the trade that we've been had to figure out from an IT perspective to survive We've come up with methods and tools and semantics and and taxonomies and and engineering because that's what we had to do To survive in the IT business Well, what I claim is that businesses are going to be faced with the exact same thing in the very very near future if not You know already So I'm a fan of all of that being completely business driven I think Paul was also talking about you know the the end-to-end perspective and holistic perspective that a lot of the architects bring to the table I think again that's really also just a state of industry as well is because we should not have to be reliant on Individual people for that perspective there are best practices for doing this within our profession and it's called Describe a enterprise language commonly called a metamodel Support it by using tools populate that repository of content that leads to what we are calling again an enterprise business intelligence platform Namely, I shouldn't have to rely on Paul showing up at work to give me that end-to-end view of the enterprise That's a very again a very organic tribal way of doing stuff It's what's gotten to us to where we are right now, but to really create a digital business I think we have to digitize that entire platform so that we're not reliant on people showing up and under and trying to get Their perspectives from a much more low fidelity manual interpretation. Okay. Thanks so if I can come back to the to the question in particular because something that That intrigued me in particular and is the term you talked about you said you outsourced your architecture and I'd want to unpick that statement slightly because I think at the end of the day what you do is you source the provision of your architecture from different places, but actually you still remain Accountable for the architecture that you end up with so you don't really Outsource the architecture and you don't care you outsource responsibility for somebody to Provision bits of it or all of it. Well, however that happens, right and and I think That still means you have to have that perspective of how of what your Enterprise architectures should be that supports your business model and However, you do that, you know that I think that's that was a key thing for me that you said in it But how will you do that? I still think that that perspective is is an enterprise Architecture perspective. It's not a differentiated Business architecture thing that's separate to to technology You know they have to go hand-in-hand and and more and more I think and I wouldn't say that this is Landed, but I think it's an important part of the whole thinking piece You know the traditional stacking of architecture and kind of you know, we all know the sort of the history of Architecture from a kind of technology point of view those lower levels might in my experience. I'm finding people are Obtaining of services. They're obtained They're not worried about the detail of them as much and actually the concentration is more about Well, what are the services that I need to buy at a business level in order to be able to do that and how it's done And how many servers make up the provision? I don't care because it's not my problem anymore So but you still have to have that. Well, how does that work across the whole enterprise? So That's my view on that in that sense thing Next question, please. My name is Aaron Brown and I'm with the city of Austin I'm the senior IT enterprise architect there and this problem is a really is a real one But I wanted to add a little bit of detail So in your presumption the business is an entity at the city of Austin I have 35 businesses that all are all operated as stove pipes that are entities So with your tribal approach, I understand what you're saying But right now there's nine inventory systems at the city of Austin because each one of them knew their own business knew Exactly what they needed some of them had their own funding Impetus and went out and now we have multiple resources doing the same thing. There is no Organizational planning that occurs because these businesses are being tribal there. You have the right word there. It is tribal So when we're asked by business leaders to have a five or ten-year plan To include new architectures to go to the cloud to facilitate technologies for them I understand that the business owner in each of those stove pipes they Dictate what they need, but what they need is Not related to the technology so they're gonna give the business problem But they shouldn't be telling us how to solve that through technology so What happens is someone has to at an architectural levels make make the call whether it's Consensus with 15 organizations and 15 enterprise architects all fighting it out because if you got 35 departments and a budget Only 10 of them are gonna get what they need so who decides Which of those 35 tribe members are eliminated and the 10 that get it so there has to be a layer above that Manages and governs the strategic direction and if you have a strategic direction Then you kind of have to own it at an upper level. Thank you Thank you, I finally met somebody who had more lines of business to manage than me. I only had 34 And that's not I didn't just make that number up I had 32 when I first took on the post at Royal Mail But the McKinsey's found another two that we needed how you make 34 lines of business out of the Royal Mail is still an interesting question, but Absolutely, I was in a corporate role. I Was the chief architect across all those lines of business Governance was I have lots of scars of governance because 32 budget holders as well. So, you know, where was the power? But it's an interesting point because Could there have been a corporate level business architecture team with a business architecture responsibility? Well, at corporate level, they didn't dictate the business strategy for the individual business units They dictated this is the profit and loss we want from you. This is the budget return and on corporate responsibility We want from you, but within that you're going to have to kind of work it out To the great I oversimplify Could there have been a unit. Yeah, it would have made my job a lot harder a lot harder because I would have had an Internal fight as to how do we reconcile let alone? How do I get across all of the different light different organizations? So I Think it's a really really important point. So thank you. I just agree Well, I think to some extent, you know what you've described, you know makes one of my points earlier namely Whether it's been intentional or accidental or haphazard If the business views itself as being how many different entities 35 different operating units That appears to be an expression of corporate culture. So we believe we are not one corporate entity We are 35 separate corporate activities and In the business Should not be surprised when there are side effects and consequences of that particular perspective So either they fess up and own up to it and say yeah, that's the way it is And you know, it's kind of gets a little ugly and you know complicated or we want a different way You know a different a different platform a different path to get to some higher levels of performance and and capability and and one of the things that that I think particularly business architecture can help with is is Really help discern That finer point between what people want and what they need Because my opinion is people tell you what they want And that is not what they need and just like as many of you know that are raising children just because someone wants something does not mean they get it But you know if that's the if that's the way that the operating model works Then that must is a pretty explicit statement of we are okay with this mode of operation So, you know, I'm sure that you you know find, you know significant challenges in that particular perspective And but you know again, we want to be thoughtful about again over centralization You know, we do want to spread responsibilities out across the federated enterprise But we do need to have some way to kind of pull it all together in my opinion to really achieve that transparency because again I think the real challenge is you know the left hand of the business doesn't really understand what the right hand is doing and then when once all the dust Settles and they find out what their investments were and they go how come we spent, you know Three times as much money here doing something And did it in triplicate when we completely ignored something that we felt was more more important So it to me that leads more to again the business really needs to start taking Responsibility for the consequences of how they've set up their operating model and how that unfolds And I believe business architecture is the solution to that problem I've heard some very very interesting arguments on both sides and There's some fundamental problems being discussed here It's like if the business is not in the business best interest to the business architecture Why should I keep take up the bill and and I she needs the business to do it to fill out the artifacts anyway to build up But the models and capability model. So why is it she carry out the job if it's really business information? but I want to flip the discussion a little bit just and Move away from discussing the fundamental problems we see today into discussing How would the world when we detach business architecture from toga and send it to the business? How would the world like that work? Are we going to then be is it going to say here's what I need from you now since you're running business architecture I would like to hear you're taking that Sure, again, I think a part of this again is really state of industry Namely how many people that are you know the CEOs and on boards of major companies learned when they went to business school That enterprise architecture and business architecture was a key capability for delivering strategy Big fat zero right so in some ways I believe that this is going to be a battle of attrition to some extent again My pessimism and cynicism is that we just have to wait for some of these people to die and retire or Perhaps a little less morbid Their their companies to go out of business because they didn't understand how to do this more effectively So I'm hopeful of future leaders Bringing this understanding that with how can because most as you guys know most companies don't have a problem with formulating strategy They have a problem executing and delivering on strategy And that's what business architecture can really provide that framework for doing in Edinburgh last year at the toga conference. I was fortunate enough to bring along my main client who is BAE systems submarines and make nuclear submarines in the UK and They'd undertaken a business architecture project that was only business architecture Domain but took the enterprise architecture approach and used a positive omission Catch word in the toga specification to say well, we're not going to look at the technology and You know application function parts of it and when I say business architecture It was business architecture and information architectures. You couldn't pick the two apart So it kind of did that and it went through now in fact actually as they went through the project And I'll explain the dynamic of it in a second. So went through a project. There were parts which were Technology enabled Right, so people started going. Oh, well actually, you know, let's talk about the wearables You know things that people were comfortable when you're kind of going actually now We are down into some form of technology, but it didn't matter that it was kind of Merging a little bit. You had to interpret that that was the kind of piece behind it but but those people that did that that used toga to develop architectural vision and the architecture roadmap Were From the operations function I don't like saying there were business people because that makes it sound like the IT people weren't they're employed by the same business So they are all part of the same thing, right? But they were from the operations team. They were engineers And when I asked them and said can you come along and present, you know to the toga conference they went But we're not architects. I kind of well, you've just architected all of this, right? So I Don't know what you need to say to feel confident in front of this group that you are Architects full of what you've done But yeah, so that was an example and then if I can just add to that There are a number of organizations that I've worked with and I work predominantly in the aerospace and defense industries But but also automotive and stuff particularly engineering organizations where I found the engineering communities Using toga to define operating models and Yes, I think there is an issue about Presentation here is coming out of an IT function. This is what you have to do Absolutely, but that's an organizational dynamic communication, you know stakeholder management thing I think that needs to do I would say rather than preventing it I'm short too Wayne Hughes with Dell I'm just gonna do a reflection because this kind of reminds me of I really didn't live it I wasn't that I'm not that old but back in the 70s when you had your mainframe computers and you had your programmers and You had your hardware and your software and nor the twain should meet Well, all of a sudden somebody said wait a second. We need to know what they're doing Because we need the machines to be able to do their programs and the programming people went well We don't really care what you do over there just do it so all of a sudden it became an IT group and They melded and they became one and I it's just kind of a reflection of you know, what you're talking about now has been going on for 30 40 years and It will go on for 30 or 40 more years. I'm sure but that yes, there there is a Point to where you need to say We need to make a business decision rather than let's just let these guys go play Thank you well Emerging and the melding I think is that it's key because as you say it's a it's a divide That's useful to start off with but then actually when it comes together You know, you need it to kind of work together and I think That was part of the reason why in the proposition I was quite keen to see that you know there was this role of what is the CIO and What is the or whatever that supporting capability may be around that delivery piece? And I think that there is a key role around transformation and adoption of the latest kinds of technologies that affect businesses and the transformation piece going forward so I See that merging of capability Quite quite key. I'd agree actually so And I think I would you know generally agree, you know, perhaps you guys have you know gotten one of my Perspectives which is you know, this is just a natural evolution of where we're going as a profession as as the you know World's economies and businesses continue To evolve it and also, you know echo what Paul said earlier that There are people that are doing business architecture in the business But they don't know that it's considered business architecture, you know So for example, have anybody you know here have ever been through a reorg And usually that's like, okay, let me check what time it is right And in my opinion is that the people that are doing that are they're changing the business architecture The problem is is they don't have the skill set the enterprise you when they do that they use primitive tools like you know Cuneiform, you know clay tablets and smoke signals, but their intent is very similar to what we're doing So again, you know, it's it's just very interesting that convergence. That's kind of happening So, you know the separation that is often perceived I think out there is perhaps much narrower than than it really is in the real world It means the Sreeni pinch color. I work for a GM a great discussion So I think my question is mainly for Paul, but I would also love to hear Chris Comments on that. So if it were to own business architecture How would we get the business to? sponsor the strategic initiatives And that's the that's a whole EA goal, right? You know, how do we? Deliver solutions that work for not only today's requirements But also how they are the building stepping stones for the long-term solutions, right? So how can we get the business to buy into, you know sponsoring the strategic initiatives rather than Fixing, you know, it's just the tactical being in a tactical mode all the time. Thank you. That's a great point And the only thing I'd pick up in the in the question if you like is There's a need to change the change the bit that we say about it owning the business architecture Because that I think is the shift is it's not about it owning the business architecture It's about having one cohesive unit and I think that comes that and I call that enterprise architecture that Has business architecture as one of the domains now in a lot of senses that can come out of the current it Construct, but it's about up gaming what the building the game up of what the CIO function is if you like Just to kind of to illustrate what exactly and I think it comes back to the and I'm still in order the 35 business units Because 34 nearly killed me right nearly killed me and I thought it was a world record, but you know But you know if I take an example there 35 lines of business I don't know your business, but I'll make a sweeping assumption that You don't have 35 distinct sets of customers that those face off to Right, so if I look at in terms of the Royal Mail as an example, I would post mail receive mail and buy TV license and that was a you know That's not three different lines of business as far as I'm concerned with on one customer to them as far as I'm concerned So that's I need they you know single view of customer was an information Problem now is that a business architecture problem or is it a technical architecture problem? No, it's neither. It's both. It has to be solved in in one actually It's not one or the other and and but there is a credibility issue about The appropriate team of people the function of people being able to be responsible for that for all of it well, again, I think You addressed it very effectively Paul, you know the the although I do I have seen Organization they're taking this path where the IT architecture is really pushing upstream You know trying to push a noodle up a hill, right of trying to get the enter, you know The business people please will you pay attention? Will you take responsibility? You're killing us. You're just killing us But but there is a risk that again if that Is perceived as an IT thing that content and practice just is not going to be embraced and not going to be you know Accepted so we do need to be thoughtful about how do we how do we manage that transition? You know from from the dark ages to the renaissance as it were and and and really help the business people understand and Identify those key players within the business community that have that span of influence those So some of those technical skills and I think that's one of the things that frightens people about you know becoming business architects Is oh, it's very technical and a lot of people confuse Technical with technology because they're right. It is technical There are techniques for modeling and for doing trade-off analysis and assessment But you know they learned how to do amortization and derivatives. I mean that's incredibly technical stuff So it's not beyond there in a competency as business people Let me say to the one from General Motors. I have this question You know I was one of those people who are in the middle You know not sure that we business won't other IT won't because the reason I'm seeing is that the the line between IT and business is Disappearing slowly right so what role IT is itself is playing the role of the business You know because many cases IT is the business, you know IT technology is driving the business and and how do technology transformations plays the roles in enterprise architecture And one last question is that how do this in a collaborative governance going to take place because? Information governance across all these layers is very important Because even though we say business owns the business business knows the business because there is many segments of business They have to work with each other, you know, there's there is a place where it plays that role There's a place where business plays a role now how does so without without all that makes Is that really something you know one organization wants it or is it more of a collaborative organization between both IT and business? Well, ultimately, I think it's a collaborative thing You know as Paul suggests, you know who is actually the owner of things I think is subjected to reporting lines and and you know funding vehicles and stuff like that But I do I you know Even though I do believe enterprise architecture should be a completely business business driven sort of thing There's no doubt that there are going to be individuals within the IT organization that takes Responsibility for a portion of that, you know stack I do believe again the differentiation between business and IT is getting narrower and narrower and narrower And again, if you think about business, you know, you know represents the entirety of the enterprise to me That just kind of comes with that IT, you know as naturally kind of a part of that so If I try and pick up on on on what I heard you were asking I think one of the points it is for me that kind of reflection of business architecture within Would and and just to kind of give an example for me And this comes back to some of the other things that are being asked about that credibility piece and the join-up If I stood up and Yes, I've got an IT background and I said I was going to take over the business architecture for a business and dictate What was happening and and tell people what they could and couldn't do. I know I wouldn't last very long at all However at the same time if I was not able to hold a mirror up to the business and Capture what in real time and reflect it in some form of architectural Capture I'm going to repeat the word if I couldn't capture it in some way in order to be able to Align it with everything else that needed to be done across that whole set of stacks Then then I'd be operating blind So so I so I need it and therefore I think I've got a role that says because I need it I can facilitate it for the rest of the business So that's really what I'm asking permission for is just to be the custodian and a facilitator Not the person who says you can't sell that product You can't work in this way on this site or whatever. So I think that's one side and then the other part really You talked about technology driving The changes and I think that for me is Absolutely key, but but what I'm going to kind of throw in I've had a conversation fairly recently with a with an engineering community who make planes and The not IT people at all, but clearly very clever people and They were talking about what they needed to do from a capability point of view And that's a taboo word at a minute But anyway capability and what they need to do and how they were going to deliver that They could not do that Without dropping through the stack and talking about information and talking about functionality and about some of the delta Some of the changes they needed from a technology point of view You know that it is almost impossible for them to describe what they need somebody who's servicing a plane in the field Needs to do without referring to mobility as an example, which suddenly drops into the technology piece So actually even if you said they were just doing business architecture They need to look through and they do drop through parts of the stack. So you end up with this Commonities, which is why I say it has to be controlled in one place Last question In my opinion the this debate is a lot about organizational readiness and What you know what the organization wants to do what challenges are they trying to accomplish? Where does it fit within the strategy in the direction of the company? Okay, so that discussion that they kind of leans one way or the other and I want to hear your opinion Do you believe black like this is a black and white that business architecture should be in business or in it? Or do you do what they are thoughts that it should be it is organizational driven Number two is what are the consequences? Why does it matter? So Important thing is you're thinking about architecture. You're thinking about how does my investment align to what I'm building? At a very basic level, that's what it's about. Why does it matter when I say when I ask that why I'm not being You know critical, but it's more like question of what does it mean if you have the business architect It's in the business where the business architect is in IT. What does it mean? What are the financial consequences or strategic consequences that? Well, I think Ultimately, you know again, there may be some again historical organizational emergence issues about why you know does architecture emerge from IT or the business? but I ultimately believe in order for This to be sustainable and executable and really add value you we've got to have that rapport with the business, right? And I think if we set as set it up from coming out of IT We were automatically just making it even more complicated Than it could be you know in setting up that kind of adversarial battle of trying to convince the business that what we're talking about From an architecture perspective is worthy I really think that what we really want to do is you know elevate the value proposition to much more higher perspective in my opinion What the the the litmus test of the goodness of any architecture no matter what domain? It's at whatever level of abstraction is how well does it allow you to respond to change to me? That is the sole reason we have architecture with the idea being we want to design or architect our enterprises to Anticipate change and not have to figure out how we retrofit it after changes happen And we're trying to keep all the parts together so to me it's really a fundamental business Operational philosophy are we going to or you know set ourselves up for success in a continually changing business and technology? environment if that's the way of business moving forward then let's start taking steps to address those by really adopting an architecture based way of Looking at our business making in this investment decisions and operating our business Organizationaly is it does it depend on the context to a degree? Yes, because it does depend on how federated you are you know kind of the state of the businesses you say how mature they are and and really The practices and the things so just so yes, there isn't there is an element of you know It's not a one-size-fits-all granted however I've seen practices with a separate business architecture capability and an IT architecture capability and Inevitably You end up crossing over because if you're going to implement a system in the technology world You need to know what processes to put in somebody's going to start creating the swim lanes It might come from a third-party vendor They need to know information models etc and all that and that will be delivered by so you they're in that space Whether we like it or not they've got to do that and similarly in the business Architecture said as I said before you know that they might talk about capabilities and and and what what we're going to do Soon as you get into processes you're talking about what information is used who does it what roles are they performing? You know and what are they doing it with what tooling do they need in the widest sense? Whether that's a you know a system or a stock at wrench or a book whatever So there is there is it inevitably overlap Now if you can it for me enterprise architecture as an approach if you can get the two people who Accountable for making sure that all joins up Absolutely harmonious and agreeing to use the same standard the same metamodel the same taxonomy You know the same way of working at the same rate of change and have the same dialogue with everybody else across the business Great chances are I can't see that happening right, so When I come back to it as I say I think there needs to be something that coordinates and puts all that together They you can have specialisms you can have preferences, but that's to be one practice that says For this enterprise we will have one standard One way of capturing our information and reconciling it. I don't mind if the business architects take the lead within that team For being responsible for making sure it reflects a business model or whoever however you want to do the construct underneath But it's about how you make that Join up. Otherwise what happens is You will end up with as I've seen somewhere else, you know a chief exec going I've got two single a4 pages of my business on a page I love the ideas that chief execs think the whole business can be boiled down to one page and Oh open-floor slice and Trapped the fact that they can actually They can actually You know Compete and say well, which one is the one that that I should Should use and I think that should just come from one place rather than two come up. Okay, so here we go We're now on the summation portion of this venture Paul you now have Five minutes at my main point here just to kind of add something slightly different Intended rather than just repeating some of the stuff that I've said is I'm very fortunate. I in my work, I get to interact with a lot of CIOs from different companies and This is a gross generalization, but broadly tends to be the kind of way that I'm seeing seeing this happen at the minute is the CIOs have got two Agendas and these agendas are getting two different agendas two different styles mostly these days and They are being driven more and more to extreme ends of this sort of approach By the disruptive technologies we're seeing what's happening in business models You know the constant change that I don't need to tell everybody about but that and what I'm what I'm seeing is there are those CIOs who are recognizing that their Team's role their functions role their responsibility for helping drive business transformation is Absolutely paramount right and they are the people Nothing can be done in the model and everything is driven through that they have a major role in delivering that transformation and Then there are other CIOs who are whose remit is very much about Lowest cost provider if you like right so being a service provider and and it is getting to the point where you can almost say It's one or the other right? It's a it's a ridiculous over simplification But it kind of tends to work in most places they go to in the former So this part of this role What we're really seeing there is that the office of the CIO has to up its game To to really help drive that business transformation It has to have business architecture inside as part of that capability in in in my Belief to be able to deliver the promise of that business transformation because nothing moves without Technology it and you look at what technology is doing now to business models not just to you know the kind of efficiency base So Anybody who wants to operate in that latter model and most CIOs that I know want to be in that space They may be forced to be in the rationalization space But any that are in that space are looking for that to build their own credentials and their own credibility and They need to back that credibility up with a full suite of enterprise architecture Capabilities all housed under one place. So that's my summary All right, Chris you now have All right, probably I won't need all the time as well I think we've had a great debate exchange of ideas But I I'm still on the side that so unfortunately mr. Hulman. I haven't swayed me That the business architecture should be owned and governed by the business for issues of credibility issues of rapport issues of continuity issues of funding And ultimately and you know the IT organization is a reflection of the business. So when the business goes Hey, how come you know, we're so fractured and we have this redundancy and it's because well That's because the way the business is and so we really need to provide that overarching, you know umbrella the business needs to take responsibility for it We may need to provide some again surrogacy or babysitting along the way that till they you know build those skill sets But I guess the thing I'd like to throw out there is that in many ways it is really often are you know charged with efficiency? You know, so how can I make things, you know more quicker more affordable more scalable? But there's a there's a finite capacity for how that's really going to deliver business results And that's really I think the flip side that business architecture delivers Which is how can I actually transform my business to be more effective and that's different than being efficient? And I think without business architecture setting that stage the organizations are going to continue to struggle So that's all I got to say about that well the result is a slight a little bit more on the Against one one additional person on the against position Three less on the four position and that I'm assuming that means a few more on the abstains