 Legacy systems, as we know, comes in all varieties, coded in different languages, technologies, and utilize card solutions from different vendors. Therefore, not all transformations or enablement of projects are the same, but the TOEGAF or ADM process provide a mechanism to do this architecture development and transformation project in a seamless manner. When combined with TOEGAF SOA guide, this approach provides the foundational process for this transformation engagement. So what are the key principles and aspects regarding legacy systems which needs to be taken into account for this evolution generally? And like any transformation engagement, legacy TOEGAF SOA also requires key operational performance indicators or metrics to ensure continuous communication and justification about this journey to ensure visibility to any stakeholders. It starts with the baseline KPI key performance indicators and measures them at appropriate intervals to effectively communicate the progress made in the transformation. The guide defines some of the key transformation strategies to enable the process of modernizing the applications using SOA, enterprises need to select one of these strategies and evaluate against their strategies. It recommends to leverage the enterprise integration patterns in a graceful transition from legacy systems to a more organized and integrated set of coexisting systems. Also, what impact of legacy system evolution has on the current organization structures and processes? The guide also highlights an approach to developing new skill sets to require to evolve the systems and plan for those evolution and transformations to SOA. Lastly, the guide provides guidance to assessing the security aspect of legacy systems and the way to secure the information in the transformation systems. The document ends with some of those detailed discussions of two legacy TOEGAF SOA case studies, including recommendations of how to improve those specific journey based upon this guide. Thanks TJ, and what's important is that in the remainder of the slides we will focus on a few of the topics that the TJ has showed in the table of contents to provide you an overview of what's inside the guide. And it's no surprise that actually the guide starts with the drivers for legacy modernization, the drivers and concerns for legacy modernization, as that is mostly the starting point for these types of engagement. There is a concern that can be a driver and we need to do something. We actually, with the members in the project, we inventorized the kind of drivers in these types of engagements and we actually grouped them into business, functional, usability and technical drivers. And that will also later on relate to phases in an architecture engagement. For example, some of these drivers, if you look at the business, and I will just mention a few of those drivers, is that you see that some changes in applications can take quite a long time, influencing the time to market, slow time to market as a result. Another type of concern that we see in business is that the legacy systems, it's quite difficult to get metrics how they actually perform in business processes, how to get those metrics and analytics from legacy systems. And actually cost is increasing as a result of that. If you look at functional, we are looking more at how these applications and how the data is actually being used. There's a lot of replication in legacy systems. As a result, data is redundantly stored, but it's also difficult to get real-time information. So we need to go, in various cases, towards near real-time or real-time and accurate information. Of course, also on functional level, it's about difficulties to reuse. Reusability is difficult as part of a functional driver. It's not only about how these applications can be reused or integrated, it's also about usability for an end user. Integrating legacy systems in Web 2.0 technologies like portlets, portals, but also integrate with social media, social technology is difficult. And that's where a lot of integrations or contact to the customer is needed for now. On a much more technical level, we also have to look at that level. For example, the fact that data might be stored in files and not in actual databases and storing the data in files might be hard to access by other functionalities, but those are hard to scale, and especially if we need to scale to much more users or much more external parties. Also on a technical level, we see drivers like embedded logic. Embedded logic in the application, like business rules, like security, authorization rules as part of the application business logic, which was quite normal some time ago, but also integration logic like point-to-point connections deeply inside these applications. And we've summed up a set of those drivers, and in summary, if you look at them, even if you look at different types of legacy modernization projects, you see that maintenance costs are getting higher and higher, there's no surprise, but if you want to reuse functionality and you do it in the same type of systems now, it will even be higher. It's difficult to get control over the application landscape, and especially its dependencies, how these applications relate, but also how these applications relate to business processes. So the business wants to change faster than IT can support. And this is actually where SOA is coming into the picture as a possible answer on some of these drivers and concerns that we have identified. But these concerns are not meant to diminish the value of these systems they represent. As TJ already introduced, a lot of business and mission-critical systems are running on legacy systems, but we overall see these trends in summary, and we believe that we can do something about them. Later on in the presentation, TJ will provide an overview of how to use this guide, and you can actually use these drivers as a reference and see how that matches in your engagement. Okay. As TJ already introduced, if you look at the TOGAF ADM, the Architecture Development Method, it provides a process to facilitate and manage architectural development and transformation, and legacy modernization is all about transformation. If we combine that with the TOGAF SOA guide, the SOA Practical Guide, that really provides the foundational process for elder SOA transformation engagements. And what we actually did is we looked at these various phases and focused on specific legacy aspects that are important in the SOA context within the TOGAF ADM. And that means that you will see in the guide, per phase, a specific legacy to SOA attention points. So actually it extends the guidance in the TOGAF SOA guide and the ADM. I want to provide a couple of examples of that, not the whole list, but you'll see some of those aspects in the blue boxes. One of the things is, for example, in the preliminary phase, it's important to have a SOA assessment of the SOA readiness of the organization, but also about the current legacy landscape. So one of these results will be an assessment of the so-called fit for SOA state of the current legacy architecture as a baseline to be used in the different cycles in the architecture. And if we look at the architecture vision, one thing was immediately clear within our project group. It's all about business case. It's all about cross-reduction and make sure that we have return on investment. And that's not always easy, but a business case is really a mechanism to support more originalization of this process, of the investments being made and a stakeholder buy-in. That also means that we have to work with metrics. And we have a set of metrics defined in the guide, which might be useful. Then if you look at the architecture definition phases, let's look at phase business architecture, information systems architecture, technology architecture, which is all about defining current state and defining target state. In the current state, it's a matter of still a certain detail, knowing what the state and where the legacy systems are, and especially how they relate to the business process. Because what we will see later is that we cannot only focus on technology because the legacy transformation is a transformational program. We need to know how it relates to the business. If you look at later on, and if you look at, for example, the planning on how to plan this transformation, the legacy to SOA transformation, also within a larger architecture engagement, there are a couple of things that are important. One of them is that we need to distinguish between actually the SOA infrastructure, like the enterprise service bus or specific adapters, messaging, et cetera, versus the applications itself. We need to put those in the right sequence in a planning to make sure we can actually SOA enable those applications. What's also important is that the SOA maturity level of an organization, we can actually plan legacy modernization, legacy to SOA evolution according to the SOA maturity level. So maturity level is already high. We can, much earlier, are able to open up legacy systems than when it's not there. So then we might have to start first with the SOA infrastructure. And above all, and we will see that later on, it's all about governance. It's a transformational program, so we need to have management of change, not only of technology, but also of people and process. This is a quick overview of some of these aspects that are important in these phases. So refer to the guide to learn more about that. Thank you, Juist. So when we were talking, or when Juist was talking about the ADM process in the architecture vision phase, we have to define some of the key architecture principles, and we leveraged the SOA principles for the transformation since we are transforming the legacy systems into SOA. And some of those principles, which we believe, or actually the guide has highlighted, is our principle that needs to be accounted for during the transformations. It needs to be well-defined service contracts. Service interactions must be well-defined and possibly with the widely supported industry standards. It has to be loosely coupled services. Service requester and consumer shouldn't have any knowledge about any service implementation details and how to interact. And they should only interact by the service contracts. Legacy systems can be migrated or replaced by other technologies without affecting the service. Therefore, service requester is totally decoupled or loosely coupled with the service providers. Define services with appropriate granularity. Services granularity should be easier for service requester to assemble different types of services to execute their business scenarios. It is generally targeted to achieve the business agility. So to really having some new requirements or new business needs, you can totally assemble some existing services and possibly create new services and create new business needs or address new business needs. Designed for statelessness, services invocations must be independent of the state of other services with minimum functional interwining. Or it has to be managed in such a way that you are really requiring for internet connectivity in a stateless manner. Ensure services has appropriate security enforcement and also adopts a anthology of vocabulary standards. Those standards really ensures that the enterprise has a common understanding between the business and IT community to effectively manage the civil life cycle of the services. So here are some of the metrics which might be considered for the legacy to civil journey. Metrics are essential for the continuous communications and the justification of legacy to civil engagement. Service enablement describes how we could expose the underlying data or information to the service consumers. The metrics also help in terms of application usage. If you baseline those before the transformation and compare it with after the transformation is really a way to really provide the justification of legacy to civil engagement. Cost reduction maintenance would be what is the impact of transformation on maintenance and licensing and energy consumptions. This could also include some kind of intangibles. Cost example, for example, business readiness to launch new solutions or systems, functional reuse, reusability aspects of transformations compared with the baseline functional reuse before the transformations. Revenue generated metrics would allow you to provide additional revenue, some metrics that would be providing information about additional revenue generated with the transformed services. Time to mark it as I discussed earlier with intangibles, that you can create new solutions by promoting core and extended functional solutions or services. Security and data protection enhancement are also important metrics because those really, if you compare with the baseline and making sure there is no new incidents or any reported other impact to the existing business needs or existing business usage are being impacted with the transformation. So all these metrics are really providing a way to justify the continuous journey as well as to ensure that the business is running as smoothly as possible during the transformation. So here is what, you know, there are a few modernization strategies we have documented in the guide. The format of this is each of these strategies would have a what approach you could take, what kind of problems or solutions or value added this strategy would be providing and what could be a risk and how do you mitigate those risks and what are the architecture building blocks involved in that strategy. So in terms of modernization strategies, you know, you are enabling the process of modernization of legacy solutions applications using SOA. Enterprise needs to select some of these or maybe combination of these, you know, to in their transformation journey. These are like a service enablement, a language transformation, which converting or migrating the programming language such as COBOL to Java. Re-architect strategy is to enable services based on service based solutions by re-architecting and applying the SOA architecture style. Are you hosting of legacy applications? Is to the, you know, what applications are dispersed in a multiple locations and you have to consolidate into an environment and possibly deploy in a call computing environment. So these are the strategies we actually highlighted in the guide. So here's a little bit of brief synopsis of one of those strategies, how those are being laid out in the guide. Service enablement is an approach, approaches to access the legacy applications through service hosted by integration platforms and or service containers. What problems could be faced during the transformations are documented, for example, reuse and leverage existing assets while protecting huge investment made in legacy applications. Improve value of core applications by using SOA. Leverage legacy functionality in an automated business processes spanning across multiple systems and departments. What could be the risk and how do you mitigate them? It would be difficult to identify useful legacy functionality to be leveraged. Mitigations may be the detailed business process analysis and mapping of those. Poor documentations also could lead to unknown functionality versus clear service interfaces. System transformations may be disruptive, so proper analysis needs to be happening to make sure that the impact on organization's process and technologies are fully assessed. And what kind of architecture building blocks are involved in this modernization strategy? It could be information service systems architecture, which is phase C of the EDM process. New transformation, new information system services and providing legacy systems functionalities in a service oriented manner. Technology architectures would have a integration platforms that are connected with the legacy systems. And also service container hosting different services and you may have a different container that might be utilized on it. So here it's just, please go ahead for the patterns. Yeah, so besides these modernization strategies, we also looked at the use of enterprise integration patterns, relevant enterprise integration patterns, considering the software enabling. So they provide the capabilities actually to service enable legacy applications. I'm not going into too much detail about these patterns itself, most of you will be familiar with them. But how we talked about it was to map them on this matrix of cost and complexity. And what you actually see is that if you look at directly related SOA patterns like service bus or redesigning SOA and enablement are on a high cost and medium to high complexity. But the result of it is on a SOA supported infrastructure on enterprise or solution level. While if you go to like screen scraping or Q-based mediation, it's more or less system or provider based. So when we talked about this in the project group and we mapped it based on all our experiences, all our experiences, we actually concluded that if you look at SOA enablement and by using these directly SOA related patterns, you need to see that SOA enablement in the context of the enterprise as a whole. And not only on individual systems. And if you do that, you can actually spread the costs much more across multiple service enabled applications. And not only legacy also new because the actual software infrastructure also integrates both legacy and new. And that can only be accomplished if you do this from an enterprise architecture perspective. Of course, from a bottom up perspective, you can focus on a system to enable to use SOA to enable the openness of that legacy system when there is a direct need for it. But it is our advice from the project group to look at it from a solution or enterprise level. And that also means that the costs can actually be shared. It's not only about technology. Of course, we talk a lot about technical aspects, but we have also discussed and that's very important from a holistic perspective, the effects on organization and process. And a few of them I will mention. Of course, you can SOA enable one legacy system, but you will mostly see that you need to handle it as a transformation program. Especially because it's not only about system, it's also about process. It's also about people and it's also about governance. So that's very important. You will have new learning because new technologies enter the landscape. And that's learning from a development, designing development perspective, but also from a managed perspective. And managing an SOA infrastructure is different than managing legacy systems or any other system. So you will have to, you see that you will get new roles. You need management of change to guide that. It can be an opportunity for people, but it can also be a threat, especially if people have been in a technology for a long time. Because you introduce these new components and also opening up systems to other systems than before and other business processes, the change request procedures need to be extended. And that's absolutely the time to make them organizational wide if that has not been implemented yet. SOA brings the concept of services implement across business boundaries. That also means that current governance roles, maybe on application level, they might need to change. So we need a change program for them. We talk a lot about SOA competence centers when we talk about SOA. Legacy needs to be included in that or maybe even a dedicated legacy competence center when there are a lot of business critical systems on it. And again, it's all about return on investment. So it's really important to work on that and to detail that more. So if you look about these changes and also if we talk about change requests like functionality that need to change, we talk about life cycle. And life cycle is all about governance. And we took a look at the open group for SOA governance framework and we looked at the specific legacy touch points. And there are a couple of those touch points already in the governance framework. And we highlighted them in this part in the guide. And what is really important is that you also need to create guidelines like legacy modernization guidelines. So what patterns are we actually going to use? How are we going to implement those patterns? So you need to work at those guidelines which could be architectural deliverables or the first thing that needs to be done when projects start. Yeah, you see more like process analyze where the legacy functionality is. Make sure it's in the design so that there's a transparency exactly what legacy functionality is being exposed by what service and how are these services related to each other. It's very important to enable that overview. There are a couple of things that we added to this in the guide. For example, there are legacy systems that have a maximum number of users and they have been reached already for years and opening it up to other systems or other services. You might reach a point where we can't actually use it. So you need to check that very well. And the other one is of course integrated security. Integrate the legacy security with the solar security solution that you define. So we went through a set of topics from the guide. There are more topics in the guide but because of time constraints we will not go through that and you are encouraged and you will get the link later to read the guide. Quite a big part of the guide is about two case studies. And actually we use case studies. Also more case studies when we talked about to get these best practices. And also later on to look at these case studies again and looked at how could we improve actually the transformation with some of the best practices that we came up with. So we have a case study on a supply chain solution and one about address management and also about web service enabling legacy systems of a large telecommunications company. And what you will see we will go on quite detail in the guide through those case studies and we end with a recommendation how to improve that journey based on the elder solar guide. And that's also what we want to encourage you to look at your case studies to look at your engagements and to look at the guide and to provide feedback on what you see and also what you can actually add to the guide because we can start like new work on getting more of your input in there. Yeah, thank you youth. So what we actually described a brief overview of the guide and we thought like it would be good to really provide you a little bit guidance on how you can utilize the guide. The best way we thought like it would be better for you to utilize the guide would be to assist the various business drivers as it's been outlined in the guide into your context or into your enterprise. And then consider the hooks we have been providing for the architecture development method of ThurGaff when you're trying to tailor your enterprise architecture process and select one of those modernization strategies for example re-architecting, re-hosting or conversion of languages and evaluate against these strategies during the process how they are being measured and how the transformation has been happening and confront some of those so principles we have discussed in here in terms of granularity in terms of decoupling the existing systems with other functionalities and you know just try to utilize those principles in such a way that it would be providing more business agility to the enterprise. And if there are there are some patterns which are relevant which are highlighted in this guide and utilize those in your context consider advice for the people organizations processes and technologies and don't forget about the security aspects to it because we have to really retest the whole functionality again when you're really doing the transformation. So security is really a critical aspect to that one and establish those metrics on return on investments and baseline them before the transformations and measure them during the transformation journey and try to make sure that the business case has been laid out is properly addressed and you know utilize the ADM process architecture development process and the whole ADM life cycle to manage the transformation. Well thanks very much PJ and thanks very much and in fact we have had a couple of questions come in but the first one perhaps we could take up comes from Carlos Quiroga and he's asking what is the value of SOA maturity assessment? We know that there will always be a gap so perhaps it's better to go to the business case rather than to do a formal soil maturity assessment I think is what he's driving at so perhaps I don't know today or yes could you perhaps expand on the role of a soil maturity assessment in the legacy evolution process? Yeah let me try to answer that Chris and Carlos thanks for the question the soil maturity assessment how we use it in the guide is really to provide input for example also for the migration planning phase because a soil maturity assessment tells where the organization is it might also tell that the organization is not thinking in SOA does not have any SOA-enabled applications or an SOA infrastructure which means that in the planning phase that's the first thing to work on or to plan to have an SOA environment ready of course the business case ARI and 2B architecture will absolutely be done but it tells me about the current state of yeah the SOA level of the organization that means mostly that it will influence my transitional architectures and the planning in the whole evolution No I think you covered it the maturity actually assessment provides what the current state is and how we need to transform and what are your business drivers really needed to be transforming those matured into a to a target maturity state and the business drivers actually drives those tanks and it transformed that in such a way so you could measure them as we go along in this transformation journey so it is actually the business cases already been provided and maturity assessment is one of those transformation journey action items you would do to really baseline your current and then progress forward as you go into the transformation journey so if you don't mind Chris before going to the next questions there is a reference sections in the last slide which people would like to see or maybe here are some of those links we have provided how you can download the guide and there is a tutorial version of the guide is also available and so you can download those as well and if you need to go into what as L2SA project how you can come into work on the next version or sequel of the guide and possibly addressing another hot topics for example cloud computing with so those things would be coming into those so here are some of those links sorry Chris go ahead on the other questions okay thanks to Jay Wojtaj as Carlos has made a comment on your answers to that question it is more than as his leverage phase that the maturity assessment doesn't document the compelling reason to act to go to the desired evolution is the point that he's making and I guess I guess the maturity assessment is one of the things you take into account it's not it's not the whole rationale for doing the legacy evolution I don't know if you want to comment further if not we could move on to it's a question from Adnanah Badival can we have an example of loosely coupled and tight coupled which is really a general sort of question but I don't know perhaps whether you've got any thoughts on loose and tight coupling as it relates to legacy evolution and whether perhaps the fact that legacy systems are more likely to be tightly coupled and whether that gives you a problem yeah I think yeah I think there are lots of examples depending on where you look at in the systems and in the architecture for example tightly coupled might be that that you have lots of code that is actually not modularized and that's actually calling all kinds of parts in the code maybe a lot of intercobal calls and it's so tightly coupled that actually it's very difficult to see the structure within a system but also to be able to reuse part of it by other systems mostly then you will create redundant code which is easier to call and another one is for example database links is tightly coupled where you it's very difficult to see that database are actually linked to each other and when the link breaks then mostly executing runtime you see that hey the link broke while loosely coupled will mostly be that you have put that upper in the stack on the business logic level so there are different examples and different types of coupling that's more about the answer and just to add on what you said I already described the SOA principle about having a business contract or actually the interface contract really abstract the technology implementation from the usage of it so when it's loosely coupled you can integrate different services in a flexible manner and there is a seamless integrations and you can provide more re-usage if it is loosely coupled if it's tightly coupled then you may have to have some issues if you need to reuse those functionality so that's it okay so thanks next guest and to Jake for that one as a specific question from Anton on where can I get more information about the metrics mentioned how they're decomposed and measurable more specific things what scales are used and so on so I don't know how far that dealt within the guide or whether you have to look outside for if you like for specific metrics yeah that's a very good question this version of the guide actually describes the metrics and we haven't really gone into the implementation aspects how you could collect them and report that out but we are actually considering in the sequels to enhance the metric sections as well as how you could use the different deployment models so yeah your question is very valid and guide highlights some of those metrics and as well as how you can measure them in different transformations but it's not very prescriptive at this point in time but we certainly take that advice and try to address them in the sequel of the guide okay thanks thanks for that T.J. I think one more quick question before we move on to the general where do you get it from how much does it cost and so on a specific question thanks for this question Philippe I would like to know how you can calculate or estimate the ROI in phase A before you have defined the target architectures in phases B, C and D which relates to size 12 or 13 yeah this T.J. thanks for the questions what we really suggesting in the in the guide and as well as in the ADM process of the TURGaf is you identify what kind of metrics you would be you know measuring against the transformations process and you identify those and then you further elaborate in the phase B, C and D sections how that would be you know done and you know so what I think probably discussed in this webinar was identify those metrics in the preliminary and the vision sections of it especially in the vision section and then further elaborate once you have the you know the and the target architecture defined you do you want to clarify further or well I think it's indeed a matter of granularity right so in phase A you already work on a first version of the architecture on a very high level and that means that you like you said you identify those metrics and you can already on a high level work on ROE and it will be more detailed when you go through these target architectures so it's a matter of granularity yep thanks okay thanks so that's a for that answer I think as we our time is going to its close we should wrap up the questions how do we obtain a copy of the guide and how much does it cost well the link here download the L2SOA guide that's where you obtain a copy you can obtain it and other open group standards from the open group bookstore you get that from the open group home page and click on the on the tab for for the for the bookstore it costs nothing this is free to download as are most open group standards and guides the there was a question as to whether it provides a reference to the SOA maturity framework and I'm pretty sure that it does and again that's available the OSIM OSIMM open group service integration maturity model is available again from the open group bookstore and there's a specific reference I believe in the guide so I'd like to thank again TJ and Jast for this this excellent webinar and thanks Simon for for setting it up and most importantly to thank everybody who participated of those who asked the questions and those who who listened for your attention and thank you all and we hope we'll see you again at other open group webinars many thanks to everybody