opinion: How Much Do Architects Need to Know About Mainframes?
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
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
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
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:
OK, this is a lot of information, and architects starting with a clean slate are
facing a lot of work. But no architect can expect to do this on their own. They
- How they access data - IMS or DB2 databases?
- How they connect to each other - Websphere AS transaction calling an IMS
- 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
- 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
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.