ZAC - vision setting - where do we want Zowe to be in 2 years

[armstro]

One take away from the discussions with Node.js team was to have a vision of where we would like to see the project at some future date. Node mentioned 10 years? I recommend we pull in the target to 2-3 years?

Ideas:

• Zowe to be the preferred (or defacto standard) interface to z/OS services
• Zowe services have two deployment options :
• 1) easy USS deploy/configure
• 2) portable containers with a bias towards zCX deploy and configure (exploiting its adjacency to z/OS)
• Zowe stay with the principle of "All of the old with all of the new" - with continued focus on next generation IT staff
• Zowe exploit its fast time to market (compared to traditional z/OS products) to drive innovation
• Zowe follow the "app store" model of VS code or NPM registry with a variety of open/free apps for selective download with easy install/configure (and removal)
• Zowe to be a suite of services that consumers can pick and choose to deploy
• Zowe created an added layer of security to the already secure z/OS systems
• Zowe core optionally orderable with z/OS

[PeterFandelAtRocket]

1 Yes

2 Not sure about " bias towards zCX deploy and configure (exploiting its adjacency to z/OS)". Does it need mentioning? I want to get feedback from others e.g. Sean whether the z/OS adjacency is a notable benefit as compared to Linux/Z? Also, how about an iii? The entire Zowe dev community all run all of the so called z/OS Zowe components (except ZIS/ZSS) off Z when developing. Why the heck not offer this formally an an option to consumers wanting to do in-house tool/app dev on Zowe to lower cost and increase independence from Z ITS? Is it the thou-shalt-not reduce Z workload rule?

the rest of bullets - I like all the others as is except 2nd to last which I don't understand

The only additional bullet I could think of is "something" to do with promoting acceptance of USS, making Zowe part of USS in some way - anything to move the needle on USS-literacy and acceptance since it will help with up-and-running

[pdubz3]

Peter, your reference is to "Zowe created an added layer of security to the already secure z/OS systems"?

I think we agreed on a recent call that this should be reworded. It's not really within scope for Zowe to add a security layer, implying that Zowe is somehow a player in the security business. However, we're facilitating access to mainframe services, and that needs to be seen as "secure access to mainframe services" which means (a) don't do anything to compromise or work around existing mainframe security, and (b) exploit advanced capabilities like MFA and SSO and certificates and token-based security, etc. to enable the best end-user experience when securely accessing mainframe services.

I would say something like "Zowe is respectful of preserving mainframe security and embraces the use of advanced authentication and authorization features when interacting with mainframe services." Thoughts?

[pdubz3]

Also, on the topic of "Zowe services have two deployment options :" in general, I'm not sure I understand why we want a requirement for specifically two deployment options, unless you're just saying "container" and "not container". In that case, I think it's sufficient to state the vision as "Zowe remains easy to deploy and configure and offers an option for containerization." ???

[PeterFandelAtRocket]

Mike I think you nailed it with "Zowe is respectful of preserving mainframe security and embraces the use of advanced authentication and authorization features when interacting with mainframe services."

[PeterFandelAtRocket]

"Zowe remains easy to deploy and configure and offers an option for containerization." could be read to mean it is generally accepted to be easy to deploy and config today. This is far from universally accepted. More work needs to be done. If we are going to be less specific on options (to which I am amenable) I would go with "Zowe supports the deployment options demanded by the user and exploiter communities as well as being generally accepted as providing an excellent up-and-running experience for the installer. "

[pdubz3]

Yeah, "remains" was the wrong word. Maybe should have said "strives". But your rewrite may be even better because it eliminates the specific reference to containers and emphasizes that the users and exploiters should determine how Zowe is delivered. I like that even better. Somehow I think the statement can still be simplified. Need to think it through a little ...

I'm back ... how about this?

"Zowe strives to deliver an excellent onboarding experience and to offer the deployment options expected and demanded by the user and exploiter communities."

Many words or expressions could be used instead of "onboarding" in that sentence, like "getting started", "out of the box", or "up and running" as you had suggested. I'd support any of those.

[pdubz3]

General thoughts on this list - and probably something we should discuss on a working call rather than here ...

I'm OK with the ideas in the list. But I think this feels more like a set of rules rather than a vision. Aside from the first bullet, I feel like it's heavy on the "how" and light on the "who" and the "what". In fact if you remove the first bullet, it doesn't really say anything about what Zowe is or should be at all. (BTW I do love the first bullet!) I just don't think we've collectively done a great job of answering the question "What do we want Zowe to be in 2-3 years?"

I think a vision statement should read more like this:

Zowe is the preferred "defacto" standard for interacting with z/OS services, processes and data. Its ease of deployment and modern interfaces attract new talent to the mainframe platform by creating an experience which is similar to interacting with cloud platforms. Vendor offerings can easily leverage Zowe to create an ecosystem filled with consistent solutions that interact more securely and seamlessly. Zowe protects the future of the mainframe platform by enabling and simplifying modernization and automation of mainframe workloads securely to ensure that they remain on the platform.

This is just an example, I'm not suggesting that this completely covers the vision for Zowe and I'm sure it can use some wordsmithing. But beyond a clear vision statement, I think many of the items that appear in the bulleted list might belong under Principles or "Core Values" more so than under Vision.

Like I said, we should probably discuss this on a working call.

[armstro]

OK - let me try to merge the comments and yes we probably need a working session to has this out. Not sure if some (most) of these are "principles" vs 3 year vision? Should we be talking in "hill speak" (per request from Jakub with who, what, criteria and "wow" in SAFe)?

By 2024 (3 years) - assume Zowe V2 is in maintenance and V3 LTS have been released:

1) Zowe is the preferred "defacto" standard for interacting with z/OS services. BA: I am not sure we want to claim "processes and data"? We can discuss.

2) Its ease of deployment and modern interfaces attract new talent to the mainframe platform by creating an experience which is similar to interacting with cloud platforms. By attracting new talent Zowe assists to both maintain existing z/OS workloads and grow new workloads.

3) Vendor offerings can easily leverage Zowe to create an ecosystem filled with consistent and compatible solutions that interact securely and seamlessly.

4) Zowe supports the deployment options demanded by the user and exploiter communities as well as being generally accepted as providing an excellent up-and-running experience for the installer. Zowe technology is flexible in its deployment options meaning the services can run natively on z/OS (for those environments that only have or want z/OS) or run Zowe on platforms in combination with z/OS such as Cloud or Distributed servers.

5) Zowe has an "app store" model with a variety of open/free apps, plug-ins and extensions for selective download with easy install/configure (and removal). Zowe to be a suite of services that consumers can pick and choose to deploy

6) Zowe is committed to preserving mainframe security and embraces the use of advanced authentication and authorization features when interacting with mainframe services. Zowe will integrate with and leverage the latest security capabilities of z/OS for the benefit of all Zowe consumers and software extensions they implement.
BA: Being "respectful" didn't seem strong enough. I beefed up the words here (well tried)

• Zowe protects the future of the mainframe platform by enabling and simplifying modernization and automation of mainframe workloads securely to ensure that they remain on the platform. BA: I propose removing this as I tried to merge this into item 2 above

[armstro]

Note - there is some overlap with https://github.com/zowe/community/issues/1969 - propose to keep this issue active for now and decide how to integrate the two

[armstro]

Closing since contents moved to other issue https://github.com/zowe/community/issues/1969