Agile Digital Transformation

Agile Digital Transformation

Subscribe to Agile Digital Transformation: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Agile Digital Transformation: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Agile Digital Transformation Authors: Pat Romanski, Elizabeth White, Liz McMillan, Nate Vickery, Kevin Benedict

Related Topics: Agile Digital Transformation

Blog Feed Post

Three Perspectives on Mainstreaming the Mainframe

As the next generation of professionals advance, they work alongside the mainframe experts who have been keeping host-based systems running since the 1970s or earlier. As a result, perspectives on mainframes must necessarily evolve as well.

This evolution of mainframe thinking, of course, does not happen in a vacuum. The enterprises that depend on such technology also struggle with digital transformation initiatives, while change comes to their application development shops in the form of Agile approaches and more recently, the cultural and organizational shift to DevOps.

Lost in this shuffle, perhaps, are the changing perspectives of categories of professionals, as new technologies, new priorities, and new generations of people come to dominate the IT organization.

From the perspective of management, understanding these dynamic perspectives is essential for identifying and hiring candidates, motivating the new generation of mainframe professional, and advancing the appdev organization and the IT shop overall as business priorities drive disruption and change across the organization.

Three Core Roles and their Perspectives on the Mainframe

In this article I’ll consider the roles of the software developer, the software engineer, and the architect. To be sure, many individuals would consider themselves as occupying more than one of these roles, and each of them – the architect in particular – actually consists of multiple, related roles.

When it comes to shifting mainframe perceptions, however, these three roles define important contexts for the overall discussion of mainstreaming the mainframe.

The Software Developer

Modern professionals may never need to work with traditional Mainframe UIs.

Modern professionals may never need to work with traditional Mainframe UIs.

The developer lives to write code. While each coder has their own preference for language, as they get more senior, they tend to have skills in more than one language, coding in the one that is most appropriate for the task at hand. The choice of, say, Java vs. COBOL, therefore, is really one of the best tool for the job.

More important to the developer than the choice of language is the ability to work with modern tools that behave in modern ways. In the mainframe world, little things like archaic file name formats can slow down a coder – and the last thing they want is for a trivial issue like file names to slow them down.

Once such niggling headaches are resolved, the developer maintains a high level of productivity coding on mainframe applications by sticking with their tools of choice – text editors such as Sublime and advanced IDEs such as Eclipse, Visual Studio, and IntelliJ. There’s no reason to use a green screen unless a particular developer prefers such an interface.

The Software Engineer

While engineers are generally coders themselves and thus share perspectives with developers, they also focus on the full application lifecycle – ensuring it follows established practices while achieving the goals of the business.

Modern software engineers, therefore, are focused on the details of DevOps, from the tools in the toolchain to the API-based integrations connecting them to the manifests and recipes that constitute the DevOps representation of each phase of the lifecycle.

For the engineer, integrating mainframe as a full-fledged participant in this lifecycle represents a significant step of achieving the DevOps way across a hybrid-IT architecture. Every tool on the lifecycle, from source code management to build management to testing to deployment, should work together, regardless of whether it be on the mainframe, in an on-premises distributed environment, or in the cloud.

Furthermore, how each of these tools works should be consistent across environments and operating systems. For example, creating a package should work the same way on a mainframe or in a Java or .Net environment.

Connecting such tools should also be seamless. RESTful APIs are now the established standard, and engineers expect mainframe tools to support them just as any other tool would.

The Architect

True, there are many types of architects, and the perspectives of software architects, solution architects, data architects, systems architects, and enterprise architects will necessarily vary.

That being said, there are certain ways of thinking that all good architects share. Just as developers approach their choice of programming language as the right tool for the job, the architect takes this attitude to a broader level.

In particular, the choice of mainframe vs. some alternative is essentially an architectural decision, as is the choice of modernization approach generally. Whether to retire a legacy asset, modernize in place, or integrate old with new is a decision the architect is best suited, either to make or support.

Today, IT is inherently distributed, and the mainframe must play on this ball field. The choice is no longer host-based vs. distributed, but rather whether a mainframe is the right server for given applications or workloads.

In their role as advisors of IT management, architects must be able to separate reality from hype. The unfortunate truth is that anti-mainframe hype has been leading IT executives to poor decisions for many years, to the detriment of their organizations and in the final analysis, to their customers.

The architect is in the best position to counteract this hype with factual information about the role the mainframe can and should play in modern IT environments. This person must be fully versed on the platform’s strengths as well as its weaknesses, in order to make or support decisions in the best interest of the organization and its customers.

The Intellyx Take

If you’re in an IT management role, you may be in a position of hiring developers, engineers, or architects – and if you have a mainframe, your hiring and retention challenges have just tripled.

Don’t approach mainframe hiring as a separate exercise. Instead, think about the perspectives and attitudes each role you are looking to fill must have in order to help your organization move forward with mainstreaming the mainframe.

Regardless of the specifics of your modernization strategy, you want people who can leave behind dogmatic or adversarial points of view. Instead, hire for open-mindedness, empathy, and people who see technology choices as a question of the right tool for the job.

Join Jason Bloomberg February 13th at 11:00am EST for an informative discussion on tactical approaches that help facilitate the cultural change required to unlock the full potential of mainframe as a driver of digital transformation.

Copyright © Intellyx LLC. CA Technologies and Microsoft are Intellyx clients. At the time of writing, none of the other organizations mentioned in this article are Intellyx clients. Intellyx retains full editorial control over the content of this paper. Image credit: CA Technologies.

Read the original blog entry...

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).