If the mainframe was an animal, which animal would it be?

I spent this week engaged in philosophical debate on the subject of mainframe application output management with a dozen hard core zSeries specialists from IBM. These chaps had spent their entire working lives in, on and around mainframe systems. Compared to these guys I felt like the new kid on the team because I had only been working in IT for twenty-ish years.

When I started work, mainframes were falling out of favor. They were big and expensive, and the trend was toward more, smaller mid-range systems. Distributed computing, if you will, over cheap, commodity hardware. When I started in systems integration we talked about building abstraction layers over legacy applications to make it easier to migrate their functions away from the mainframe. When virtualization become vogue I was struck by how the wheel had turned full circle. Now we wanted to consolidate all these smaller boxes into virtual machines on fewer, more powerful machines. Well hold on now, isn't a VM just a fancy name for an LPAR?

The more I work with mainframe systems, the more I am impressed about the thought that went into their design from the very beginning. I am also impressed with IBM's determination to keep the mainframe relevant. The mainframe, as it turns out, is an excellent platform for hosting guest O/S. I have been reading about Marist College running 600 virtual Linux systems on their z9. It seems that businesses that depend on mainframes today will continue to do so with confidence. However, I am not sure how many corporations who do not currently run a mainframe would consider installing one.

Now that the mainframe is back in favor, it became apparent that we're going to need people to support and maintain them. I am hearing stories that 20,000 graduates a year are being recruited and trained to tame the big iron. I can see the interface to and administration of mainframes changing dramatically over the next few years, because let's face it, it is a bit ugly right now. We young whiper-snappers from the distributed world know a thing or two about making user interfaces intuitive and easy to use. I also expect to see the proliferation of typically distributed development languages to the mainframe (and not just via unix system services or VMs). In the meantime, the principles of writing good code apply to all languages even if it does mean learning a bit of JCL, REXX, C & COBOL.

These days I think less in terms of distributed versus mainframe and more about blended solutions that benefit the business and end users. The mainframe is evolving from a T-Rex that'll tear your head off, into a big friendly dog that will dribble on you until you give it a hug.

James
Atlanta
October 2009

Defining Project Scope

I am confused as to why some companies insist on running huge projects that invariably run into trouble with dates, quality and budget.

Here is an example of what I mean. I have worked for several customers who initiated the "SOA Project". These were multi-year, multi-team, multi-budget, multi-million dollar projects. And all of them ran into trouble one way or another just through being too big.

The last time I worked on one of these, my company was brought into to replace another vender who had thrown in the towel. i.e. It was so bad they would rather lose the account and walk away than complete the engagement.

SOA is not a project, it is an architecture pattern. Same thing applies to EDA. These are design principles that are applied to projects.

My thinking is this. A long term strategy should not be encapsulated as one project with a dozen phases. Instead, divide projects up into two categories:

Business Value projects are those that have a clearly defined goal with a concrete return-on-investment. These projects should be accounted for using a budget from a business unit. A couple of examples: Stream-line processes to reduce the average call handle time in a call center. Enable customer self service via the web.

Infrastructure projects involve bringing new technology into the enterprise that will increase the return-on-investment of Business Value projects. These projects should be classed as capital expenditure. For example: Implement a new middle-ware product to enable application integration with a legacy system. Implement an enterprise message system.

It may be that an infrastructure project becomes a pre-requisite for a specific business value project. If this is the case, then we should be clear on the cost accounting as this will dictate whether the infrastructure project is a good investment. For example, will this infrastructure enable other business value projects? Will it enable the IT team to better serve the business?

I look at these things as a Techie. Big problems are easier to solve if they are broken up into smaller problems. Small problems can be solved quickly (and for less cost) while working in the context of a long term strategy. We should maintain an agility that will enable us to change direction, as needed, without discarding that which has already been acheived.

In my view projects should not exceed six months in durarion. Three to four months would be the optimum size. In this way the business receives regular benefit from the IT team. Business propsers, makes more money, more money funds new projects, new projects help the business to prosper.

It boils down to this: Clearly defined goals based entirely on a well understood business value proposition. Small, agile teams working to a limited scope for rapid delivery.

James
Atlanta
April 2009