 Good morning, good afternoon, good day everybody. Welcome to this the third in a series of webinars on IT for IT. It's my pleasure to introduce our speaker today, Sue Desiderio, but before I do, just to bring you up to date, we published the new IT for IT standard on the 20th of October. Since that date there have been a round of 3,000 downloads of the technical standard from the open group site. 1,500 individuals from 500 organizations have looked at the collateral. And today we're going to have Sue, one of the longest serving subject matter experts in the forum, walk through one of the four value streams for us. So on the call today we have as well as Sue from PricewaterhouseCoopers and myself from USF, other forum members from RTOS and CapGemini, potential new joiners from Bayer and so on, so welcome all and welcome to the rest of you. So without further ado, I will hand over to Sue and look forward to rejoining your conversation at the end of her presentation. Thank you Chris and welcome all. So today we will be doing a deeper dive into the requirement to deploy value stream, but first we'll start with a little background on the overall IT value chain. So the IT value chain within the IT for IT framework is used to describe the operating model for the business of IT. It includes primary activities which are depicted across the top of the diagram as plan, build, deliver and run. And this can also be thought of as planning, production, consumption, fulfillment and support and is realized by the IT for IT value streams. It also includes supporting activities such as finance, human resources, governance and supplier management. These activities are tied together through the IT for IT reference architecture. A core concept of the reference architecture is the service model. Here it is depicted as a lifecycle across the value streams, conceptual, logical and realized. In the planning stage, the service model is conceptual in nature. Think of it as a marketing plan for the service, the product of IT. What does the business need need to address? Who are the customers? What is the value to them? And how much will it cost? And when do we provide it? That model becomes logical in nature when it is built or sourced externally. These are development and integration model elements such as system design, source, build and deployment checklist. It then can be released, published as a service that can be subscribed or deployed directly into a run status, which is the realized service model. Finally, it can be ordered through a catalog subscription process. Here's a view of the overall IT for IT reference architecture. The focus on the architecture is on the data and functional components, not the processes that comprise these activities. Any organization's methods and processes will change over time, but the underlying data about the service lifecycle remains constant. The blue boxes represent functional components. Think of it as the smallest applications or tools that really support that specific function. The black circles are data objects and are really those key data objects within the whole reference architecture. The solid lines are relationships between data objects. And the purple circles are special types of data objects from the service model backbone. And this truly is what brings the whole IT for IT reference architecture together. By stripping away the functional components, we can see the end-to-end nature of the data and the relationships. And again, with the purple objects at the bottom, you can see how the service model is indeed the backbone of the whole reference architecture. This is known as the system of record fabric of the architecture. Think about how difficult it can be today to tie information together from different parts of the IT organization. This architecture allows us to tie the key data together, enabling IT leadership with the information they need to run the business of IT. Let's look at the value streams a little more closely. Strategy to portfolio is focused on planning, defining objectives and aligning them to business and IT roadmaps. Requirements to deploy are focused today. It's focused on building or sourcing, turning that investment decision into services, planning the work or approach, designing and developing the needed solution, whether it's in-sourced, outsourced, composite, cloud, and then testing that application against the requirements, be it functional, performance or security. The last step is releasing and deploying the service, either via a service catalog or into production. Request to fulfill is focused on delivering, making the services available to a consumer through a catalog. And Detect to Correct is focused on keeping the services running in production. This is possible because of the interlinked reference architecture that defines data and their relationships across the service lifecycle. The reference architecture is the prescription that delivers end-to-end data relationships for traceability. It allows IT to become repeatable, predictable, coherent, and future safe. There are four phases in the requirement to deploy value stream. Plan and design, develop, test, and deploy. Keep in mind that this is continuous development activity, not a one-time activity or even necessarily sequential, and the phases are intertwined. For an example, an agile methodology project may have all four phases happening every week. Plan and design. You can think of this phase as taking the concept from planning and create a more detailed, logical view of what the service is. It starts with a scope agreement, which comes from the Strategy to Portfolio Value Stream, and creates an initiative to manage the overall work. Logical design then builds on the conceptual design and incorporates the functional and technical requirements as well as IT standards and policy. Develop. Development, be that integration, sourcing services, writing code, happens in all methodologies, whether it's waterfall, iterative, agile, or others. And this development is packaged based on specific versions of the many components which are used within that service. Develop also includes developed team testing, such as unit testing. Test is really focused on three main areas. Is the service functional from all user viewpoints, desktop, web, mobile? Is the service meeting performance criteria across multiple usage levels and devices? And is the service secure? Inspecting the code and probing the up-and-running service. Deploy. Deployment starts with a release plan that documents the parts and versions which come together to create that service. Think of all of this as a model. The plan includes a lot more than bits and bytes of computer code. It also needs to integrate into IT's change and configuration management processes. It needs to include knowledge about how to operate and troubleshoot issues. And it needs to include how to monitor availability, performance, and security aspects of the running service. To understand how a user-centric world influences IT building services, let's look at how the four major phases of requirement to deploy are impacted as we move from a two or three times a year release schedule to a more continuous delivery model, where releases could be every month, every week, or even more frequently. So in plan and design, traditionally we define everything needed for a new service and only then start a large development effort. Today, our customer expects an initial version quickly with a few key use cases working then incrementally release new functionality in response to user feedback. Develop. In the past, the most common development method is to put everyone in one building and start driving the development process. Today, we need to be able to support, which is virtually a global assembly line where virtual teams are empowered to integrate and build different parts of the service. Test. The old testing approach was to wait until the service was finished to engage the testing team and then build out the test environment, whereas today, to meet the continuous delivery goal, testing needs to be closely integrated into the whole development process, testing little bits of the service as it is created, and to leverage tools that quickly and consistently stand up test environments. Deploy. Deployment has been a process of collecting many parts and tossing them over the wall, letting the next team engineer solution to get the service operating. Now, the goal is to leverage a deployment model of the service, the same model used in testing, to quickly and consistently deploy a service. IT will be a mix of waterfall and agile development models for years to come, and the requirements deployed value stream is agnostic to development methodologies. The value stream provides a way to improve both models and maximize the effectiveness of the build and deploy phase of the service lifecycle. Let's focus on the IT reference architecture itself. These are the functional components within the full IT reference architecture that represent the requirements to deploy functions. The project component, responsible to receive scope agreements, provide ongoing execution oversight of IT initiatives aimed at the creation of new or enhancements to existing services. Requirement component, managing requirements to the lifecycle of the service, maintaining the traceability of each requirement to the original request that generated the portfolio backlog item throughout the service lifecycle. It's responsible to collect, refine, scope, and track progress of the requirements. Additionally, as you look at some of your agile methodologies in the requirements component, you would also manage things like your portfolio backlog, your product backlog, and your team backlog. Service design component. This is where you create the logical service blueprint for the services. You ensure that they meet the requirements from the scope agreement, the IT initiative, and or portfolio backlog item, and make it perform against the key performance indicators or key risk indicators and service level agreements. The output of the service design functional component is used by the source data object to guide source, create, and secure the service. Test component. Plan, store, and execute tests which ensure that the service will support the customer's requirements at the agreed service levels, including system integration testing, user acceptance testing, performance testing, and load testing. Source control component. Ensure that the service is developed in accordance with design specifications, organizational standards and policies, and both functional and non-functional requirements so that the service can be operated successfully and in line with customer expectations and requirements. Produce and manage source and documentation which is then stored. The build component. Create, manage, secure, and track builds. Implement build automation. Manage the delivery of builds to the build package component. The build package component. Manage the creation of the build package consisting of one or more builds and also managing the deployable package. Defect component. Keep track of all the defects, including their origin, status, importance, and relation to requirements and known errors. The release composition component keeps track of the different service releases, defines the structure and content of the service release, and its underlying components, including the instructions of how each component can be deployed. This is a level two architecture of requirement to deploy. It is a more detailed view of the components, data elements, and relationships. The gray functional components, which you can see on the outside edges of the diagram, are the supporting functional components or functional components that come from one of the other value streams. And again, these connections show how and to end the IT for IT reference architecture is and interconnected. As you can see, requirement to deploy uses information from strategy to portfolio, as seen on the left, in the form of skills agreements, conceptual service blueprints, policies, and portfolio backlogs, all coming in as inputs into the requirements to deploy value stream. From the detect to correct value stream, there are additional inputs coming into requirement to deploy that include incidents, problems, and known errors, as these are work items that must come back into the build service solution to be remediated. Requirement to deploy information that goes to detect to correct are things like requirements, which feed into service contracts, and also requests to open up requests for change in the change management processes. Requirement to deploy also feeds into service catalog entries, and ultimately the desired service model, which are stored and managed in the request to fulfill value stream. Again, concrete examples of the end-end nature of the IT for IT value chain. On the last side of this presentation, there are links to other resources, which will provide more detailed definition of each functional component, each data artifact, and all the relationships. The requirement to deploy value stream helps you drill down to the functional components and data associated with defining, building, testing, and deploying an IT service. By examining and understanding the key underlying elements of this stream, you become much better equipped to control the quality, utility, schedule, and cost of any service you deliver. IT and the business gain from improved philosophy and greater quality, comprehensive insight into distributed team activities and deliverables, and true data on service costs and quality. The requirement to deploy value stream gives you a framework for creating or sourcing a new service or modifying an existing one. This value stream spans the activities and decisions that start when a approved scope agreement is received and continues through the deployment of that contracted service. The goal is to ensure predictability, cost effective, high quality results, and everything IT delivers to the business. The requirements to deploy stream also promote a high level of reuse and flexibility, which helps you support new methods of creating and sourcing services. Think about things like DevOps and Agile. Consistent with our overall value stream strategy, the focus is on the data and functional components, not the processes that comprise these activities. Any organization's methods and processes will change over time, but the underlying data about the service lifecycle remains consistent, giving you more control than you have today with ad hoc data artifacts, unsupported by an open standard and with each tool vendor delivering and managing those data artifacts differently. To justify the overall value that IT delivers to your business, you need solid metrics. As you apply the requirements to deploy stream, you can use KPIs to measure and document. And I'm not going to go through every single KPI individually, as there's three pages of KPIs, but just to give you an example, we have KPIs around improving quality, you know, percent of actual versus planned executed tests, improving project and feature execution, improving the stewardship of IT investments, increasing the automation adoption. Automation is really key as we start moving into the new delivery methods. Achieving development process excellence. Again, present of requirements traced to testing, changing results and incidents, and improving early life success of releases. Percentage, reducing percentage of incidents during warranty and percentage of emergency changes. Improve financial visibility. Plan costs versus actual costs. Maintain a linkage between business services and IT initiatives so that we can roll up all of the information. High quality service design specifications at the outset. Integration test success. Design review to ensure application design compliance with all policies, including security. And again, security is one of those things that's baked in throughout the whole IT value chain and all the value streams. And early testing of applications for security vulnerabilities. So with this, Chris, it ends the pre-formatted slides, but I did want to open it back up to questions and I will turn it back to you. Thank you very much, Sue, for a really interesting presentation. The link on the screen at the moment to the forum's website on the OpenGroup website will take you to many more resources which will extend further your understanding and appreciation of the potential of this new technical standard. I'd also like to flag up some recently posted testimonials from the likes of Delta Lloyd Insurance in the Netherlands and Royal Dutch Shell, where we have video testimonials from senior enterprise architects and executive sponsors of this initiative that highlight the value that the new standard is already delivering in their organization. So Sue has presented one of the four value streams and provided a really comprehensive overview. How does this compare to ITIL? This is one that I'll respond to initially. IT for IT is a standard reference architecture, so highly complementary to the more textual guidance offered by the ITIL framework. So this is a technical standard which offers off-the-shelf prescriptive guidance for the four value streams. The benefit of the approach to the standard that we've taken by working with the OpenGroup is that we followed the TOGAP formula so that we can accommodate some of the guidance already in ITIL. So you saw Sue present the value stream in one of the earlier slides. Governance is a strong supporting activity of the whole reference architecture, so the guidance in ITIL can be accommodated within the IT for IT initiative. So what we provide is a reference architecture for the business of IT, which is quite specific and much more prescriptive. So in addition to the models that Sue has presented today, we have articulated the reference architecture using the OpenGroup's Archimate language, and the forum has a substantial SPARX repository of those prescriptive materials that can be brought into operational use a lot more quickly than the more textual emphasis of frameworks like ITIL. So that's a response to Ronald's question. We've got a question there from Gerardo. It says, how is IT for IT integrated with ITIL? You may have answered that already, Chris. I think so, yes. They're highly complementary, and as I say that they are, if you will, acknowledgement of each other's strengths and weaknesses, but the reference architecture is distinct and very potent because of the technical prescriptive guidance that it offers to practitioners with complex briefs like Sue, who are responsible for choreographing the business of IT across a complex organization like PricewaterhouseCoopers. So again, I think one of the best ways to respond to that question is to take a listen to the likes of Rob Arkeshoke from Delta Lloyd or Mary Jarrett from Shell, who talk about their initial experiences with the benefits and complementarity of this new prescriptive technical standard. Question from Ahmed says, what's the difference between IT for IT and Togath? Togath is a framework. We have been guided by Togath in the development of IT for IT. They don't compete in any sense. IT for IT basically follows the Togath Crop Circle, and we have been good open group citizens in adhering to Togath methods and practices in putting the reference architecture together. So again, highly complementary, but we are comparing a generic framework in Togath to a very specific reference architecture which is focused specifically on the business of IT. When will Archimate be updated to include these artifacts? This is a question from Ronald. That's a work in progress. As an open group forum, we liaise very closely with the other forums, and we have liaisons into the architecture forum. That's an ongoing process because obviously Archimate is a living language, so that continues through the work using the Sparks repository and the articulation of the IT for IT collateral using the Archimate language. Looks like you've come to the end of the questions there, Chris. I think so, Simon. Sue, many, many thanks for a wonderful presentation. Always good to hear from you, and to the attendees, many thanks for your interest today. Please don't hesitate to contact myself or Sue or Simon if there's any more information that we can give you on the forum, and we hope that you find the material useful and look forward to working with you.