PHP. You can't do the tango in a drugstore without bumping up against it. It's not the only player in town, but it's definitely one of the big boys.

And lots of people are talking about it. But you know what? It seems that most of the people who are doing the talking are the ones who are actually working with PHP.

Yeah, yeah. I know that in many ways that makes sense. I mean the one who does the work is the one who is naturally going to do the talking. But I think it's important that management be talking about it as well, especially managers who are still deciding what their web strategy will be. And I honestly don't think that most managers are doing that much talking about PHP. Or Ruby. Or any of the other languages that are contenders for handling the GUI portion of the IBM i modernization work. And if they are talking, they're doing very little in terms of education to get up to speed with how a particular web language fits into the i environment or what the utility of that web language is going to be for their particular shop as they move to a more web-oriented experience.

So why aren't more managers talking about PHP? I suppose there are a number of reasons, but as anyone who reads my articles might imagine, I have my own particular take on that.

What Does IT Management Think Of?

Now if you work in the trenches in the IT world, you can't ask for a better setup than that. I know what I would have said 20 years ago. Heck, I know what I would say now (I've never quite gotten over my Rebel Alliance days). But that's really not fair. So let's move on.

You want a very difficult job? Try being an IT manager today. Yes, it's true; they do get paid the big bucks, but there's an awful lot that goes with that territory. If you're an IT manager, you're responsible to everyone. You're unable to please anyone. And there literally are not enough hours in the day to do your job.

And what is that job?

Much of it is attending endless meetings. It would be nice to say that those meetings actually accomplish anything, but I am not nearly that Pollyanna-ish. Seriously though, the number and length of time that people spend in meetings is probably the biggest productivity impediment in business today, but that's another topic for another day.

But that not withstanding, the truth is that most of an IT manager's time is spent on hardware or infrastructure issues.

And that's kind of surprising in a way. After all, the IBM i is renowned for its integration. If there's anyone who should not be spending time on hardware and infrastructure, it should be an i IT manager.

But the reality is that, even in the i environment, Windows is really the dominant infrastructure environment. You know what I mean. No one just runs an i anymore. They run an i with a Windows partition and an AIX server or two and goodness knows what else. And they support users who are more connected to the web and to servers than they are to the i per se.

In addition, whereas with the i there's pretty much one flavor (granted with a few flavor overtones), the server environment attached to most i's is a free-for-all. Do you go Windows? Linux? AIX? Virtualization? The cloud? SkyNet?

And don't get me started on the network. VPNs. Distributed. BYOD. A smorgasbord of software apps that may appear with no warning. And don't forget viruses. Did someone mention data security outside of the i?

Bottom line, most IT managers in i shops today are almost totally focused on pleasing everyone while devoting most of their efforts on hardware and infrastructure concerns. If you think otherwise, just sit in on some of the IT meetings that are held every day. Definitely, the focus is hardware and communications while programming and system enhancements take a back seat.

And like many things in life, the squeaky wheel is the one that gets the grease, the special attention, not the one that's doing most of the work.

The i—Screwing Up in Reverse

In some ways that's been the problem for the i all along. It's too easy to work with, too hard to screw up. So we sort of ignore it. It's the i after all. No big deal.

So when we look for a road into the future, do we really look at the i? I think a lot of people don't. Even people who have been longtime i users think, "The i really filled a niche, but now its time is over." And they move on to other platforms. The most common one they move to is Windows. And you have to honestly ask: why?

If there's anything that Windows has proven over the past 20 years, it's that it's consistently not the best bet for a secure system. But it is Microsoft. And that's an icon, like IBM back in the '80s. So when push comes to shove, it's a safe alternative. Safe from a corporate point of view. It's not a new or controversial option. Windows servers, in one of those strange twists that has made Miley Cyrus a star, is probably the server of choice. Needless to say, Windows is a bit high-maintenance and absorbs a great deal of time.

What am I saying here? No matter how committed to the i someone is, there are so many pieces of software that run on Windows that it's hard to avoid. And once you invite Windows to the party, you automatically sign up to a very, very needy relationship. The initial cost is small, but the ongoing requirements are huge.

So Who Cares Anyway?

OK, so the typical IT management types spend most of their time obsessing about hardware and infrastructure issues. And the environment they're most concerned about is Windows, which sucks up a huge amount of resources. So who cares? They have to worry about something. And the more time they spend sequestered with the hardware/network guys, the less time they have to bother me.

But focusing on those two issues leaves enhancements and the future of the i sort of up in the air.

Deciding how you want to modernize is an important issue. In my mind, it's the most important issue you can deal with. Yes, infrastructure is critically important. But that doesn't mean nothing else matters. No matter what else is going on, the number one mission of any IT group is to deliver applications that do two things.

First, meet the user need. You need to accomplish what needs to be done, and you need to do so in an efficient and easy way.

Second, apps must be easy to modify in the future. Change is the new stability. What you do today will be changed tomorrow, possibly in unthinkable and vile ways. If your app can't be easily changed, you're toast.

