Determining the best platform to host your workload can be a difficult, risky decision. With seemingly endless choices that all claim to have similar characteristics, the search for exactly the right platform to meet your requirements is daunting.
With the recent introduction of the IBM zEnterprise System, which more tightly integrates different platform architectures while expanding the qualities of service traditionally recognized on mainframe systems, there are even more choices to host your workload.
Making a wrong decision could mean you will have trouble meeting your Service Level Agreements (SLAs) for availability, performance, or security. In addition, a wrong decision may result in an increased Total Cost of Ownership (TCO) that strains your budget and prevents you from investing in new business.
Many general purpose servers can meet functional requirements. Much of IBM’s middleware is certified to run on many different platforms—from small x86 architectures to the largest System z. For instance, the WebSphere Application Server can be deployed on Windows systems and z/OS systems. The implementation is slightly different to take advantage of some System z services, but functionally, they’re essentially equivalent. An application that’s developed to run in WebSphere on one platform, as long as it follows standard Java practices, can easily be moved to another platform with the same functionality.
However, what determines the optimal platform for a workload is how well the work runs on that platform in a specific environment. These non-functional requirements and other local factors can include both technical and non-technical characteristics. Some of the technical, non-functional requirements include availability, performance, scalability, security, and manageability. Some of the other non-technical, local factors include your skills, standards, organization, and independent software vendor support. All of these considerations are inputs that can help you make platform deployment decisions.
IBM has created a platform selection process that can help you wade through these considerations and determine the TCO for potential platforms. This process consists of three optional parts: a fit for purpose assessment, a TCO assessment, and a technical validation. This article examines the fit for purpose assessment and includes the assessment of local factors against candidate platforms. IBM has several TCO assessment offerings that complement the fit for purpose assessment; for more information, refer to IBM’s Scorpion, Eagle, and RACE studies. The technical validation part includes hands-on assessments, such as proofs of concept and benchmarks. Any of these can be included to help make platform selections.
The fit for purpose process helps you assess candidate platforms against non-functional requirements and other local factors for a specific workload. While many IBM clients have asked for a standard matrix or algorithm, the assessment really depends on your specific environment. For instance, an environment may not be running at the highest levels of availability because the cost of setting up a completely redundant configuration exceeds the value gained from having that high availability. It doesn’t matter what the platform can theoretically achieve for availability since it’s configured for a lesser level. So, multiple platforms could meet or exceed requirements. IBM typically does the fit for purpose assessment in a workshop format.
The Fit for Purpose Process
The first step is to select a workload to assess. The workload doesn’t need to be new; the assessment can be done with a workload that’s currently running but isn’t meeting necessary operational characteristics. It might not be meeting the SLAs or managing the environment might be too complex. We generally look for a workload that contains some mainframe content but may have distributed content, too. If a workload is currently running well and there are no operational issues, there’s no need for this type of assessment.
Once the workload has been selected, the next step is to build a list of local factors, including technical and non-technical requirements. This activity usually occurs as pre-work that’s validated during the workshop. There are many constituents, including architects, engineers, and operations, who can supply these local factors. Don’t worry about the significance of the requirements; they’ll be prioritized and weighted in the workshop. Remember, however, that these aren’t functional requirements so the focus shouldn’t be on what the workload should do functionally, but how well it should do it. The fit for purpose assessment won’t address functional gaps. Also, don’t worry about the length of the list since it will be pared down in the workshop.