 It is a pleasure again to have the opportunity to share our experience with the Enterprise Architects community, representing MEGA, Maya from our office in Sydney, and myself from our regional headquarters in Singapore. We both have been engaging with many organizations around the world on their initiatives for more than 10 years, and we are happy today to testify that this topic definitely covers a challenge that each one of them has been facing at some point. We can guess that this is still a very relevant topic for many organizations. Without further ado, let's start our presentation on how to demonstrate the value of Enterprise Architects to your executors. The EA journey of their organization is basically similar issues, similar challenges, based on the maturity levels they are reaching on this journey, which is made of three phases. And parking on the EA journey applies to organizations where the EA function is not yet in place, and where architects are solution architects with IT backgrounds, usually deployed into the various domains of the organization, and attached to project teams, and have strong silos, each having their own legacy systems, with redundant capabilities, that there is a lack of visibility and governance to implement changes in the context of digitization, for instance, but they usually don't know how or don't see the value of putting in place the cross-domain teams that are today breaking the silos and support the business better. So once again, this is the scope of this first phase and back. And once organizations have established an EA practice, with the team being able to interact with all the domains, they need to reach phase two, which is extension of the EA practice, as you can see here in the middle of the second phase. This is done by employing the enterprise architects with the capabilities that will allow them to build the continuum or enterprise repository for the organization. This phase tackles the issues on the data inconsistencies and standardization, and will facilitate integrating systems and stimulate the collaboration within the organization. Last but not least, it provides clear KPIs that the management can use for its decision-making. As some of you may have already experienced, successfully a practice regularly needs to adapt and renew itself as disruption comes with organizational changes, for instance. A typical example is a new CIO coming in the organization. And we have to say that we see this kind of challenges coming every day, which is taking us to the third phase, the sustainability of the EA practice. And I want to emphasize that, definitely, this is probably the most critical phase in the EA journey. So, of course, you need to go through the two first months. But reaching the third phase makes the role point about being able to show the value of the EA practice within your organization. So, the sustained phase where enterprise architects have to identify and leverage on new opportunities to make the practice durable and stronger with a clear value proposition. Going through this introduction, I'm pretty sure you could recognize yourself and your organization in at least one of these three situations. And I would bet that many of you know the challenges to convince their management on the opportunity to start the journey or to move from one phase to another. So, let's see how we plan to help you succeed through these phases. And let's go quickly through the agenda of our presentation today, which, as you can see, will follow the journey with these three phases, embark, expand, and sustain. So, in a nutshell, we will show you how to identify challenges and pain points supposed to be covered within each of these phases. Select the clear and useful use cases you shall tackle to bring value to your stakeholders and, of course, build your business case to internally sell your practice dedicated to the embark phase. And I will let Mayer give you the insights on how to build the foundations for the continuum of your company. Great. Thanks, Geron, for the introduction. I will reintroduce myself. My name is Meher and I'm in the enterprise architecture space for around 15 years now and 10 years with MEGA. I've been working with different infrastructure tools and also part of my experience is training Toga for many organizations. So, more than happy to share some of the experience and the insights that we had previously with lots of different organizations. And looking forward to getting some interesting questions to chat together and see how we can tackle those challenges. So, the first part we're going to start with the embark phase that we have seen many organizations facing it. In the embark phase, we're still at the beginning of having and establishing any 18. There's no a practice in place. And in that situation, normally, and based on the modern challenges we have seen organizations facing, there are various business challenges that the C levels and the executives face today. These challenges are for all organizations in all industries. Some of those are preventing organizations and executives in investing new projects. Many companies, they focus on only keeping the lights on. Their main objective is just to maintain what they have, prevent system breakdowns. Instead of putting the efforts on some new projects and innovation. Indeed, the organizations have become also more complex with the new systems and the different infrastructure. And these also have led organizations to start to migrate to cloud in order to decrease the complexity and increase the agility. So these different challenges that we've faced today, I'm sure that you can identify yourself with at least one of those. And when you talk to your executives, I'm sure that they have been talking and mentioning about these topics. How can we go digital? How we can cut some costs in maintaining our IT systems? How about the big data and analytics? With all the new regulations coming on the data privacy and the security of the data. How about the growing need for the agility? As mentioned, the departments are, especially IT departments, supporting the business. They are facing increased complexity and they have some lack of flexibility to support the new initiatives. Like, for example, moving to cloud. Another challenge also is on the risk and the data security part. And of course, you all know and aware of the topic of moving to cloud with the latest trend being for all organizations. So knowing all these challenges today. How does EA and how does architects like you and like myself, as an EA disciple will pitch this kind of value proposition to the executives? Today, enterprise architecture is not only addressing a simple impact analysis and giving us the visibility on the enterprise. It should do more than that. It should answer more questions and it should address more use cases. The various questions that you see here on the slide are different questions that have actually come from our customers. They have said these in their own words. When we have started the project with them, they have said that we want to know and our management want to know how we can rationalize our IT landscape. We want to identify which applications are providing duplicate capabilities so that we can eliminate and cut some costs on our total cost of ownership of our applications and IT systems. Some other questions have been on the technologies part. How we can standardize the technologies and control the impact of the obsolescence on our business? Some others have been focusing on the risk part, the security risk, the threats and the vulnerabilities on the IT systems. And we have enough control to prevent those risks. So these different questions that you can see here, they span across the business, data, application, technology, strategy, all over the EA layers and in various different domains. And of course, we as architects, we know that the right answer and the right function which connects the dots in all these questions is enterprise architecture. Today, with its scope in covering the business, in covering the IT, with the application, data, technology and its various domains. And enterprise architecture is in the heart of transformation of all these initiatives. In order to have a clear visibility of the organization, enterprise architecture assists the corporate and the strategy planning in the alignment of the business and the IT operations to the strategy. The operations and the process modeling and the improvements also benefits from enterprise architecture when it gives the dependency of the business from the IT. Some new functions and domains are also in the picture. Lately we have seen from lots of organization in banks and other financial institutions, for example, when they try to map their customer journey. And we have seen enterprise architecture playing a very important role in assisting the marketing functions and other business domains in understanding and improving the customer journey in using the various channels to interact with the services and the products offered by the organization. Enterprise architecture helps the information architecture and the data part in the data security, the GDPR or the PDPA, the various data privacy acts imposed by the governments on the organizations. Of course, we know a lot of the importance that enterprise architecture brings on the application and technological name in the obsolescence, the portfolio management, evaluation and transformation. And last but not least, in terms of compliance, how the EA can help and bridge the gap between understanding what kind of compliance and the policies there are applicable to the organization. And if we have enough controls to try to comply to those regulations. So because of the digital business transformation topic today and the challenge faced by the executives, the way we do enterprise architecture is quite different from the classical ways in only focusing on layer by layer. Today, enterprise architecture spans across various domains. So the questions that we need to ask ourselves and we need to pitch to the management as well to say that do we have the right visibility on the organization? Do we have the right tools to navigate the change and understand how the technology obsolescence impacts our business process? And this impacts the customer and hence our services and the profitability is impacted from this. So EA is not an option today. EA is a must in order for the organization to go digital. This is very clear message and it's very clear of course for us all being in the enterprise architecture space. So the way we actually do business process modeling today, the way we do information architecture today, the way we do application and technology architecture today is different. And it's all impacted by the digital business challenge. So in the first phase, when the enterprise architecture team is about to be launched and it's about to let's say start a new initiative in the organization. It's very important for the enterprise architecture team to focus on these type of challenges, to focus on these kind of use cases in understanding the impact and the interdependency between all the different domains. Not focusing on one particular area, but trying to get a big picture and present it to the executives. So now that we see what value EA brings, we see the scope that enterprise architecture covers and the use cases and the challenges it addresses. Jerome will present to us the toolkit on how we can present this value proposition to the executives. What you already know in terms of the conviction you have as an enterprise architect for the value your work is bringing to the organization. One of the main challenges you've been facing probably already, since you're attending this webinar, is that you know the complexity and the frustrating exercise that it is to explain and justify, motivate the need for enterprise architecture within the organization to your executive. So in this section, we're going to show you some very clear items to describe the preparation of your business case as tactical approach to motivate and convince your management that it is worth investing in such kind of practice. To identify opportunities, to keep in mind that from what we're doing now, we are not doing things as architects. We're putting ourselves in the shoes of executives trying to understand what their concerns are, what their pain points are, and trying to help them addressing those issues. Step one, definitely understand what are the priorities of your executives. So they're of course usually aligned with the priorities of the company. But it is important to make sure you have a clear perspective on what each of your executives are expecting and trying to achieve on their own responsibility. For example, of what objectives can be assigned to some of the executives. We can get from the one that I'm sure all of you are knowing and facing, which is to put costs under control on the IT spending, for instance. I could mention one of our customers being using enterprise architecture and a new repository to make sure it has a good visibility on its IT landscape, on its technology obsolescence, on the cost of its application. To be able to project itself and make assumptions to reduce its refresh budget. And the leading insurance company I have in mind basically has been able, within two years, to reduce its refresh budget by two. So you can see here that we have clear objectives assigned to the usage of a new repository through the apparatus. And we could show some achievements regarding those objectives. Another typical example is to get to market faster. This is also a very trendy topic today. It's been for a while, but it's getting stronger and stronger. And even within governmental agencies, for example, in Singapore, we're working with some of them. And we have customers in the governmental business that want to be more efficient and to be able to have the time to market more efficient, faster, and cheaper. In this context, putting in place the apparatus and showing how it can help leveraging on the existing situation, which we've seen step two. And building some clear road map has been very useful for them to reduce the time to market of some of their developments and some of their deployments of new services. So once again, step one is critical in order to ensure that you know what kind of objectives you have to align to and tackle within your practice and what your executives are expecting. Once you have identified and selected some use cases that have to be prioritized, you have to make sure that you're able to project yourself and help the company project itself based on what it is starting from. And this is the scope of step two, which is to define where you are. What are your current EAS sets? What is your IT landscape? What are your processes? How are the operations running? On what do they rely? What are the risks on those assets? And then once you have a clear visibility of this, as it states, which is typically called vocabulary for enterprise architects, you have to be able to project yourself and identify people that we have to be served by your practice. So we're moving to step three, making sure that we know who we're working for internally. And we have to consider them as customers. So we have to pick people that can get some value from our work as an enterprise architect. And that can get some value on what we can provide in terms of analysis, impact analysis through the EAS sets, projections through the KPIs. We can identify from step one and work with these people to impact them and involve them in using the EAS repository. So for people to identify the opportunities, you have to address first to prioritize within your EAS practice. And then be your value statements, articulating the coverage of the use cases with the stakeholders you're going to work with and work for. And basically, with step four, you're going to prepare yourself speech. So this is something a bit particular in terms of practice and use case building. You have to see yourself as safe people for step four. As we see on this slide, basically, we can consider several approaches. There is one we tend to recommend to our customers, which is the sub-approach, features, advantages, and benefits. This is very important as very often from what we've seen with many of our customers, enterprise architects are very feature-oriented. They try to justify the deployment of their practice, the usage of an EAS repository on features that are going to be useful for users. While the real point is first to address benefits, to make sure that what you're going to do and the way you're going to deliver it will provide benefits to the stakeholders you have identified. So once again, before considering features and advantages, focus on benefits from your user's customer's perspective is dedicated to add some cherry on the cake for your executives to convince them based on some other company's experience or colleagues or people you know within the enterprise accession committee that can give you some feedback of the proven benefits that EA brought to the organization. We ourselves have quite many examples as we are showing one on the screen with a very large insurance company getting a very strong, very solid ROI on the investment that's made on the EA practice. Once again, we have many examples such as this one, but within your community, within the open group community typically, it is possible for you to gather some such kind of example that would be meaningful in your own organization and that would be convincing to your management. So keep in mind, you're part of a community, you can work and collaborate with people, colleagues that have some useful feedback for you, sending the value and the way to measure it. We've said it before, we've seen it with some examples from the use cases. We have to make sure we deliver some value and that it can be measured. So KPIs are very, very important to be considered. Anything that can be measured is always more convincing than just quality assessment on the progress, on the improvement or the way the company operates. So I think all of those steps in mind, you have a good guideline to build your business case and to convince your management of the value your practice can bring to them. Once again, focusing on their priorities, on their expectations, on what is useful to them. We won't spend too much time on this as we have a limited time for this webinar. But if you want to have more details, know that we have a white paper available that describes each of these steps much further, with much more examples, with even questionnaire templates to collect and convince the stakeholders. So feel free to contact us if you want to have a look at this white paper. And conclude the first part on the end-back phase of the EA journey by pointing out some very critical aspects that we have to consider to build your business case on this stage. Once again, when you launch the EA practice and you want to establish it within the organization. So the first and most important point is, as we said, to identify priorities of your management and the way you can address them. So the use case is you're going to cover with your EA practice. Knowing where you're starting from within the company, within the organization, with your EA asset, is, of course, very important to map them to the use cases and see through your assets how you can help analyzing, assessing the value and the transformation of those use cases. A very important point is the third one in terms of success and the capability to convince once you launch the practice is to select quick wins on how you're going to deliver the value of EA. We've seen, unfortunately, quite many organizations trying to launch EA as a big bang to cover all the layers of EA, involving all as many stakeholders as possible and to show that it was moving big and having a big impact on the company. And to be honest, it most often fails because it's very difficult to gather everything at the same time, to embark everybody at the same time, and to fight against all the resistance you may face for various reasons. So once again, selecting quick wins is very important to show value as soon as possible and to prove that your practice is useful to the organization. And the way to do that is to share and communicate. One of the drawbacks or risks we've seen in many projects is for enterprise architects to be somehow afraid to share the knowledge, the information they're building and they're collecting because sometimes it's not fully up to date, because sometimes it's not very complete. But in the meantime, it seems nothing is happening. So stakeholders who have been contributing to the practice are getting frustrated. So it's better to decently start sharing, showing the progress, even though it's not perfect from the beginning. But having this visibility on your work is very important to make it accepted and appreciated by the stakeholders within the organization. Phase one of the journey with the embark phase, we're going to move now to the second phase, which is the extension of the practice by running the continuum. And Maya will take over on this part. Thanks, Jerome, for clearly explaining how we can start launching a new team and how we can pitch the value to the executives. Now for the second stage, we have seen many organizations once the enterprise architecture practice is launched. Then there is a need to try to standardize that practice, try to consolidate, and make sure the value is complicated throughout. So there are new challenges and there are new obstacles that this newly formed EA team faces in trying to make this practice a standard in the organization. Challenges like lack of transparency. We've seen different organizations and newly formed the teams using various tools, using different methods and frameworks and trying to build and create their artifacts by contribution from sometimes other teams or sometimes them themselves building the whole artifacts. So there's an issue of lack of transparency in sharing the information clearly with others. The data is inconsistent. There are different tools used. There are different, there's no single source of truth for all the information where we will have some inconsistent data in place which can lead to an improper impact analysis. Since the team is new and there's no clear govern, there might be no clear governance in place, there's a lack of standardization as well. The information and the artifacts are created in a non-standard way and each member of the team will try to do things their own way, the way they have been used to doing it and that will create some lack of a standardization as well. Since there are no workflows that tries to link the contributors and the EA team together, there's a lack of collaboration as well. A very important point that Jerome mentioned in his last slide is to say that the EA teams have been sometimes shy in sharing the information. They try to keep things for themselves and just give bits and pieces to the other stakeholders. This is sometimes the result of lack of collaboration. We try to get information from other contributors but we try to build our own repository in our own way and keep it as our own cotton-coat baby innocence. So it's very important to also see the collaboration part of it. And of course, the standardization also needs some integration with some existing systems, some existing tools in place where we can benefit from those information and try to present to the executives the real value of the EA once we have tackled those challenges. So then, we will give you some best practices based on all the challenges in how you can tackle those. And really, there are two main pillars we have seen and we have seen successful EA teams use in order to move from this particular stage in the standardization and the expand which is the second kind of the phase in the lifecycle of an EA team to the last part. The two pillars are first, using and adopting a proven best practice framework and second one, using a continuum and the repository for all the enterprise architecture assets. So for the framework and the methodology part, it's very important to adopt a framework which is the best practice available like Toga. Toga gives you the best practice. It gives you a very good integrated approach for all the domains. It covers various phases of the architecture development starting from the vision on how what kind of challenges we want to address and then how we want to do our business architecture, the application architecture, what are the different viewpoints that we can generate from these phases and how we can move all the way to find the right solutions to the challenges that we are facing. It's very important to use this kind of framework and of course the recommended one is to use Toga for that as it has been proven over the years and years that it's a very successful framework in trying to make this practice a standard practice in the organization. Of course, you can take also advantage of some ready to use methodologies that you have in enterprise architecture tools that are also important and gives you some sort of the structuring and governance in place in order to tackle the collaboration issues, the standardization issues or the integration issues that we saw in the challenges for this phase. And of course, the main approach and the main advice from this part is to make it tailored to the needs of your organization. So tailor it to best suit the organization, the challenges you're facing and the use cases and the questions you are trying to answer. So this is the first pillar in the framework part. The second part, it goes to the repository. It's also extremely important to have this single source of truth that will contain all your enterprise architecture assets. Your business process catalog, your application catalog, the matrices, the different viewpoints that you generate and the different analysis and the dashboards that the executives will need. The single source of truth needs some ownership. We have seen lots of enterprise architecture teams fail in this part. They succeed in the first part in craving the single source of truth but the ownership and the responsibility in maintaining those artifacts are not clearly defined. So the ownership is another key point there. The collaboration, the communication and sharing of information with all the organization comes also in this part. Since we have one single source of truth and all the organization can benefit from it to see all the enterprise architecture artifacts that the team is producing. And the last point, it's always the most important point that we as architects always say and always face is to focus on the outcomes. We are not doing modeling just for the sake of modeling, of course. The important thing is what is there for the management? Why am I drawing this particular diagram? It's something that many organizations try to focus when they build their as is architecture space and they try to forget the big picture. What kind of challenges am I addressing? So it's very important to go back to the phase A in photography and architecture vision to say that why we are doing this architecture piece. So in summary, to standardize the practice, the enterprise architecture practice, it's two main pillars, have the right approach, the right methods with the right tools. Now, what are the benefits that this will bring? Having the right tools with the right approach, the automation and the standardization that it brings, it can actually put it in four different domains. First, in the governance and control, this will give you having the right methods and having the tool in place will give you the full visibility of the enterprise landscape. You will be able to get a holistic picture of the enterprise and communicate that to different stakeholders. You will get some accurate data because the owners are there for each list of applications, for example, to maintain. It's not one application team trying to maintain hundreds of applications, but the applications have their owners who are contributors and they maintain their own list of systems, for example. So the data will be more accurate. You will get the transparency because the right information are available to the stakeholders that require those information and also will break the silos between different units who try to collaborate using the collaboration capabilities. Another point, there's also the analytics or the intelligence and the expertise that this approach brings. You will have the right tools to use it for the transformation of the information that you have in your source of truth into some useful analysis that is used through various tools, it's used through various techniques and these analysis are extremely important for the executives. They might not look at the diagram remodel, but they might look at the analysis and the information that is generated based on those models. Some of the capabilities will be there also that will try to, let's say, alert the executives to highlight the obsolescence risk or these kind of analysis that is needed for the organization. And to give an example here also, it's very common we see in almost every project nowadays the risk of technology obsolescence impact on the business. It's becoming more and more important to the executives since we have lots of IT systems using different technologies, different vendors. So it's extremely important for the management to stay on top of it and get immediate alerts whenever there is a risk of using an end of life technologies. Another domain that it will help, it's in the productivity and the simplification. We will have all these artifacts created with minimum efforts since there are some automation involved in trying to, let's say, build this single source of truth. Then we don't need to create diagrams all the time. There are some tools that that particular continuum repository can do it for us. So some low value added activities in trying to create diagrams, maintain the diagrams all the time. These approach can help us in simplifying that process and be more productive in focusing on how we can actually address the challenge that my management and the executives are facing. Last but not least, it's the standardization. And based on that, it's the improvement. In the best practices, you are reusing some frameworks that are there. You are reusing full gas or reusing other frameworks which are important, which are reused and proven worldwide that it's a best practice. And based on that, now we have a common understanding, the enhancement that this will bring as the organization tried to speak one language across the whole enterprise. And here, there are some three or four extracts or deliverables that you can present to the management. These are some examples in various domains that will bring lots of value to the management. One example is the roadmap impact of the IT systems direct on the business capabilities. Another one is the impact of the technology obsolescence on the applications and the business. Another example is on the costing, try to understand the total cost of ownership of the systems. And the fourth part is addressing more from the risk domain and understanding how the risks on our IT systems can are impacting the IT and also the business boom. So to summarize this particular phase in how to make the EA program and the initiative in the organization a standard one, we always recommend to start small, make a small use case, have a small pilot program to test to showcase the benefits of the repository and the approach that you have adopted to the organization. Don't boil the ocean from the first part in trying to standardize the practice. Understand clearly what the concerns are, what the executives are most concerned with. And this of course requires an architect to be aware of all the new challenges that the organization is facing. Sharing the information through a portal that's important also to try to get as much contributors to your own repository as much as possible. The ownership and the responsibilities are critical so that the creative artifacts can be maintained and up to date. And of course, the end part here is think, win, win. Assess how the customers, as in the other people in the organization can contribute to your practice and the value that you will get out of it of course is that your own repository and your own practice will be populated with up to date information. And on top of that thing, what kind of value they can get out of it. What kind of analysis and reports is important for these stakeholders so that they can also address their own challenges in their own roles. So the last part will be on how to keep the EA program sustainable and successful in the organization. And Jerome will give you some information on that last stage. Last phase on our journey for the sustainability of the practice. In the previous sections, how to establish the practice, how to extend it to make it run and to start delivering some value to the executives, the values they've been expecting from what has been defined with them. And now we address what is probably the most challenging part of the journey. As you mentioned in the introduction, this phase is often missed by enterprise architects in a sense that some of the considered the job is done as they have a new practice running, being delivering some value and being seen as useful within the organization. Unfortunately, it is not that simple. And as some of you may know, as time is passing by, after some months, some years, some new challenges, some issues that are appearing that are entering EA practice. I'm going to show you some types of risks that are typical in this kind of environment and that definitely put at risk the EA practice and can jeopardize the initiatives and the existence of the area. A typical one, which is very common, is an organizational change, which can be due to people. If you have a new CIO coming, joining the company, for instance, you may have a very different perspective on what are the priorities for its teams and for what they have to deliver and how to deliver it. But it can also be because of a merger and acquisition of your company with others. So you can have different triggers that can change the perspective on the value that is expected or that should be delivered by the EA practice. We mentioned it several times, but this is a key point, the sharing of information. If you don't spend time and you reassess regularly the way you share the information you have on your EA inventories, your EA assessments, and the dashboard that are available to the executives, if you don't pay attention to those items in a continuous space, you may miss the point of new opportunities coming into the organization to show the values that is expected by new people, by new projects, by new business lines, et cetera. The data of solicitants is always a risk, that's for sure. And from what we've seen in the previous talks, you have some insight on how to make sure that the data is up to date, that people who are in charge of it and accountable for it are collaborating and contributing to maintain it. However, once again, it is a point to pay attention to all time long to make sure that you can trigger alerts to your management, to the executives to say, okay, we have some issues on the refreshment of data on some layers and we need to put some more effort on different things. As long as you show how this data is valuable and used for some analytics, you will get the support of your executives. Budget restrictions are the daily life of any organization and making sure that you show that you bring some ROI in some way is important. If you remember on some slides before on the business case building, for some steps we are showing you some concrete examples of what kind of ROI could be evaluated and assessed by some companies. This is a very important input to provide to your management on what kind of benefits they can get from the budget perspective based on the investments they're making on the equity. The new business priorities are usually very disruptive and there are more and more actually. So this disruption has to be taken into account, of course, as a risk for your practice, but in the end as an opportunity. You will see that most of the time what you see as something challenging and being a problem is basically in what EA can help. If you consider the pressure from regulations, for instance, one of the very trendy topics we have this day as this year is the preparation of the GDPR law in Europe and regulations for data privacy to which any company doing business in Europe has to comply. So this kind of new pressure, new constraints that is in the end coming from the business because they have to comply to it is an opportunity for EA. And it is something you can support your executives making sure they can provide the expected proof to the regulators that they comply to the new constraints. I will say on this slide, so it's not to say it's not useful just to reassess and re-point out what you have to run, what you have to do and what you have to make sure you pay attention to in order to continuously reassess and show the value of your practice to your management. So the assignment of responsibility and the accountability on new information on the asset is basically a daily job because as soon as you have a change from the organization, from the business, the use cases you're covering, you have to make sure that the accountability on your asset is maintained. So that's once again something you have to pay attention or done. Try to be as less dependent as possible on those changes. Putting in place clear processes to run your practice and to make sure that it's stable and can be reliable even though people are leaving the company or moving towards a position. You can ensure that the practice can be operational and go on delivering the value it is providing to the stakeholders within the organization. The point is definitely to continuously pay attention to what value the practice can bring to other stakeholders. Extending the use cases, finding new opportunities to deliver this value is something you also have to pay attention to all the time long. So finding new stakeholders in one of the typical examples we are covering ourselves is to work with risk managers, with audit teams who are very found in taking advantage of the assets for their own operations, for the daily job, the risk managers are very, very keen seeing the business processes to do their assessment on risk. Auditors are very happy to see the description of your IT landscape to see where the data is going within your organization and outside of your organization. So those assets are once again very, very good for these kind of stakeholders and you should not miss the opportunity to work with them, to collaborate with them and make them contributors of your practice. One of the more recent use cases we've seen emerge in the past years and which is very, very interesting to show the value of your business architecture is the customer journey. Basically, marketing teams within our customers are very interested in mapping the customer journey to the description of the asset to be able to do a thorough analysis and impact analysis on where the pain points are from the customer perspective. And the integration is also something you shall pay attention to all time long to see based on what new repositories are coming into your organization, how you can take advantage of them, collecting some information and linking it to your assets and providing to those new repositories the information that will be valuable from your perspective as you're managing the assets and being the source of truth for the inventories of applications, for the inventories of technologies, for the inventories of processes, etc. After several times and I will state again, sharing is critical and sharing in a sense also that it can involve people in some other processes for the review, the validation of the assets. One of the very major use cases we have on this is involving business owners validating the description, the analysis on their business processes. So we don't say that business stakeholders are working directly to provide the assets to describe their processes, sometimes done by architects, but those people, those stakeholders are getting involved to do some review, to do some validation on those assets to make sure once again we have a clear accountability on what is described and what is known on how the organization is operating. The customer-oriented approach is vital and it is more and more, I'm sure all of you understand that, but keep in mind we are talking here about internal customers. So you have to see all your stakeholders as customers to be able to serve them better and make sure their experience as a customer is good. Last and important item is for your own team for the apparatus to be efficient and to be sustainable and to make sure that the skills that are required within the A18 and that the capabilities in terms of workload and in terms of the ability to produce, to interact with other stakeholders is sufficient to deliver what you've been engaging for and on with your use cases, with your business case that you sold to your management. This is the conclusion of our presentation and we'll give you very few takeaways on the three phases we covered and on the critical items you have to consider to build your business case and convince your management that the A18 brings some value to the organization, to themselves, because of course as we said several times, to convince your executives you have to provide them a clear vision and a clear idea on what benefits they will get for themselves. So through the embark, extend and sustain phase, we basically saw that we need to build business cases that are dedicated to those stakeholders' expectations. So understanding their needs, understanding their pain points and being able to tackle those use cases through the ELAs and the assets you're managing within the A18 is of course important and critical. So the identification of those stakeholders is something you have to review regularly to make sure you don't miss opportunities to take advantage of your A18 and adding some value on them. You have to focus on the management priorities and you have to build a robust practice. That means it has to be visible from outside of your team, once again sharing, sharing information, making it available to the whole organization is a key point. Then you have to make your ear repository a source of trust for the items you are comfortable on. So we mentioned the intentaries on applications and technologies and processes. It varies depending on the organization, how far the ear repository goes in terms of source of trust. But what matters in the end is to be reliable so for other repositories to be able to take advantage of it for the stakeholders to take advantage of it and in the end the motivation is to become a source of trust. You have to be an advocate of enterprise architecture and bring some value, some confidence within the organization on the fact that we know how it operates, we know what to realize on and we know that we can use those assets to transform it. The conclusion for our presentation, we hope it was clear and interesting to you. We can now open the floor to some questions. That's great. Thank you Sherom. Thank you, Maya. I think you've covered a very important subject that as you've identified that many enterprise architects come across on a very regular basis. We do have some questions in the QA facility and please, if you do have any questions for today's speakers, please do write them into the QA text facility. Before I go through those questions, guys, have you had any thoughts about if you'd like to make your slides available to the attendees today? If so, how would you go about doing that? We'll make the presentation in slides over. Okay. Thank you. Let's just work through some of the questions we have here. The first question is from Mary. Mary asked, what are some examples of measures that are realistic to prove the benefits you mentioned? Examples of the measurements of the value and now, once again, to convince your stakeholders, you have to correlate them to the KPIs they're expecting. So I took an example on the costs. Once you know your management as a target on cost reduction, for instance, you can make sure that the contribution of your activities can be assessed towards those KPIs. And it's quite simple, actually, because if you consider the technology of solicitance and cost TCO on applications that we're able to provide, for instance, without tools, the impact is very obvious and direct on the reduction of those costs in the form the KPIs expected by the management. That's right. I'll give some other... Go ahead, Mary. Go ahead. Just wanted also to say that there are also other examples I have seen, I can give one or two examples from some projects I have done. There are teams that measure the success of the EA by the number of projects, for example, that are using the AIR defects or the number of projects that are actually relying on the enterprise architecture governance process in place in order to get approval on their projects or the system designs. This has been becoming one of the key topics as well when you try to integrate the EA in the overall practice of the organization and their lifecycle and see how the project teams are actually... How the EA basically is serving the different project teams in their day-to-day activities. So one example I have in mind is of the projects part. And other examples also will be... I have seen on how far the documentation of the different layers has been done in the old layers. So how far we have documented, let's say, four, three or four levels of the business processes if that is part of the framework, it's on the process. If you go on the application layer and part of it is to document the capabilities, the applications, underlying technologies, then how far we have documented all those information in our single repository. So these are two different examples that I have seen from enterprise architecture teams using in various countries. And I will add one more very shortly. I'm sorry, but as you understood, sharing is something that is very important to me and to us. When you have, for example, an EA portal that is available within the organization to share the information on your EA inventories, EA assets, the number of people going through to this EA portal daily, weekly is a very interesting indicator. And we have customers leading financial organizations in the region such as DBS who use this as a KPI to assess its interest and the value of the EA repository within the organization. That's great. Thank you. A question for Aria, asking, what's the best way to integrate EA with business process management? Question two, and we have several levels of answer. The thing is, what we do in our EA repository regarding the business processes is usually a business view of how the operations are running. So it's including some manual activities, some automated activities, but it's the business perspective. What automation and execution of processes implies is basically to have only the automated part being described and being able to be updated to be aligned with the business view. So once you're considering new projects or the goal of deploying a new ERP or deploying some very specific business applications, that can be very automated, and we are doing this, for instance, with a customer in Singapore, a large governmental agency. They can close their business processes in the EA repository, separating clearly what is done on a manual basis and what can be automated, and they're able to export the automated part to a BPM engine, and the results are pretty good. The level of reworking within the BPM engine is pretty low, so they're saving much time. In order to take business view as a specification, basically, for the processes to be automated in the BPM engine. Okay, thank you. A question from Angelo, and I'm just keeping an eye on the time because we have come to our end of the hour, but we can do this question, I think. Angelo asks, do you have any tips or ideas on ensuring that EA products are business aligned and usable and explained by the word products? He means artifacts such as reference architectures. I would probably answer that in saying that in terms of the reference architecture, you need to refer to the industry and what kind of reference architectures are available that can clearly communicate the architecture and the different artifacts in different layers on the reference models. There are different capability maps, for example, available for different industries in financial, in oil and gas, in insurance, product services, different industries. But the business capability map is becoming more and more an important tool to communicate the value and the alignment of all the IT and business operations to the capabilities that the organization has to offer. Okay, thank you. I just want to cover off these last two questions before we end, if that's okay. A question from Rohan. How do you deal with outdated information and the impact on buy-in because of it? I guess we can, for this question, we can go back to the topic of two points basically, sharing the information and then the second part is the ownership of the information. We have seen lots of organizations failing in this particular point where the information is not melting. So in the beginning, when we have clear ownership and the ownership, if the ownership of the artifact is not constrained only within the E18 and it's a decentralized way of working where we've seen different contributors from different functions trying to contribute and get the ownership of their own artifacts, that would help a lot in keeping the information up to date because at the end of the day, the information that they contribute to your repository is basically their own value and their own information as well. So as much as the E18 is interested, they will also be interested in keeping those information up to date because they are using it. And the second point I was mentioning about the sharing information, if the information is shared clearly with all the organization, then I'm sure the E18 will get lots of feedback about some information that are not correct, that are up to date, and then there will be the urge that it's available to everyone. Everyone can see it. So once everyone or the owners can spot the mistake, they can clearly identify and pass correct and make sure that the information is always kept up to date. And I will add one more point going back to the accountability. On the example I gave previously on the large insurance company where a big benefit could be reached on the refresh project, application owners who are accountable for the application information for the refresh of this information and to keep it up to date are subjected to an assessment on how up to date the information is and this is part of their incentive plan within the company to be assessed at the end of the year and based on the performance on the update of those information, the incentive is higher, of course. So it's a way also to stimulate the accountability, the update of the information. There are different ways, it's one of them and we see it as a success for one in this case. Okay, thank you very much. I'd just like to end with this final question from Papendra asking about the embark phase and specifically how can EA provide leadership in the setup or establishment of good governance in an organization? As I mentioned in the last part as an enterprise architect you have to be an advocate for the practice so you have to be very convinced yourself of course to convince other people and you have to be able to talk to various types of stakeholders to meet them regularly and bring the argument to them understand the pain points and map to the pain points the items, the use cases that you can cover with information you have within your repository if you have one or the information you're able to address through the activities of the EA team. So in terms of leadership these enterprise architects definitely have to drive this activity to be visible from the other stakeholders to stimulate and challenge the other stakeholders to collect information from them so this is a day-to-day job to interact with those people to get their confidence and to show the value that you can bring to them. Okay, that's fantastic. We have reached the end of our allotted hour and we've covered a few questions there which is great. Thank you for today's presentation as I said I think you have covered off a very valuable subject. Just before I close today we've got a number of requests for copies of the slides. Jerome, if it's okay with you I will liaise with you and make sure everyone gets what they need. Everyone will get an email from me as host so if you would like a copy of the slides used today please reply to that email and I'll liaise with Jerome and Maya and make sure we've got those distributed if that's okay. That's great stuff. Okay then we'll thank you both for your time thank you everyone for joining us today please do keep an eye on our website for future events and I look forward to seeing you all again soon. Thank you very much.