Which Means…

Which means that, with most of an IT executive's brain being occupied with infrastructure issues, what often gets left at the curb is modernization.

That's not to say there's not a lot of talk about modernization. There is. But talk is not the same as real thinking or conscious decision-making. Talk is never the same as learning or acting. It's just talking.

I would be willing to bet that in many shops there is not one, but a number of different modernization strategies in play. Generally, companies have tried a number of options over the years and it may even be possible that different developers within the organization are using competing approaches simultaneously. Nothing is quite so picturesque as a fractured development environment.

There's probably even a bit of a difference in terms of how different people in the organization look at modernization. Is it redoing everything using a web language? Or is it putting a web look onto the code you already have?

But There's More

OK, so most IT manager types spend most of their time on infrastructure issues. Get over it already. But there's one more thing that gets in the way.

I strongly believe that everyone, from the CEO of GE to the lowliest Windows specialist, considers one thing to be the main thrust of their job. They might be multi-tasking and doing all kinds of stuff, but there is one thing, and I mean one thing, that really defines whether or not they feel successful in their job or not.

And for most IT managers, that one thing is not modernization or developing a coherent web strategy. Even if we have IT managers out there who do feel that their job depends on their understanding of the options available for web access, it's unlikely that they have the time to actually develop that awareness.

After all, most IT managers that I have met have grown up dealing more with hardware and infrastructure issues than programming. It's not even unheard of to have an IT manager who doesn't know how to code in the language that's used in his shop. Or if he/she does know how to code, it's been so long that it's not operationally important. Think I'm off base on that?

Tell me, from your own experience, how may IT manager types that you have worked with could code proficiently on at least one of the languages used in your shop? How many IT managers have you worked with who know what options are available for web access on the i? Or how many of those options run natively on the i versus via a toolkit?

I believe that most IT managers today can't answer those questions. And the question that follows from that is, does it matter?

There Should Be a Coherent Modernization Strategy

First and foremost, every i shop should have a coherent and consistent modernization strategy. And that strategy should be based on firsthand knowledge, not on where the press seems to be moving or what vendor came in to the shop last.

I know that sounds pretty unnecessary, but it's actually pretty basic and it's something that many i shops don't have.

Most have a number of different modernization strategies in place. First, someone convinced them that Java was the ticket, so a programmer went to a few classes and spent a year or so getting familiar with it, and now you have a few 15-year-old Java apps that nobody else knows how to deal with because that guy is long gone.

Then they decided to try something that was a little less technically daunting, so there's a whole library of CGIDEV2 enhancements out there. They're functioning well, but some people wonder if that's really where the technology is going and if we wouldn't be better off using a true web language.

So you look into PHP or Ruby. But that means you need to do HTML (have to do that with CGIDEV2 also), and once you're into HTML, then you get into CSS3 and JavaScript (or at least jQuery or Node.js), and people begin to back off because, man, that's a lot of tools to learn.

And I'm not even going to get into the use of embedded SQL, stored procedures, DDL vs. DDS, and other database concerns (like the push for NoSQL databases).

Once you sort of decide on a general approach (like using PHP, for example), you then have to decide if you're going to do the work with the language itself or with one of the many "build apps fast" toolsets out there.

And finally, or actually first, you need to decide what the role of web-oriented languages is going to be. Are you going to rewrite everything you have in this web-oriented language? Some people are doing that. They're not doing it cheaply, but they're doing it. Or are you just going to move to some sort of MVC-like programming paradigm and leave your business rules in RPG but do the interfaces with the web language?

Why PHP Is Important

Those are some pretty hefty decisions, and to make them you need to know more about the web languages and how they interact with the i than you can get from a standard one-hour vendor webinar for a product. It requires some real study, some real thought, and some real education.

And who should be instrumental in this process? That's right. IT management. But can they really do that, given the amount of time being spent on hardware and infrastructure? Of course, the real question here might be, after spending the past 40 years coming out with more and more advanced hardware, why does that seem to be more time-consuming now than ever? But that's another topic for another time.

So the job of setting up a comprehensive modernization strategy falls to…no one. Or maybe it's everyone. Because everyone has an opinion about it, and everyone on the team seems equally knowledgeable about it. The problem with "everyone" is that most people tend to go with what they already know, so everyone has an approach that's different from everyone else on that team. And that's where a knowledgeable manager should take charge.

This is the reason it's important that IT managers know about PHP. And I guess Ruby. And other things. They must know these products at a level of detail that makes it possible for them to not just spell them but to really understand them. That might mean reading a number (OK, a bunch) of articles. Or going to a Zend or Ruby conference. Or even digging into the code a little to understand the pluses and minuses of each approach.

Is it a lot of work? Sure. But that's what we IT people do. We learn—not just surface stuff, but real stuff. And the same person who can gleefully spout off six or seven different tape drive controller model numbers can just as easily learn real details about PHP.

Am I right? Feel free to comment if you think I'm not. What do I care? You don't know where I live.