Change is good

I don’t know if you’ve ever seen “The Day The Earth Stood Still“, but I always thought this scene holds a universal truth…..

“Technology is not your problem. The problem is you, you lack the will to change”

So why do we need to change?

It’s my firm belief that technology, by itself, is never the solution to a problem. There is just no way a slick and sexy looking ‘appliance’ by itself will magically fix your technology problems. Sooner or later the ‘real’ issue will pop up and cause the same problem over and over again.

Take for example a company facing severe challenges to keep their ‘backup window’ within the allotted time frame. Just getting faster drives and faster networks might solve the ‘short term’ issue, but as long as they don’t ‘take a step back’ and review what it really is they’re backing up and compare that to what they really need to be backed up, this ‘gain’ might only be marginal and most likely temporary of nature.

Taking that step back to reevaluate past decisions and configuration should always be the first course of action when facing ‘problems’ (for me this holds true beyond the technology domain). Just like how the car would have never be invented if we had just kept searching for ‘better and faster horses,’ I believe we will make the biggest progress in (Enterprise) IT once we allow change across the whole playing field.

But why don’t we?

This means we should be willing to change our infrastructure, our operating systems, our applications and middleware our procedures and maybe even our job descriptions….

And for a lot of us, change is not something we like.

I’ve always done it this way” and “But that would take a lot of effort” are frequently heard excuses for not changing. Whenever these “arguments” are given I cannot help but think about these demotivational posters.

When your basement is getting too packed with ‘stuff’ you keep storing down there would your solution be to move to house with a bigger basement? Or would it maybe seem smarter (and more efficient) to reevaluate your procedures regarding what to store there?

“To improve is to change; to be perfect is to change often.” 

Looking forward to your reactions in the comments section……

 

In honor of our 1,000th hit, behold System Z’s answer to Ruby on Rails: COBOL on Cogs!

In all seriousness, the modern mainframe has come a long way towards embracing modern web technologies.  Due to the integration of UNIX into z/OS and the popularity of Linux on the z/VM hypervisor, TCP/IP has become a foundational technology of the zEcosystem.  This is demonstrated by companies such as Marriott making the zEnterpise the heart of their IT infrastructure by adopting a service oriented architecture tied to XML, web technologies, and custom APIs.  Although unimaginable during the era of the S/370 and the Systems Networking Architecture (SNA), companies are adopting APIs as a means to simplify and accelerate the integration of their mainframe and zEnterprise systems into web and mobile apps.  This has the potential to promote the use of the zEnterprise as an Infrastructure/Platform/Software as a Service solution accessible to developers through a standard API.

Even more interesting, it is possible that a private cloud on zEnterprise could follow the steps of Eucalyptus (a public cloud solution) and run an API that matched the syntax of an API stack such as Amazon Web Services (AWS) or IBM’s SmartCloud.  Such a move would allow the instant portability of ubiquitous cloud-based front ends to a private mainframe clouds, potentially following in the footsteps of industry standard technologies (such as TCP/IP, UNIX, Linux, Java) to further open up and promote the mainframe as the centralized “system of systems” of a complex heterogeneous IT environment.  In the web development world, developers have benefited for quite some time from Google and Amazon’s simple yet powerful APIs.  I can’t help but wonder how similar tools could affect the deployment and utilization of the zEnterprise environment in the future.

I challenge you, dear readers, to consider how one could build and deploy an mainframe API that would provide the strengths of flexibility, inter-connectivity, and ease of use without compromising traditional strengths in security and efficiency.  Have you worked with APIs in the past?  Do you think that there is a role for such tools on the mainframe?  What sort of impact would the use of such tools have on the mainframe?  Let’s hear your thoughts in the comments.

Here are some interesting resources related to this idea:
Info on the IBM HTTP Server
Toys and Tools for z/OS UNIX System Services
Guide for Porting POSIX complaint Apps to z/OS UNIX System Services
PHP for z/OS Guide
IBM HTTP Server Cookbook
Porting Apache to z/OS
Coding AJAX Apps on z/OS
System Z APIs
tcACCESS

Happy COBOLing!

Posted in IBM.