[MUSIC] By now, you've heard plenty about the journey to modernization of core applications. Given the importance of these applications, that journey should be incremental with the goal of minimizing business risk. These modernization efforts might involve building new services, or rewriting, or enhancing existing application components as a Cloud-native applications. Most likely these new applications and services will need access to core applications and data residing on IBM Z. So, how do we modernize these business critical applications, minimizing risk without negatively affecting service level agreements? Well, that's what we're going to discuss with some examples in this video. The court of this is a solution that co locate new applications on IBM Z, closer to the core applications and data that those applications need to access. Which reminds me of a story, this guy is out hiking. It's getting late, so he pitches his tent in the first clearing he can find. Early next morning he grabs his camera and a coffee and heads for an eastern facing overlook, where he's greeted by a wonderful sunrise. He sets down his coffee, turns on the camera to take a picture, but, no, the SD card is still in his backpack back at the tent. So he rushes back to the tent to retrieve it and in his haste stumbles spraining his ankle. He grabs the SD card hobbles back only to find that the wind has knocked over his coffee and the sun is now hidden behind a cloud. If only a hiker had co located their tent in the place that they needed it, the site of the sunrise. Instead they experienced network failure, spraining an ankle between the two sides, security exposure, unattended coffee that was blown over, and most significantly latency missed the sunrise. IBM Z hosts system of record or SOR data across multiple lines of business. Applications residing off platforms such as distributed platforms or public clouds need access to this core function and SOR data on IBM Z. And as a result of being off platform, could suffer from an order of magnitude higher latency coupled with lower throughput. IBM Z provides the runtime environment to run both Cloud-native applications as well as for migrating existing distributed applications to IBM Z. Co locating supporting applications on the same platform also called SOR applications just makes a lot of sense. Now, consider this example to develop and deploy new Cloud workloads. A credit card provider uses kicks with business logic written in COBOL and Java and DB2 as the system of record. The system receives incoming credit card transactions from mobile apps and point of sale systems. The provider decided to add fraud detection capabilities and wanted to have it in transaction to catch fraud before it occurred. By keeping the influencing logic on IBM Z OS, the provider was able to achieve ultra low latency in transaction fraud detection. Had this solution resided off of IBM Z, several network hops would be introduced for each transaction introducing latency. Let's look at another example related to migrating existing Cloud applications for efficiency. An organization performed a batch jobs each night and as part of a past modernization effort, migrated a piece of the business logic to Java micro services running on open shift on distributed hardware. There was significant latency due to network hops, and this was causing the organization issues with meeting their batch processing Windows. As IBM Z supports Java with industry leading performance to boot, they co located their application to the Z platform without needing to change code. Latency was significantly improved and batch Windows times were reduced by an order of magnitude. One more, illustrating incremental modernization without significant business risk. An organization wanted to modernize their monolithic website application server that access IBM Z DB2. The website application server business logic ran on a distributed platform, and they saw an opportunity to co locate with their system of record on DB2 to improve throughput. They re hosted their insurance record processing application on website application server Liberty, without needing to change any code. Moreover, due to the scale up capabilities of IBM Z, they could containerized there monolith application without needing to convert to microservices first. Ultimately, the outcome of all of these examples is lower latency, which translates to higher throughput, and eventually to reduced total cost of ownership plus a host of other benefits, including business continuity, a secure end to end pipeline, and offerings to address data sensitivity requirements. You have choices on where you deploy this workload on IBM Z. You can deploy it natively in z/OS as in our first example. Or application deployment can occur in a native Linux distribution with a container runtime, such as docker. Or within an IBM Z container extensions environment. So, first thing in the morning, with the sun rising gloriously above the horizon, think about how you can continue an incremental journey with adoption of Cloud native services without having to rewrite entire applications, or take a high risk with core applications. [MUSIC]
