 Please give a warm welcome to Chris Ford. So I want to apologize in advance. I've been struggling with the flu since Christmas and allergies since I've arrived in the United States. So hopefully my voice will maintain itself throughout the presentation here. I'm not gonna take you through a bunch of models and architecture diagrams. I'm gonna talk a little bit about the genesis of this conversation that I've been having around the globe, both in Asia Pacific, Europe and North America about the value of reference architectures. Steve mentioned my background here. The only additional thing that I would mention here is that amongst other things while I was working out in the industry, I was responsible for both the reference architecture program at American Express and also for the utility computing strategy as it was back in 2006, 2007. So some context. The genesis of this conversation actually resulted from me and my responsibilities to go around to organizations globally, talk about the value of enterprise architecture and to try and bring organizations into participating in development of submissions to our standards process out of various industries. And while I didn't get a huge amount of pushback, typically I got some very, very pointed pushback about enterprise architecture, the lack of value in this in this day and age, in this digital transformation age and the lack specifically of value of reference architectures which are dull, static and irrelevant. So the reason I'm standing in front of you today obviously is to try and refute that. Now whether I am successful in that or not, you will be the judges, but there's gonna be an enormous amount of material over the next two days covering the details of reference architectures in applied areas. I'm gonna try and set some context for those more detailed conversations. So the open groups vision around this information flow revolves around supporting business improvements. It's not about the technical standard delivery, okay? Looking to move a business into its desired state, addressing its needs, and we provide open standard components to that landscape. So with multiple areas, sources of information, secure delivery of this information and providing appropriate context to the people and for the systems of those enterprises. Now this is not at all new but was inspired by the interoperable enterprise business scenario that one of our fellows, Terry Blevins, led back in the day, okay? And it's still germane today, still very relevant. So on a personal perspective side of things, my view is that enterprise architecture is actually a management discipline. And if you go to Dr. Robert Winter's work out of the University of St. Gallen in Switzerland, you'll see some supporting research in this space. So managing and identifying the fundamentals of your enterprise and its ecosystems as a complex system, not as an IT system, creating a formal description of your organization, developing principles, guidelines, and scope. Now this term, principles is banded around a lot but outside of technology and enterprise architecture, there's a phrase that goes along in the martial arts area and it goes like this. You understand a technique and you teach a technique, the student understands the technique and apply the technique. You understand a principle fundamentally and apply the principle. You understand a thousand techniques and the application of a thousand techniques. So glossing over the importance of principle-based architecture is a perilous activity in my view. So you can use this discipline to manage the complexity of your organization. You can develop appropriate plans and the key thing is a lot of times when we see the traditional references to EA and architecture in general, you see this model of buildings and stuff like that but architectures and ecosystems are dynamic. They're always changing and responding, they're not fixed things and the other trap that people fall into is thinking that the reference architectures are also fixed but these are just reference points that change over time and they need to be managed and updated on a cycle that makes sense to the organization and to the industry for that matter. So what do you do in enterprise architecture approach? Vision, principles, requirements, constraints, gaps, implications, things like this. Okay, plans and iterate, learn and execute on best practice methods tailored to your company. Now an accelerator for getting to that point of a customized architecture program and practice for enterprises is a product of the open group, actually two products of the open group, Togoff and Archimate. Now these are enterprise architecture standards. They are used by world leading organizations to deliver business value. Now, we had invited a person to speak tomorrow who's actually the chief architect for the China State Administration for Customs. It's unfortunate, apparently, that Wang Xiaong won't be here but he would demonstrate for you how that organization uses Archimate in real time to manage the data centers with a visual interface that drives down to the HVAC systems in their data centers. He would also demonstrate for you how they use Archimate as a fulcrum to integrate the disparate enterprise architecture practices that they have in the various agencies and through the Belt and Road Initiative that they're driving across Asia and the globe, for that matter. So the point being here that this architecture modeling reference stuff is not some sort of static thing. It is something very, very dynamic and you will see other examples of that in the next few days. Now, one of the benefits of having a open standards developed method and framework and modeling language is you tend to insulate yourselves to some extent from proprietary methods and approaches to doing things. Now, when you end up customizing something, of course you've made something special for yourself but the starting point is not an isolated product from a particular vendor or from a particular consultant. So combining industry practices with your own organization's best practices is a very, very useful model. These are proven and tested and effective accelerators and to a certain extent you can help your organization and your suppliers speak a very similar sort of language. You can utilize resources more effectively and you can demonstrate ROI. So I'm asserting a lot of things here but I do have materials to back this up. We can have that conversation over a beer this afternoon or this evening, whatever your time zone is, okay? So here is a graphic which you saw on the slide intro about the current adoption of Togaf. Now, the number down in the middle there is like 70,000 plus people certified. So this is not a proxy number from the open-route perspective. This is an actual stat. But if we talk to the training channel, both the official training channel and the unofficial training channel, that is the gray and black markets of training that go on around the products that we produce on an open-stender basis, it would be no fib to tell you that that number is probably closer to half a million people trained in Togaf, okay? And of course, you know, close to a couple hundred thousand people have paid money to buy stuff. Okay, so why, from a contextual standpoint, are people using EA? Typically there are two basic activities going on. Delivering new capabilities at the same time, optimizing investments. Now, the investment side here is not simply driving down costs, cutting headcounts and moving on with a leaner organization. Most often what's actually occurring in an organization, I'm not saying that's not happening, what is normally happening is a reinvestment of the savings of efficiency in other areas of the business to drive growth, which is very different than just a hard bottom-line numbers approach to things, okay? And the closest thing you're gonna see to an RA here is this diagram, block diagram, which is typically what people tend to think about when they think about reference architectures, but this is for an architecture practice and is a published set of material from the open group out of the Togaf library, which is something you should check out if you haven't. So if you think about Togaf as the book, you're kind of missing out on the several hundred of other applied architecture documents that are in the Togaf library that may or may not apply to you, but you should go research if you have a particular problem to solve, either in cloud computing, SOA and microservices or other environments. So just as a reference point, it's fairly easy for us in the open group to point to concrete examples just on the presentation basis that have come through this kind of forum over the recent years of industry sector examples using enterprise architecture and reference architectures to good effect. And by that I mean transforming their businesses, operating efficiencies in their IT function or wherever. So I just wanted to add here some observations on digitalization and transformation. As a result of these conversations, I've been back through not only the materials on digital transformation that we've presented here at the open group, but other reading obviously. And here are the observations. These are the phrases and buzzwords and things that come up almost universally across all of these presentations. Leadership and vision, perspective, transparency, planning and tough choices made well. Cycle times that are fit for purpose with continuous learning change, minimal viable product, minimal viable architecture and a tolerance for failure. Societal and market force driven, that is that what's going on digitally in our societies is not a technology change solely. It's actually changing the way society operates and thinks. And that these technologies are applicable both on the B2C and the B2B side and in other areas as well. Platforms and ecosystems are increasingly fungible. That is to focus on your own platform and your own ecosystem is actually short-sighted. You have to do that, but you have to be looking at this issue of interoperability as well. And that's why I started with the vision of the open group around interoperability and boundaryless information flow. Continual references to value chains, value streams, capability services, APIs, governance and the management to outcomes. Culture and workforce readiness, integrated multidisciplinary teams, a way of working and competences, cybersecurity, data concerns, information, automation and scaling. Debt, degradation of systems, disintermediation and a collapse of business models. A need for a sense of urgency and change. EA, Lean, design thinking, microservices agile, DevOps and modeling. Open standards, private public partnerships done well and give back and validated learning. Now the second bullet from the bottom here is one of the areas that organizations and ecosystems come to the open group to get help. This is because we have demonstrated year over year our ability to operate public-private partnerships for good outcomes. Now that's part of the process, but what also is going on here is the subject matter experts in these areas are the people actually doing the work, not the staff of the open group. But this is a place that can deliver in a timely and rapid fashion, in fact by those standards organizations measure, time to value. So I borrowed extensively from some colleagues and publications from the open group and they forgive me for reusing your material. Borrowing. The Chinese is on there because I do this presentation globally and I didn't want to screw up the formatting. So I'm not requiring you to read it if you can. Congratulations. All right, so this is a publication, the Seven Leaves of Digital Transformation from the open group. And I just want to push through this fairly quickly to say, okay, in the business transformation, I've tweaked this a little bit. This is where you start to see the phrases around value change capabilities, governance, management outcomes, and EA lean and design thinking showing up a lot. This is not exclusively where these terms show up, but this is generally where they show. Customer engagement and experience, open standards, give back, public, private, done well, design thinking, product to service, digitalization, societal and market force driven, and the target interaction environment. Cyber security, data information, automation, scaling, APIs, microservices, and DevOps, exposed out of the core IT function to these other areas and to the ecosystems. We have a cycle time for purpose. You have culture and workforce issues. You have multidisciplinary teams. This is, you know, before we were talking about digital transformation, we used to talk about these same issues in the EA space and in fact, if you look at the first three or four pages of the TOGA specification, it tells you that this is one of the primary things you need to pay attention to. But it's not an easy thing to do and it's not an easy thing to change, culture. Leadership, vision, perspective, transparency, planning and tough choices made well at the leadership level. And then you've got the ecosystems and business models here. So I would encourage you, if you haven't already done so, to go pull this digital transformation white paper down and go through it. It's a valuable piece of work. Now, in all of this, in this digital transformation stuff, we've got a workforce issue. You know, geographically, the demographics show that in certain regions, we have aging populations and a lack of resources available. This Harvey Nash KPMG survey highlights that there is a, in the bottom left corner of that square box there, three roles, big data and analytics roles, business analysis roles and enterprise architecture roles are in a world of hurt. They just aren't the people out there. Now this kind of flies in the face of most of the conventional wisdom you hear about the death of VA and reference architectures. Given that Henry's architecture in 2017 was the fastest growing job category globally. And you can see that the shortage of these resources is actually a global problem. North America is actually in the best shape. Whereas in Asia Pacific, there's a serious shortage of people. So positioning reference architectures, what I wanted to do was to set, try and set the context from a personal perspective of what I see the value of enterprise architecture to be. Because if you're not even willing to approach that idea, approaching the value of an artifact delivered out of an enterprise architecture, such as a reference architecture, is a dead on arrival concept, right? So why are most interested in embracing reference architectures? Well, industry-wide problems are not the sole responsibility of any one organization. And they should not, perhaps, cannot be solved without engaging rivals and partners in the solution to those industry-level problems. And that pretty much is the reason that the open groups exist, that the open group exists, is to bring a community together to solve that class of problem. To mitigate these industry-wide challenges, a practical solution is to develop and use common frameworks, methods, and architectures to create something of mutual benefit. For organizations that aren't used to operating or thinking in that way, this can be really anathema to them, okay? There are issues of IP, and there are issues related to antitrust, and there are issues of trust trust and competition. Well, the open group actually helps to manage that and does so quite well. Now, what I'm positing here is that the major, well, a major benefit of developing and implementing open standards-based reference architectures is that they distill business and technical value. They distill and enclose it, and one of these examples of distillation occurs through the practice of enterprise architecture. Now, an architected approach to solving business challenges is typically represented as one of more views, models of an RA with its associated services. Now, this is the crux of why I was confused about why people were pushing back on the value of RA's, and they were pointed to digital native companies as an example of why these ideas were now dead, both architecture and reference architectures in particular. The problem I had was that when I looked around into the industry and to these digital native companies both in China, North America, and Europe, what I saw was that actually those companies were monetizing reference architectures and that these monetized reference architectures in the past decade had become big business and were fundamental to the transformation that many organizations were undertaking. However, the difference is that when I was working on a reference architecture program inside a particular enterprise, I wasn't thinking about branding and monetizing it except to the leadership and the business and technology people who had commissioned its delivery. I wish, I really, really wish that back in the mid 2000s, 2007, 2005, around that time frame I had gotten this a little bit better, okay? So if you look past this, you see that in fact at the core of what's going on here in large part is enabling the scale of transformation that we're experiencing through these rebranded reference architecture and services. So the intrinsic value that's distilled solves both technical and business problems and the big difference here is the way these solutions are being made accessible in seemingly simple ways that masks and effectively manages the complexity that organizations want to move out of their organization to take advantage of operations of scale and capability. So you get these reference architectures with your credit card over the internet today and use the realization of those services to accelerate your time to value. Now granted, the example that I'm giving you is primarily an infrastructure oriented example, but it holds water. So the value in coming to an organization or a consortium like the Open Group is that we've worked out a way to manage the co-operation issue, okay? The technology sector around co-operation has paved the way for enterprises to work together to collaborate on developing broad solutions in multiple areas. And we are seeing an increasing number of groups of enterprises, industries, and multiple industries coming to the Open Group saying we have really significant problems to solve and we want help solving these problems. Now they're not looking to the Open Group staff to solve these problems, but they're looking for an environment in which they can effectively solve these problems. And some examples of those are at the bottom bullet here. Current type of EARA type of activities underway or delivered in the Open Group are microservices and SOA, cloud computing, the future airborne capability environment revolving around avionics for war-finding machines, the exploration, mining, metals, and minerals deliverables. Newer stuff around process automation is getting into food and beverage, oil and gas, and the farmer area. Imagine things that are being done here stretching across those multiple industries to deliver value. It's actually, in my view, it's quite remarkable. We have upcoming activity with the commercial aviation area that you'll be hearing later from Cap Gemini and Lufthansa on that. A little bit different from the Berlin conversation. You have IT for IT and the sensor environment. I think this is probably the newest one we have is SOSA. So I'm gonna go back to an outside the consortium viewpoint here as a case that is, and I really need to emphasize this because be standing up here going through the material I'm gonna go through is gonna piss a lot of people off. And can you edit that term out of the video? Solly, please? Okay, it's a case. It's illustrative to try and underscore my point. There are multiple cases that I could have put up here and it's not an endorsement, okay? So exited from a common commercial framework outlining what it means to be well architected. You can scoot around the internet and pull who this actually is if you want. Operational excellence, security, reliability, performance efficiency, and cost optimization. The value proposition they present to you is not only just those kind of techie kind of things, but learn, measure, and build using architectural best practices per the same commercial framework provider. Build and deploy faster, stop guessing. Don't worry about your capacity needs, your tests, your systems at scale, using automation, experiment, and build cloud native architectures. Lower or mitigate risks. Understand the way you have your risks in your architecture and address them before your applications are put into production. Make informed decisions about architecture, trade-offs, the impact of performance and availability on your apps, and business outcomes. Learn best practices, access to training, white papers, provide guidance based on what we have learned and through review thousands of customers architectures on our platforms. If you put this stuff side by side with the value proposition the open group puts up, you'd see a very similar sort of relationship to me, except that we don't monetize the reference architectures the way this organization does. What we do is we seek to have our members monetize what they produce here as a result of an openly available set of materials that are transparent. And they advertise architecture IA solutions by application industry and many are listed. Now, if you go to their careers website, the number of open solution architect roles they have worldwide current as of midnight last night is 591. The interesting thing about this number is that as I've watched it from roughly November of last year through this year is I've never seen the number on their website on a monthly basis drop below 450. So the number's going up, not down. I've needed solution architects. That doesn't include what they class as enterprise architects who go out and talk to the C level folks at the organizations that are trying to persuade to move to their platforms. And here's the characteristics of their solution architects. You'll build architectures and provide, wow, prescriptive guidance from a digital native company. Wow, who would have thought it? You'll be an individual that can demonstrate the ability to think strategically about business, create technical definitions around customer objectives and complex situations, develop solutions, strategies, motivate and mobilize resources as well as deliver quantitative results. Yeah. So the reason I started down this path, as I said earlier, was I got some pushback and quite virulent pushback from folks about the value of enterprise architecture and reference architectures because the digital native companies were changing the way we do business. Well, they may be changing the way they do business or we do business, but they're not changing the way things need to be done necessarily. Okay, there are certain management disciplines and best practices that are useful no matter where you are applying them. And so, assuming that because they are occurring in another organization, and that that organization is doing these things and they're not doing what you would be doing if you were trying to do it, is wrong. What I mean by that, because it was a little bit convoluted, is that EA practice and reference architectures are necessary disciplines and skills and deliverables, whether you're doing it in your enterprise or you're giving it over to a third party. And the reference thing that I had about capability versus value, actually on the right side in the middle of that reference model is a category of enterprise architecture, discipline and practice that talks about managing third parties, okay? And that actual use of enterprise architecture is a very sophisticated use of reference of enterprise architecture. The interesting thing is that I've come to believe that it's actually the third parties that are now using that sophisticated discipline to manage the enterprises. As they move your business and technical capabilities out of your enterprise, it's not inappropriate. I'm just saying that the model for that was identified in a white paper in the open group about eight years ago, okay? So what's the point? If you haven't figured it out already, I think there's value in reference architectures and enterprise architecture. It's intrinsic, but it must be unlocked in the applied solution to business and technical problems. The objective is not to produce the diagram, the models and things like that, right? It's an enabler of rapid time to value. It's not a barrier when positioned appropriately and supported by skilled resources. And the development of these RAs may be done differently these days, but it's still an absolute necessity for it to be done effectively and clearly. It does require a particular discipline to develop an appropriate services to support it and that applied an instantiated level. And when developed and delivered by industry SMEs, by an open standards process, it has enormous far reaching value. And that's the primary reason that more industries are coming to the open group to deliver this kind of value. And this has actually been going on for more than a decade. It's been changing most of our industries for a decade. It's just kind of been a, it seems like yesterday, but then the years seem to fly by now that in a way they never used to, oh God. Okay, so RAs are far from irrelevant as is enterprise architecture. And when I'm talking about enterprise architecture, I'm talking about this in the context of architecture as a discipline with specializations. So from my perspective, an enterprise architect is just a specialization of a management discipline that includes technical architects, application architects, a whole bunch of skills and disciplines. And there's, for a digital natives and digital transformation, the open group is involved in developing a digital practitioner's body of knowledge, which is probably gonna be dealt with here also in presentation. So I would invite you to look for that as well. So what I wanna end on here is to ask you to, it says here submit your candidate RAs to the open group so we can help unlock that value. That's a little bit of a misnomer. What we're asking you to do is to submit your business problems that may be solved by an architected approach to the open group. But come with your colleagues, come with your partners, come with your industry rivals. And we can help you unlock that value. Thank you, that's pretty much it. Nice job, thank you, thanks. Impressive list of industry sectors deriving value from usage of EA and RA. Is there any sector that's obviously missing that we should target? That's a really good question. One's that need to fill the need for help. Yeah, I think it's really kind of situational. From my perspective, the answer is it's really kind of geographically oriented. Okay, the level of maturity that is in the North American and European region about enterprise architecture and certainly in let's say Australia is really sophisticated. It's picking up speed in the Asia Pacific region. But interestingly, I'll be going to the Philippines in a week and a half's time for an AEA event there. And there's an entrepreneur that presents there. He's actually based out of Paris, France, but he's a native of the Philippines. And he's a serial entrepreneur and has made a lot of money through his business ventures. And what he's identified is that for his company as a lean kind of operation, EA is fundamental. He's actually makes a very clear point that yeah, it's gonna get in the way of the application developers who want to run off and do things, but he's got a business problem to solve, not an application problem to solve, okay? And he's applying that to healthcare imaging, these sorts of things. So it's situational. I think that I see a lot of push in China, in particular for high tech manufacturing. And in the Philippines, those folks are trying to modify their approach to governance and governmental activities. And Palab's gonna be talking a layer about the NDA activity, which is gonna be immensely clear and specific and valuable. So yes, of course, there are situations where the industry or sectors are not up to speed, but from my view, it seems to be geographic more than industry-oriented. Okay, so a related question. What would be the suggested first steps to start an activity for building a reference architecture for a specific vertical, for example, the electrical sector? By electrical, I assume you mean upstream and downstream generation of power, right? Nuclear, coal, whatever. Those already exist, but they don't exist through this forum. They exist on a proprietary basis. You can look to the European Union Standards for material on this. You could look in other areas. If you're interested in getting such an activity underway with the open group, what you need to do is simply come with a problem statement to the staff from an individual basis if we can help you then do outreach to other folks in your industry or you've already had this conversation with the folks in your industry. The problem statement, the value proposition, we will help frame that and then try and get the wheels under it to get it moving. What are the best practices for applying a reference architecture to fit the specific needs of my organization, applying the reuse principle, but at the same time keeping the right view of delivering value to my stakeholders? Which is very similar, well, some more specific than another question, which is where is the guidance in our industry on how to apply reference architectures? That seems to be the main challenge. That's a very interesting point. So in the cloud computing reference architecture material that's already been polished and the SOA and the stuff that's been developed for microservices, I know that there's guidance related to what's produced by the open group. In fact, as the operation, the phase consortium, the current operation of the open process automation consortium calls out, I believe, guidance on those specific things as delivered through the open group is a requirement to go to market. So it's a little bit difficult for me to comment on what's situationally necessary for a given enterprise. Developing that material, examples of that material is available from the open group and if there is a specific set of guidance that needs to be developed for your enterprise, participation in the open group is a way to deliver that. There's a huge political thing that goes on with reference architectures, right? If it's within your enterprise, there's an enormous set of political battles that may go on. You not only have the idea of reference architectures, you have the idea of reference implementations on which facets of the architecture do you deal with? How do you sell that to your technology organization? How do you sell that to your executives? So it's very difficult to comment here on just kind of a generic approach to doing that. I'd struggle, to be honest. Right, and we're out of time, but I'm just gonna pick one more. Is EA and our reference architectures, are they moving out of IT? Where is the right place in an organization? Oh God, what a great question. Back in- If we had more time for that. Yeah, I just give you an anecdote. Back in 2006, I sat in the office of the marketing vice president for one of the areas of American Express, and he was arguing the toss about me, about why I owned that program and why he shouldn't own it. So what I said was this is a management discipline. It's not organizationally oriented necessarily. The question is whether you see the value of an architected approach to things and where that can be promoted, funded and politically driven is the right place for the program. Chris, we'll leave it there and move on, but thank you very much. Good job.