Modernization goals and approaches
So, you want to modernize your IT environment. Where do you get started? The first thing to consider is your goals for modernization. These goals need to be SMART:
•Specific
It might take some time to get the wording correct, but it is important each goal is clearly defined.
•Measurable
This metric enables you to gauge progress and impact as you implement each goal.
•Assignable
You might not set specific roles when setting your goals, but you must think broadly about which teams are to be assigned to each goal.
•Realistic
You might want to set some stretch goals, but most goals must be achievable within their set scope.
•Time-bound
Having goals that are measured or restricted by time helps to focus the team and prevent a goal from growing to encompass more than originally intended.
This chapter discusses how to set modernization goals, different modernization approaches by using IBM Z, and where to begin your modernization journey. It includes the following topics:
2.1 Setting modernization goals
Every company is unique, with varying requirements and IT configurations. Even within a company, what works for one group might not work for another. As an organization, whether you are about to embark on your IT modernization journey or you already began, it is encouraged that some self-assessment is conducted periodically. This effort provides a clearer picture of the state of your IT setup and serves as valuable input for your short-term and long-term goals.
For example, you can self-assess by using questions similar to the following examples:
•What works for you today and will it remain strategic in the future?
•What does not work for you?
•Does your IT setup allow agility so requirements can be made quickly?
•Where is the industry heading in terms of the IT system?
•Is your investment in IT modernization generating the kind of return on investment (ROI) that you expected?
•How does your IT setup fare in comparison to that of your competitors?
•What are the technical skills in your IT organization today, and do the same skills continue to be relevant in your wanted future state?
•What is the extent of technical debt in your organization?
•What kind of platforms are used today? Are these platforms suitable to enable your modernization journey?
After you acquire the answers to these questions, prioritize the problems that you want solved. With this information, you are in a much better position to make an informed decision regarding the modernization journey of your IT setup.
Try not to jump from the problems to be solved directly to their solutions; that step in the process comes later. (It is no coincidence that not a single product or offering was discussed thus far in this publication.)
Figure 2-1 expands on the three phases of a modernization journey as discussed in Chapter 1, “Introduction to modernization” on page 1.
Figure 2-1 Phases of IT modernization journey
From our example that is presented in Chapter 1, “Introduction to modernization” on page 1, after understanding their current state, Company A begins thinking about their wanted future state. Some of the goals Company A decides on setting for their modernization project include the following examples:
•Deliver code changes more frequently with higher quality.
•Reduce the number of manual steps that is needed to promote code from a development sandbox to the test environment.
•Enable connections to data and transactions on IBM Z from other platforms by using industry-standard APIs.
•Improve performance of core applications running on IBM Z.
•Encrypt all client data without requiring application changes.
•Leverage machine learning technology to increase the effectiveness of security monitoring.
As we discussed in Chapter 1, “Introduction to modernization” on page 1, modernization goals can be classified into three categories: infrastructure, application, or process. We discuss these categories next.
2.1.1 Infrastructure modernization
Every new generation of IBM Z includes innovative features; however, you cannot benefit from some of these features if you do not activate them. In the case of infrastructure modernization, it is not merely a matter of keeping your IBM Z systems current; rather, it is updating how you configure them to ensure that you realize the utmost benefit.
Figure 2-2 shows a high-level view of the different layers in an infrastructure stack.
Figure 2-2 Typical infrastructure stack with end-to-end encryption
Comprehensive modernization plans take each layer of the infrastructure into consideration. For example, if you want to modernize applications and how applications are developed on IBM Z, it is important that your middleware products and operating systems are also modernized.
Similarly, to modernize the operating systems, you must have the proper features available and enabled on your hardware. This availability ensures that you use all of the capabilities of the IBM Z platform and applications that are running on it. Consider asking questions to assess what works for your organization and what does not, including the following examples:
•How often does your hardware team consider implementing new features?
•What is your upgrade strategy for your IBM Z systems?
•Is your IT infrastructure resilient to failures and cyberattacks?
•Is your IT infrastructure designed for near-continuous availability?
•Can your IT infrastructure continuously deliver optimal performance with varying workload?
•Can your IT infrastructure handle an increased workload as a result of a planned outage, and quickly catch up with the lost time after everything is back up and running?
•Is your IT security team highly stressed and concerned about data breaches?
•Is your data security encryption algorithm and key quantum-safe?
2.1.2 Application modernization
The focus of application modernization is to build off your applications with minimal changes. Three approaches are available for this type of modernization, each with multiple entry points.
Each well-scoped business requirement can be an entry point to application modernization and can be addressed with a specific solution. These modernization approaches are independent and can be run in parallel. Some approaches and entry points are less complex and can deliver immediate value, such as exposing assets with REST APIs to make them easily accessible and consumable by cloud and mobile applications. Other approaches might be a bit more involved.
In this section, we briefly describe the following approaches and their entry points:
•Approach 1: Expose core mainframe assets
•Approach 2: Containerize and deploy new cloud workloads
•Approach 3: Transform core applications and data assets
Approach 1: Expose core mainframe assets
This approach includes the reuse of long-term investments that are made on business-critical applications that are running on IBM Z by exposing them as OpenAPIs to ease interoperability with other applications. A key business benefit to this approach is that no new code development or code changes are required to access core applications and associated data.
Also, it helps to avoid the need for complicated interfaces to access mainframe assets, time-consuming development to allow integration, or multiple runtime environments.
This approach delivers a key capability for enabling digital transformation and hybrid cloud solutions, which demand new ways of delivering services through new channels and enhanced interactions with cloud-based solutions.
For more information about this approach, see 3.2, “Enabling data accessibility on IBM Z” on page 30.
Approach 2: Containerize and deploy new cloud workloads
This approach focuses on cloud-native application development, with a focus on containerizing existing applications and building new applications with cloud-native technologies. These cloud-native applications can integrate with data and are optimally deployed across, and managed within, the hybrid multi-cloud because of their containerization.
You can deploy cloud-native applications on IBM Z without compromising application development approaches. Some of these architectures and methodologies include microservices, container-based deployment, and Kubernetes or open standards-based service management.
Cloud-native development, with its “develop once and deploy anywhere” philosophy, and the myriad of open source tools that can be integrated to streamline an automated process, revolutionized the DevOps strategy of developing and managing applications. For more information about cloud-native development, see 4.5, “Code” on page 44.
Approach 3: Transform core applications and data assets
Applications that run on IBM Z often were used for many years and underwent numerous evolutions in their lifespans. Application developers altered these programs to meet an endless number of evolving business requirements. An unintended consequence of this long history is that the code for these existing applications can be complex.
To make matters more challenging, home grown business logic is not always fully documented. Although new requirements emerge for accessing data, it is a challenge to use data from your traditional applications’ databases without developing complex application logic as the data model grows along with the application. It is difficult to re-create any of this logic without a deep understanding of the applications.
Because you must keep the business running, the transformation of core applications requires careful, incremental approaches. This approach is critical to address these concerns as it focuses on incremental transformation of mainframe applications through refactoring and modern development approaches.
To modernize such processes, you might consider breaking monolithic applications into several application components. Each component implements a higher-level business task. Then, one or more application components are exposed as APIs that the new business process application can use to compose an agile business process.
You might also consider refactoring the code incrementally, which is aimed at simplifying the code without changing its behavior, which improves the maintainability, flexibility, time-to-market, and above all, the lifespan of these proven programs. Consider externalizing business rules and policies that are embedded in mainframe assets so that these rules and policies are easily accessible and usable across the organization over standard protocols.
When refactoring, you might also consider supporting development in the latest programming languages that complement programs that are written in other languages. This approach not only helps in improving agility, but also to extend existing, or develop new, applications that manage systems of record data.
2.1.3 Process modernization
DevOps practices can help you transform the processes that you use to deliver your mission-critical applications without sacrificing stability or security. Combining a common developer experience with integrated and open source tools, and a streamlined process for developing and maintaining existing and new assets across platforms provides many benefits. Modern development software act as enablement tools making it easier for development and operations to perform the following tasks:
•Analyze and plan: More accurate planning through identifying the effect of a change and its associated risks by identifying dependencies between different IBM Z applications across the enterprise.
•Code and build: Faster application development, testing, and problem determination through integrating IDEs and various product suites to aid developers, and by automating the process of compiling and linking incremental changes.
•Test: Run tests earlier in the lifecycle, or in parallel with other tests, through automation, both of which decrease time to deployment.
•Provision, deploy, and release: Simplify deployment and release management while enabling audit trails and automated tracking of feedback.
In addition to DevOps, modernizing other processes also realizes many other benefits. For example, tracking transactions and monitoring the correlation of application, transaction, and system resource performance data on IBM Z can provide valuable insights, predict failures, and alert support staff for necessary corrective action. User-friendly monitoring products can be customized to suit your requirements to empower the operations teams.
For more information about DevOps on IBM Z, see Chapter 4, “Introduction to DevOps” on page 39.
2.2 Where to start
Modernization is not about putting your applications on a cloud offering. Rather, it is about the use of the significant business value of your investment in IBM Z and enabling it to become the center of your hybrid cloud, which is unlocked through modernization.
Figure 2-3 shows some entry points into a modernization journey. Each of these entry points can naturally pull in the adjacent areas as the journey progresses.
Figure 2-3 Modernization entry points
Modernization comes in different categories and approaches. You can approach modernization in various incremental ways with, or without, the need to change the underlying code.
Where you start depends on the level of modernization that is required based on your needs and priorities. In this section, we discuss approaches on how to decide where to start your modernization journey based around the following topics:
•Disruption to your business
•Business risk
•Specific drivers to modernize
•Teams affected
•Business continuity plan
•Questions for IT team
•Questions for application developers
•Role of an IT leader in the journey to modernization
Because you need to maintain availability always during modernization, the transformation of core applications requires cautious, incremental approaches. We discuss later in this section conversation starters to consider that can aid in planning your modernization project.
Disruption to your business
Most teams consider a production outage that is caused by a project to be a significant failure. Some questions to ask when considering a potential disruption to your business, include the following examples:
•How much time is needed for project completion?
•Does this project require education to build the team’s foundational knowledge before implementation?
•How long after completion will it take to see a positive ROI?
•How can this project be implemented without taking down existing systems?
•Is there a fallback plan if problems arise when deploying to production?
In general, you want to start a modernization journey with a project that has a low likelihood of causing major disruptions. After a few projects are successfully completed, you can apply the lessons from those projects to a project with a higher risk of disruption.
Business risk
Part (but not all) of the risk that is assigned to a modernization project comes from the potential disruption to the business. In the case of a modernization fall out, it is important to make specific considerations, such as the following examples:
•What are the worst- and best-case scenarios for this modernization project?
•Is the amount of risk that is introduced by this modernization project acceptable?
•What steps can be implemented to reduce the risk that is associated with the modernization project, and how long does it take to implement these steps?
The suggested practice is to start a modernization journey with a project that has no more than a moderate amount of business risk. You want to select something that demonstrates considerable benefits with an acceptable amount of risk.
Specific drivers to modernize
Modernization can be done for many reasons and to meet many objectives. You can ask yourself several important questions, such as the following examples:
•Are you implementing modernization projects to improve user experience?
•Do you have the latest technology and are you fully harnessing the new technology?
•Are you addressing issues of skill-gap with this project?
It is important to periodically reflect back on your modernization drivers to ensure that they are being addressed during planning and execution. This review prevents the project from drifting off course.
Teams affected
It is not only the IT department that feels the effects of modernization. It is crucial to understand how all areas of your workforce might be affected, even if they are not working with IT infrastructure directly.
IT departments are directly affected by modernization because they are tasked with the implementation of the selected modernization solution. They are also expected to be well versed with the modern technology and to confidently implement the modernization steps in a near flawless manner. This staff not only is affected during implementation, but also as they use the new solutions going forward.
Other departments might also feel the effects of modernization, even though they were not tasked with the implementation. Therefore, it is important to consider how the modernization affects other teams.
It also is imperative to the success of your modernization journey that you be prepared for extreme scenarios through performing a thorough risk assessment with all affected teams. The suggested practice is to start your journey with projects that are simplified by affecting only a small group of people.
Business continuity plan
To help you be better prepared in the case of modernization tasks having major effects, you can ask many questions, including the following examples:
•If an unforeseen issue occurs, is a fall-back plan in place?
•Is an escalation matrix available for you to contact the required personnel if you need help during the back out plan?
•Is your expert team equipped for what needs to be done and how to fall back successfully, if need be?
Questions for IT team
As a part of the planning process, several important conversation starters are available to begin discussions with your team, including the following examples:
•Do you have a list of key business areas or business processes that run on IBM Z?
This list helps you understand the potential for modernization with IBM Z across your business.
•When was the last time you took an inventory of the features that were added with your latest IBM Z hardware to make sure that you squeeze every last drop out of your investment?
This assessment can help you identify a hole in your upgrade process, and find ways to improve your implementation.
•Are all the key features of your current IBM Z environment used?
This question helps in identifying the key focus areas of modernization.
•Are there any factors, such as back-leveled infrastructure, skill availability, and subject matter expert readiness, inhibiting the journey to modernization?
Questions for application developers
As a part of the planning process to modernization, some of the following conversation starters can be used with your developers and identify appropriate DevOps solutions:
•Which, if any, agile methodologies do you use in development, testing, and production deployment process?
This question helps in identifying the type of DevOps solutions from which to choose.
•How quickly can you release a new application or update?
This question can help prompt a conversation about which tasks take the longest amounts of time and how that process can be improved.
•Are you aware of any tools for application development that can make your job easier?
This question helps you identify potential ways to enable developers that are using new tools.
Role of an IT leader in the journey to modernization
IT operations teams are becoming strained as applications are changing at a more frequent pace, and application architecture is becoming complex and heterogeneous. Skilled personnel are retiring, creating skill gaps while budgets are seldom unlimited.
IT leaders play a key role in the digital transformation process, as leaders are responsible for making informed business decisions to set their plans and strategies in relation to modernization.
The details that the IT leader at Company A implemented to help with collaboration include the following examples:
•IT leader: Sets initial strategy and make key, high-level decisions.
•Core team: The key personnel from the technical team and their immediate managers that are responsible for implementing the modernization project.
•Stakeholders: The key personnel from a business perspective for decision making in the modernization project.
•Phases: The high-level steps of modernization, with target dates.
•Governance: How the team tracks and monitors the progress of the modernization project. This issue must include key metrics and the tools that are used to gather them.
Now that we reviewed at the key technical and business considerations that are part of a modernization strategy, we bring everything together and briefly define the strategy of Company A in Chapter 3, “Modernization technologies on IBM Z” on page 25.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.