December 08, 2015
One of the best things about the world of blogging is that the readers of a blog have a chance to comment on the subject. In the past year, several posts have generated significant comments, and even discussions between commenters. This was the case for my previous post
, where I discussed part of my approach to IBM i strategy—the need to focus on more than one aspect of the user base with our strategic decisions. Several readers took time to write thoughtful responses. I read each of them, several times. I truly appreciate the effort and time it took to write those comments. And after reading them, I decided a follow-up to my previous post would help continue the discussion.
I will try to accurately represent the overall points being made in the comments, but in the end, all the comment authors deserve to have their ideas read in their own words, so I do suggest you go read the comments section
So let’s get started.
The comments submitted so far fall into four categories (or maybe three, or maybe two—I’ll get to that):
1) Programming languages and tools—and for purposes of talking about this category in shorthand, I will call this “Developers.”
2) Competing in the cloud computing market—I’ll call this “Cloud.”
3) Automation—Go ahead, guess what I’ll call this.
4) Windows-based UI—I will call this “UI.”
In the Developers category, the theme is this—if we make it easy for developers to develop on IBM i, then IBM i succeeds.
In the Cloud category, the theme is this—the future for solutions is in the cloud, so if we make IBM i the preferred cloud platform, then IBM i succeeds.
Strategy should definitely address what we need to do in order to succeed, and those two categories provide opinions on how the IBM i strategy should be built in order to bring IBM i success.
In the Automation category (with respect to Aaron, who made the comment), I am going to suggest that this fits in as either an overlap with the Developers category or the Cloud category or both. His comment compares the ability to do automation on IBM i with other platforms, and the idea is that IBM i needs to improve to be more competitive. I don’t think Aaron would suggest that focusing solely on Automation would necessarily cause IBM i to succeed, but if we don’t focus on it, we will lose ground.
That raises an important point. Some part of our strategy has to consider what other systems are doing, and decide where IBM i can afford to be different. It’s important to recognize that IBM i will be different in some areas—differences are where both your disadvantages and your advantages lie. So the question is, will this difference be a hindrance to success?
And that’s also a consideration when talking about the UI category. IBM i has enabled various kinds of UI, not only in the integrated function available from IBM i and its programming languages, but also through partner technology offerings. If you want your IBM i applications to have their UIs on Windows, you can do that; if you want your IBM i applications to have their UIs on a browser or a mobile device, you can make that happen. But we all recognize there is no single, native way to get a modern graphical UI out of absolutely every IBM i interface. This is a way in which IBM i is different. The first question, and the question which ties back to the final comment I made in the summary of the first three categories is this: if we allow this difference to continue, does it keep IBM i from succeeding?
The second question (which we’ve not really dealt with at all in the discussion, but it affects all strategies) is what would it cost to remove the difference? I’m not going to specifically address the cost question here, but realize that cost/benefit analysis is a key part of any strategy. And though there’s more that could be said about this category, let me start trying to tie a couple of categories together.
IBM i is a platform that has based its success on business applications. So, when talking about which UIs are important to IBM i, we’ve focused on making it possible for applications to have the UIs they need. The comment Pradeep made questions whether we’ll provide a way to “convert the Display files to Windows-based application[s.]”
So, let’s consider this question given the comments we had about Cloud. We have people telling us that a good place for IBM i to succeed is in cloud-based applications. Would a “Windows-based” UI be the best choice if the Cloud is going to be the business application space in the future? Microsoft would probably be in favor of that – they’d “win” if all the cloud applications were just Windows applications served up from the cloud. But is that really the answer?
To think of it another way, even outside cloud applications, is this: Should IBM i invest in this sort of “conversion to Windows” because there is currently so much Windows being used by clients even though the growth in servers (particularly Cloud servers) is not centered on Windows? If you were making a decision today, seeing the growth of cloud applications, would conversion to a Windows UI be the answer? Strategically?
In fact, would focusing on a “native UI” be important at all? Some commenters here on my blog have been telling me for years that the big thing we need to do for IBM i is to create a native graphical UI. Their argument has essentially been that this difference between IBM i and our competition keeps IBM i from succeeding. I get this comment outside the blog too, by the way. People with this belief have often predicted dire consequences if we don’t get IBM i its own native GUI.
And yet those dire consequences have not occurred. Why? Well, part of the answer is in the overlap between the Cloud topic and the Developers topic. Because, in a very real sense, they are just two aspects of the same generic topic—Applications. You need Developers to get Applications, and you need to be a platform on which businesses want to run those Applications, so if the Cloud is going to be a home for Applications, then maybe IBM i needs to be there, with Developers who can make Cloud IBM i Applications.
This is far closer to the kind of strategy we have been implementing with IBM i. It’s not quite looking the way some of the Cloud commenters envision it, but the truth is that many of our Business Application ISVs are succeeding in drawing new business by offering cloud versions of their applications. This, in turn, means more businesses dependent on IBM i.
I refer you back to a blog I wrote in February of 2010 (almost six years ago, if anyone’s counting): “ASP, SaaS and i.”
Though I did not specifically use the term “Cloud” in the blog, my commenter did. (Hi, again, Aaron.) I’ve returned to that theme several times, whether talking about a marketing video we made for IBM i
, or customer modernization stories
, or just in my IBM i Trends presentations.
If you’re talking about Cloud being a strategic emphasis for IBM i, you’re on the same line of thinking we are.
So what languages are used for Cloud applications, and what Developers are writing them? Well, there are many answers, and it’s important to understand that we don’t have to capture all of them. But we’ve been working on capturing more and more of them. The new languages we’re bringing to IBM i can be used, and are being used, to successfully implement applications that reside in servers owned by our clients. But many of these same new languages are being used for Cloud programming. And because so many of our traditional business applications are written in RPG, helping people modernize those applications—including enabling them for Cloud—has been a focus, as has been the effort to make RPG easier for non-RPG programmers to learn and use.
Since I’m writing this during the breaks in our meetings with the COMMON America’s Advisory Council, I had better get back to them, so let me close with a couple more comments and then I’ll let you all absorb what I’ve written and give me your opinions.
First, while I appreciate everything that’s been said, I want to point out that the strategies that have come up in comments only deal with some aspects of our strategy—primarily those aspects related to some aspects of applications—and what that means is that some topics which need to be addressed in the IBM i strategy have not been mentioned. For example:
- Storage options
- Security & Compliance
- And more …
That’s typical. When we work on IBM i strategy, there are critical aspects to the future of IBM i that don’t normally come up when my readers make comments.
Second, and my last comment for today, is about the scope of our strategy.
When we think about IBM i strategy we have to think very long term. I am about to celebrate 31 years with IBM and I’ve been with this platform since before AS/400 was born. In the work I do with the IBM i team, we are trying to prepare this platform to be successful for that long again. We can’t put detailed plans in place for that much time, but we can try to set a strategy that prepares IBM i for a long future.
Could we do better? I’m sure we could. We periodically evaluate the process we use to build the IBM i strategy and plan, looking for ways to improve. But we also know that we’re making progress towards strategic goals. And it’s never “done.” Good strategy shouldn’t have to change much, but those of us who work on it do have to keep our eyes on technology and our ears to the market. So, keep talking. We’re listening.
Posted December 08, 2015 | Permalink