longpelaexpertise.com.au/ezine/ArchitectzOS.php?ezinemode=printfriend

LongEx Mainframe Quarterly - November 2009

I clicked on the email attachment, and a beautiful diagram appeared on my laptop screen. Pictures of servers and routers mixed with boxes were all connected with arrows and lines. The client's application structure was clearly laid out for all to see. The diagram had only one flaw: the mainframe running their core applications was a single blank box.

Too many enterprise architects do not understand their mainframe environments. I've heard many reasons for this, reasons like:

• Mainframes are just like UNIX, so don't need any special attention or analysis.
• Mainframes are obsolete, and will soon be replaced.
• Mainframes never change. All innovation is happening on other platforms, and that's where the action is.
• It's too hard to learn about mainframes.

Let's face it: this isn't good enough.

Why Architects Need to Know About Mainframes

Mainframes run critical applications that the organisation simply cannot do without. They hold much of the 'core', or critical data, and process more transactions than most other platforms combined. Although some organisations have been planning to replace their mainframe for years (or even decades), few have succeeded. What's more, the System z mainframe has undergone a revolution in the past decade, offering new features like UNIX Systems Services and SMB, new languages like Java and C++, and new connectivity options from Websphere MQ to CICS Transaction Gateway. These new features may well present a better direction for the organisation – something an architect must be able to assess purely on merit.

Architects cannot properly contribute recommendations about whether processing should be removed from the mainframe without fully understanding that processing. And if the mainframe is to be retired, it makes sense for the architect to fully understand the soon-to-be replaced systems. He or she must be able to contribute to the effort of moving to another platform with minimal problems and disruption, and to plan the strategy to follow.

An enterprise architect with knowledge of the platform that runs a company's critical applications, processes its core transactions, and holds its most sensitive data will be far more effective – regardless of the age or future of that platform.

How Much Do Architects Really Need to Know?

There's no way an architect can have in-depth understanding of every computing platform, application system, middleware option and networking technology. So how much do they really need to know about their mainframe?

The good news is that it's far from impossible for any architect, even one with absolutely no idea about mainframes, to quickly get up to speed. Let's break this knowledge into two parts: technical and application knowledge.

1. Technical Knowledge

Architects as an absolute minimum must have a basic understanding of the System z mainframe platform. It is not like UNIX (though it does have a POSIX shell).

They must know some basic technical information - like how datasets work, what a console is, and what batch is. They must know how to log in (TSO and the POSIX shell), security options (RACF, CA-ACF2, CA-Top Secret, and cryptographic options), and how mainframe networks operate.

Add to this a basic understanding of the transaction managers (IMS, CICS, Websphere Application Server), database managers (IMS, DB2, CA-Datacom), application languages and development, and other systems software available. And don't forget middleware like Websphere MQ.

To put it another way, architects must know what mainframes do, how and why they're are different from UNIX and Windows, and what options are available to move forward with a mainframe, or move away from it.

This all can sound daunting, but there's no reason to panic - detailed knowledge isn't needed. As a quick yardstick, a few hours reading What On Earth is a Mainframe will be enough.

This basic knowledge is a good start, but not enough serious long term strategic planning. What it does provide is enough knowledge to understand the mainframe application structure, and to talk to mainframe technical experts to find out more.

2. Application Knowledge

Armed with this basic knowledge, architects must also be familiar with all mainframe applications. Yes, all of them. And simply knowing what they do and what language they're written in isn't enough. They also need to know:

• How they access data - IMS or DB2 databases?
• How they connect to each other - Websphere AS transaction calling an IMS transaction?
• How applications are developed, tested and maintained.
• If non-mainframe systems connect to applications, and if so, how. Do they use CICS Transaction Gateway, Websphere MQ, or something else?
• Transaction rates and database sizes. It's easy to concentrate on functionality, and forget about load and performance information like:
  • Average and peak transaction rates, and how they're changing over the long term.
  • Location and size of regular transaction peaks.
  • Database sizes, and how these sizes are changing over the long term.
• Business Continuity plans and backups.
• What batch processing is done. What happens every night, at week-end, and at month-end? Many architects focus on online processing and overlook batch.

Where Can Architects Get Technical Help?

So what expertise is on tap? Because of the size of mainframes, most technical staff specialise in one area – DB2 database administration, COBOL application development, CICS systems programming. Even application programmers will often work only on a small part of the overall application systems in place. So architects will be relying on several technical people, including:

• Systems Programmers - The system administrators themselves know more about the systems and applications than you think. They have tools to determine processing workloads, and even what applications are doing. Systems Programmers know more about the mainframe than anyone else, and are an excellent place to look for technical knowledge and opinion.
• DBAs – DBAs know all about their databases. They have a good knowledge of what applications access what databases, the more busy databases, how large they are, and how fast they're growing.
• Applications Developers. Most sites will have one applications 'guru' – the wizened old man that knows about the applications, and just as importantly, the history behind them.

Dealing with in-house staff isn't always easy. Many will have a biased opinion, some won't have the knowledge needed, and others will be difficult to communicate with. Some architects may not have any technical in-house staff available - particularly those with an outsourced mainframe.

In these cases, architects have to look further afield for the expertise - from an external consultant. Architects with little free time may also use this consultant to do some (or all) of the legwork. The white paper When Should You Hire a Mainframe Systems Consultant talks more about when consultants can (and can't) be of value, and how much they can cost.

One other source of information comes from hardware, software and outsourcing vendors. They are a great resource for finding out information on individual products and services. But let's face it: they have a biased opinion. You'd have to be crazy to use them as the sole source of technical information and opinion.

Conclusion

Enterprise architects with mainframe systems on their patch must have an understanding of that environment. The good news is that they don't have to know everything. A basic knowledge, and access to more technical expertise is all they need. A diagram showing a mainframe as an empty box is not good enough.

David Stephens