 Okay, good morning, ladies and gentlemen. It's a great pleasure to be here, introducing our panelists. Mark and Iver have already been introduced. What I'm going to do is ask our two additional panelists to come up here. We have Harry Hendricks, who's the business architect at HPE Enterprise. Harry's also in the EMEA office of the CTO at HPE, and he initiated the business architecture workgroup that led to the open BA standard. Harry, could you join us up on the podium here? And then the fourth panelist is Mike Lambert. Mike is a fellow of the open group, and a former CTO of the open group, and one of the pioneers of the TOGAF standard. And when we're talking about pioneers, we mean back in the day. Okay. Please welcome these gentlemen up here. We're going to feel some questions. Can you guys pick a chair that clusters so we can get everybody on the cameras? You're not sitting down. I'm not sitting down. I'll move over then. All right. So in having brief conversations with the panelists leading up to this meeting, what I said to them was, this is really a high-energy topic, how you develop open standards. So one of the things that we would like to do is actually engage in a dialogue with folks about the most recent standards that have been developed, how we get there, and what the dynamic is for creating an open standard, okay? So in terms of background, we're not going to ask you to write down questions. If you have questions, there's a microphone in the middle of the floor, okay? We would ask you to come up and queue up. No doubt the line will be out the door. We are going to also answer questions about the last presentation from Ivor and from Mark about the Archimate, the newly released standard. In developing an open group standard, there are certain principles that are followed and guiding the standards process. Now, all of the material for developing a standard through the open group is published on our publications website. So the first principle for the open group is openness. That is not only being open in behavior, but being seen to be open by publishing the material and making it available for everybody, okay? So public availability is also a very important approach for us and leads to adoption. In adoption, one of the things we consider is that there's no legal impediment to the adoption of the standards. So we manage the way in which competitors meet and what they're allowed to discuss during the meetings. The staff manage that. We also try and respect the confidentiality of the materials being developed. Understand that we have more than 500 member companies in the open group at some point in time collaborating around the delivery of their IPR to the open group. And we need to respect the discussions that occur in those spaces and how that information is transferred to us for development of standards. The process is necessarily timely and deterministic. So we put a process in place that allows for relatively rapid delivery of standards. And the approach we take on a daily basis is one of consensus, not of voting if we can avoid it. But all of those contexts are something that are managed and worked through with the folks that are on the stage with me here today. So firstly, I would like to ask, are there any questions for Ivor and Mark about the standard presentation that they made just now? If there are, please put your hand up. Could you go to the microphone, please, sir? For Archimate 3, how big is the vocabulary and how much of it do you need to be to know to be conversant in Archimate 3? How many symbols? How many symbols in total? If you look at the total set of concepts, I think it's about 16 now, but there's a lot of commonality between the three layers. So you have things like the business process, application process and technology process. The actual set that you have to learn is a lot smaller than these 60 different concepts. We started out with, I think, about 30 in version one, and now it's up to 60, but with this large overlap in symbols, in definitions. So that's the total size. And then there's a number of relationships as well, of course. The only thing I would add to that is that it's all online. The entire spec is online, and the spec has a table of contents. So it's very easy to see what's at your disposal and then click just in the table of contents and then just click on the table of contents link to find it. So even if you only know a few of the concepts, you can actually become productive pretty quickly. Maybe also to add to that, what we advise usually our users in practice is that you shouldn't start using all the concepts at the same time. Usually you grow into that. You start with a smaller subset to really address the issues you're working on. Archiment is, of course, a language that it's intended for a broad audience. So it has quite a number of concepts for different areas of the architecture. But in practice, for a specific use case, you won't need all of them at the same time. Do we have another question from the floor? Yes, sir. If you have a question, you can just queue up. You don't need to wave your hand. Just wondering about the physical layer that you introduced. It looked to me, it's more like a supply chain or a value chain type of representation. I just wonder, have you considered doing it that way versus introducing a brand new layer? The physical layer underneath the technology. So I saw that you have like, you know, how different things happen, like a process dependency or step dependency, right? Yeah, well, the main concepts in the physical layer, the new concepts for these physical things are equipment and material and facility and distribution network. So they're really about the physical stuff out there that's used in a factory or in a laboratory or for the Internet of Things. So it's not really a value chain kind of model, but you can use that in that context. Yeah, I mean, I gave a supply chain example, but if you saw also in the Connected Health case study thing, you know, there was not only the ordering, but we were also showing how the device is used with IT infrastructure for data acquisition. So supply chain is just one of the many ways that you could use the physical layer. I'll use an example from a steel factory in my presentation later today, so that's really physical manufacturing. So how much of that is really architecture versus specific design of how things work flow? Well, you could have, we could dedicate the whole day to having a debate on the distinction between architecture and design, but, you know, as an enterprise architect, my job generally is to clarify the business processes, is to clarify what's going on, and for that I use, you know, I use that, and so if I were working in an area where something is physical, I may not be the inventor of the device or the inventor of the manufacturing process, but it's important to clarify it so that we can, so that we can develop the information systems necessary to support it. And that's what I see using the physical layer for, at least at first. And typically you would link down to some more detailed specification of this physical world in another language, like you would for software to UML or for processes to BPMN. For the physical world, there are other design practices, and you would link to those, and Archimedes tries to be an umbrella and links things together, but it's certainly not going to replace the design world of physical machinery, for example. Thank you. We have another question on the Archimate presentation. Okay, I want to start off the questions relative to the standards process and the materials that have been delivered and are being spoken about here today. Actually, Mike Lembert, I'd like to ask you a question here. What we've seen are presentations of the content of the standards and use cases of a standard, and the impression may be that the standards are the only thing that get produced. Can you take us through a little bit what is there beyond the standards that are value to people? Wow, that's a good question to start with, isn't it? The most recent standard I've been involved with probably for the last five years is Togaf. And if you just read the Togaf standard, it's not really very helpful to anybody on its own. Because what it is, it is a basic, agreed, common way of approaching enterprise architecture. What you need is help. And what you need is skilled people, predictable tools, and guidance. Surrounding most of our standards now is a certification program, and the certification program provides some statements that there are people who are skilled in using those standards. Around a lot of our standards, there is software. There is some kind of tooling. Certification makes statements about that tooling, but much, much more important is a question of guidance. Because Togaf is great. I've been involved with it for many years, so I think it's great, but I would hate to have to use it without the body of knowledge that's built up around it. Something that I call the Togaf ecosystem. Everybody who uses Togaf has to make some decisions about how they're going to use it. And what's really valuable to us is that a lot of those people have taken the time to document how they use Togaf in a particular environment. So the ecosystem that surrounds it is much more important in many ways than just the underlying standard. So as an illustration of that point, I mentioned earlier that the standards themselves are published on the website. Adoption is an important thing. The case studies that you're going to see this week as a participant here in this conference will be published on a link from the agenda for this event in the history of events. That means that in order to foster adoption, we make available to all attendees all materials presented here. And with your registered ID, you can get access to that material which constitutes a part of the ecosystem that illustrates how other organizations, whether they're members of the open group or not, is not relevant. The adoption is what's relevant. And the method of adoption that occurs in your industry or other industries is one of the powerful things that is available to you through engagement with open standards. So as a reminder, in about two weeks, using your registered ID, you can come back to the open group website to this event and gain access to all of the materials. This is true on an ongoing basis for members. Okay? One of the interesting things around adoption is also that we frequently see things popping up in the most unexpected places. So as an illustration to the work that Mark and Iva have put in to the Archimate Standard, the customs authority in China, unbeknownst to us and not members of the open group, implemented in Beijing last year, how they have taken an adoption approach for an open standard, they didn't ask us about it, they just went ahead and did it, and then they drilled down through the connectivity of the cloud infrastructure they've implemented, and they showed us how they use that standard to help them manage the HVAC function for their data centers. Not the servers only, but all of the infrastructure related to managing their data centers. So the power of the open standards is that you can retrieve them and use them independently to add value to your business. Harry, we have heard a lot today from Jeff and Aaron about business architecture. How does the open BA standard address the issues that Jeff outlined? And if you could, would you talk a little bit about the way of thinking, the ways approach and the way of thinking in particular, because it intrigues at least me? Yes, I think that's a very interesting question, because what Jeff Scott this morning did in his presentation, he showed very, very well how diverse are the diversity of organizations is and their thinking. And I think one of the most important parts of talking about standards is talking about the way of thinking, because that determines what the standard is and what it will be and what it will resolve. If the way of thinking is not connected, then you have a problem to communicate with each other. So when we trigger this to the business architecture standard, then I think the history which will be shown this afternoon a little bit in the track as well. We will have several presentations which will get a little bit deeper in the different aspects, but the way of thinking will be also shown that it is kind of, at least for me it is, and I think some may confirm that as well, it's not the one avenue road to this standard. It has been many avenues and the point was there was now a certain point in the time that we could say, okay, these avenues, they all seem more or less alike. Just people don't know yet. And that's how we started two years ago. Okay, let's try to get sufficient mass to get this process started and to do the alignment for this. And that started with the way of thinking, by the way, because I discovered that a few years ago there was an article which wrote about what are the structural issues of enterprise transformations. I thought, well, every enterprise needs to go into transformations nowadays and even more accelerated than these. So if we could connect this with the business architecture, that would be great. And they really had spot on three structural issues which they identified as, that's the problem we have to solve to become more successful in strategy execution. So the three are and will be elaborated this afternoon as well. One is the systemic view of transformations. Many things are dependent on and many other things. So how do we explain to each other how this all relates to each other and what the impact for me as a stakeholder would be? Then the second one would be consistent communication. If at the beginning of an initiative I have an idea and I want to get it done at the end of the transformation cycle, in the 90s there were two years beyond the starting and the end point, nowadays it may be a scrum, but still the problem is the same. It has to be consistently pulled through that transformation cycle. So the consistent communication is very important. The problem is that usually during the process the people who had the idea are not the same people who design or develop it, so we need some kind of communication and structure around this. And then the third one is also to align these different stakeholders and that relates more to the first part of the transformation cycle itself. So we have to get from idea to a vision to a strategy and how do we get aligned those stakeholders who don't have time to discuss too much with the people who have to mobilize this. So you really have to be prepared to get the alignment of stakeholders and I think that's exactly the point where the open business architecture standard can help you. It will enable and guide you to create the views and the different structured narratives which can easily be understood by normal people and not designers or modeling techniques. And I think these are the most important part of the business architecture standard, but driven by we have identified the common problem and that's the way of thinking. Okay, the response that Harry just gave I've been fortunate enough to see you present on a similar sort of topic about how to enable communication with an architected approach and using Archimate. Would you agree that it's possible to use these models and diagrams as a communication vehicle for collaboration and strategic intent? Absolutely, absolutely. Archimate is basically just the bread and butter that I use to clarify what it is the business wants and where it's going and then we're collaboratively to show the systems that are necessary to support that business intent. In fact, that's just what I've been doing over the past week. My main assignment was to clarify an application of big data to a particular set of marketing processes and so first I modeled the processes and I got everyone to agreed on that. Then I modeled the exposed behaviors, the application services that those processes would have to, what would require. And then I modeled the applications and the technology using input from engineering teams, et cetera and just at the end of the week, in fact, Friday before I was gone for a few days so I was relieved there was actually really a consensus and that's what we're going to do. And part of that also, especially in the agile world is coming down to the minimal viable product. What's the essence? What's the least of this that can be important? And in my final set of Archimate diagrams it was very clear what was the minimal viable product and what were the key additions to really fulfill the vision. So yes, I'm using that every day, every week to clarify communication. Can I just add that I don't think that any architecture models communicate. They are tools to enable architects to communicate. Sending somebody architecture models as attachments to email is very dangerous because in general they don't understand them. If you take them through them, these are wonderful tools. Absolutely, I always take people through things but they also like something to hold on to that they can point to after the presentation saying that this is what we're going to do. I did several years ago a big multi-layer contact center CRM architecture for the financial services company I was working for. The VP of contact center took it and hung it outside of his office because it was something very tangible, something visible about what we were building. Yes, I like your remark very much because that was one of the problems we had to solve in the business architecture as well. The first thing we thought, well in fact we need a common language if we are people with diverse interests and goals or maybe with diverse languages, we need something in common. I discovered during all these work groups on the business architecture as well, well there's only a limited set of concepts to be used and then we can handle it. So why not formalizing these concepts? We want you to apply it in any industry and that's a real strength. So we started to develop those concepts and then building a common language. So no modeling, just a common language. One concepts relate to the other which improves the understanding. So we have a little bit more than 20 concepts to be used to guide people through from ID to vision to strategy and implementation plan and then it can be pulled through to the design and development phase. And it can be enriched between the argument and the standard, I believe. One is more focused on the real narratives and the languages. The other one is very strong in the modeling and the communication between designers and developers. So I think there's a good world open to combine those two in the common transformations. May I add to that? I think it's also important to realize that Archimate is not just a graphical notation. You have these concepts which have relationships which can be visualized in different ways. You can have an architecture diagram for the architects but you can have, say, a matrix or a list or any other visualization of the same model content for different stakeholders and that's very important to realize. Archimate is not just intended as something to produce pretty pictures. It's really also a way of making clear how things are related and how you can reason about that, how you can analyze that. So it's also a vocabulary, it's also a set of relationships that helps you to do that. So don't just see it as something to create pictures with. Right. Exactly. I think Archimate promotes better thinking. I train a lot of solution architects and things and then they start using Archimate and it's clearer what they want to do. And the other thing I'd like to say is that it seems that, you know, recently I looked at the U.S. NIST, National Institutes of Standards and Technology, Big Data Reference Architecture and I started mapping that to Archimate and I found that it was very easy. Much of it is written, of that standard, is written in terms of capabilities, resources and business roles which map directly to Archimate, so it was a matter of transcription. And I'm not aware of any explicit connection between the open group and the standards efforts by this U.S. government agency, but clearly there seems to be some convergence in how we talk about things. Yes, maybe I could make another remark on this, how I see this evolve. I've always been involved or mostly been involved in the idea to strategy planning and implementation phase and I sometimes tell people, one should be more like a magician, so all the techniques which are included in the standard, just keep them under the cover. They are for using them at the right time just in time, just enough. And it's like a magician, you just show them, wow, that works. So if you can achieve that type of, let's say, leveraging the process between the different views of the stakeholder, that's really terrific and that's all what the standard will provide you with. So the consulting skills, I fully agree this morning with Jeff Scott's consulting skills, very important techniques for the magician behind the cover and just act in the process. I think when Aaron was talking, he showed you towards the end of the diagram an illustration of the member companies and the individuals from those companies involved in delivering or developing the open VA standard. And I just want to illustrate with the folks on the stage here how this is representative. Iver at Cambia is what we would refer to as part of a member organization from the customer community. Mark and Harry are from suppliers, representative member community. And Mike is a little bit unusual. He's been in and out of industry but right now his role is as a fellow of the open group. The point that I'm trying to make here is that this is actually a diverse population contributing to the development of open standards. And so my question to you, and let's maybe go from Iver this direction, is why are you doing this? Why are you involved in the open standards community and particularly in the open group either from a company value perspective or personally and professionally if I might probe you on that a little bit? Iver? Well, two reasons. First of all, strategically, I think that what Cambia is trying to do to become sort of this integrated technology-enabled health delivery company from being a health insurer and is in that transition is very complex and benefits from the leading edge in various areas. So in working in the standards process I'm exposed to leading edge thinking in a lot of different areas and not just in the archimage and risk area white paper that we did several years ago where we foreshadowed a lot of the things that went into the current standards. I was really looking very holistically at risk and complexity and got a lot out of that that I put directly into the company. And as a result of being in the standards process I'm in touch with enterprise architects all around the world and I'm aware of different techniques and I'm able to deploy them immediately in my company whether they're standardized or not. And then, you know, and then the other thing is that personally I find it just tremendous development because my work, you know, I write a lot of things and it's roundly criticized by people and then the best of it is accepted. And so I learn a lot about how to express myself to people that on the surface I don't seem to have a lot in common with how could they possibly understand what I go through day to day. I'll never meet them. They're on the other side of the world. But and also just professionally learning how to express myself in this way and just learning about the other problems that people face. So it's just been a tremendous developmental thing that contributes to my performance day to day as an enterprise architect. Well, to start from a personal perspective since I've been involved with Archimedes from its very inception I was the project manager when in my previous job at the Dutch Applied R&D Institute. Of course it's very interesting and nice to see the development of your work over the years and now it's been 15 years now that I've been involved with Archimedes and it's of course very satisfying to see how it's picked up internationally and how it's become a really popular standard, etc. So being involved in that, that's certainly a very important personal motivation for me. From the perspective of business design I think I see two main reasons that we're involved in this. First of all it's because we can serve our own clients in a better way because they have certain needs and we can influence the standard to cater to these needs. So that's one important aspect. The other is that of course the open group gives us visibility as experts in this area. So there's also, well you could say a marketing aspect associated to that. We can show that we're good at this stuff. So I think those are the two main drivers for the company to be involved in this. So it's certainly to help our clients that's the most important driver I would say. But also visibility. Harry? Yes. Well a personal reason to be in this. I started my career as, well I'm an economist and I started my career as a marketer. So thinking of what's needed in the market and how can I provide good services to that need in the marketplace. And since I was born I think like a system thinker, I tried to get that communicated to people but that's not easy if you are a system thinker because there are too many aspects which relate to each other. And that kind of drove me all the way down to where we are now. Okay, how can we communicate this and how can I, could I convince these stakeholders that this is a sensible investment to do. And that's how I got to the language we needed and to the modeling aspects I took in the background and to the process we needed to get stakeholders involved and convinced. But that's a personal drive. Now when we relate this to HP Enterprise then I believe there's, we have many contracts with clients which are very big, 100 millions of dollars. And there are commercial processes to those clients as well. And in order to get all those different disciplines aligned to what the client really expects from us and what they really need it seemed to be very, very helpful. And that's how we started to leverage this and to develop that capability within our company. And the open group has been a tremendous vehicle because it brought together a few lines of thinking which were very, very close to each other. And that's how we recognized this and how we started to jump in and to give the leverage. Right. Quite an interesting question. I first got involved with this organization as the representative of a supplier company. The motivation of that supplier company was nothing less than survival in a competitive market. And the early days of this organization, when it gets open, I think put off the demise of the European computer industry by a decade by providing a platform that all of the European vendors could use to attract the software industry. I came into the open group. I became the chief technical officer. My current motivation is directly related to Togaf. I was at the first ever meeting with the architecture where we decided on bringing Tafim into the open group. I've been involved with Togaf throughout and as I reach the end of my full-time career, my motivation is to see the next version of Togaf successfully delivered to the market. Why? Because I've been engaged for the last 10 years working with many companies around the world. And I've seen the lights come on when they suddenly figure out what we're talking about. You're not talking about drawing boxes and lines, are you? You're talking about communication. You're talking about relationships. So my personal motivation now is to get the next version out to market. Do we have any questions from the floor? I asked you to queue up, nobody's queued up, but maybe it's because I've been talking too much. Okay, Mike. I'll ask a question, then I'll answer it. Why is it so important that we've got customers, vendors, et cetera, in the same room? And the answer is that if you get vendors in a room developing standards, their motivation is minimalistic, so it doesn't affect their products, their business. Having customers in the room provides that balance because the customers say no. You simply can't duck that issue because if you duck that issue, what you're doing is of absolutely no use to us at all. Having both sides of the industry in the room at the same time is the thing which ensures that what comes out is of value. I just want to reinforce that point because as I used ArchaMate 2, I worked a bit on ArchaMate 2 and as we used it over the years, there were things that really didn't work that really didn't work for me, that were shortcomings of the language and I was able to communicate them to Mark and my other colleague through the standards process and those things are fixed. There are just a large number of things that I can trace back to a complaint that I had about the standard that I was able to communicate constructively to the right people. So that's fulfilling and it does work. I think to underscore that from a perspective of somebody who's responsible for the architecture products is that I'm going to ask Mark to comment on the actual process of delivery for ArchaMate so you have an understanding of what goes on. But what I was just illustrated is because it's an open standard you only have to engage in order to influence and make the changes that are necessary in the standards for your business value, whether that's your value from our perspective as a customer organization or as a supplier. So the critical thing here is engagement. Mark, you just nurse-mated with either in the ArchaMate forum the delivery of the standard to market as a member organization. Can you talk a little bit about from ideation through to delivery what you guys went through and how you operated? Well, the first initiative coming to version 3 of the standard started about two years ago. I was personally involved in that because that was really the point that we saw that it was time for a new version. There was input from various angles. First of all, there was this sort of a bug tracking system that the open group has request for change or issues with the standard. So that was an important input. We had from various different sources we had ideas about how to improve the standard, how to extend it. So what I started doing that summer was draw up a basically a large spreadsheet of all the things we might want to have in version 3. That was then discussed within the ArchaMate forum and basically decided upon that this is the set of requirements for version 3, this is the stuff and then we started working on that. First, we developed with a fairly small core team a draft of the next version over about the period I would say fall 2013 until summer 2014. So in summer last year we had the first drafts available with everything covered that we had in this list of requirements. And then we went into the official standardization process where we have the two levels of review, first the ArchaMate forum review so everybody in the forum could comment on that. Lots of comments came back of course. We addressed those came up with a second version that went through the company review many comments again of course those were addressed and that was then the version that was eventually standardized. So the whole process until the standard was completely finalized took us about two years. So from first idea that it was time for a new version until the delivery of version 3 last month that was about two years in total. I think we've done a pretty good job in compressing that time and sometimes it was a bit stressful but we really wanted to deliver it on time and I think we are blessed by the fact that the ArchaMate community working on the standard is fairly small and fairly coherent. I think Togaf has a larger challenge because it's a much more diverse and much bigger community and Togaf itself as a standard is a lot larger so moving that into the future is of course a much bigger effort so I think we are pretty flexible and nimble as a fairly small team and that really helped us as well. Thank you. One more opportunity for a question from the floor if there is one. Okay I want to wrap up here thank our panelists for their candor and their expertise thank you very much gentlemen