As you may know, TEC performs all types of system selection projects with clients in which analysts are usually involved to a lesser or greater degree. In collaboration with a client, analysts usually prepare the “to be”—the future system business and technical requirements document, or request for information (RFI)—and make corrections or additions to the template based on the client’s current needs. Often analysts are astonished about the kind of future requirements that users demand—especially the users of early Application System 400 (AS/400). I clearly understand that with that statement, I am at risk of inciting anger in AS/400 system proponents; nevertheless, I cannot keep silent and as such need to share what I have discovered during these projects.

It is quite a difficult task to understand the nature of a user’s future system requirements. Their requirements often look unusual—until you know what type of system they’re currently using.

Here are some examples of user worries.

•    Concern about the availability of multiple internal  interfaces . In my understanding, the interfaces for  GL and accounts receivable (A/R), GL and fixed assets, and GL and invoicing (for example) are the core of any enterprise resource planning (ERP) system and must be there by default. Moreover, submodules of the same functional module cannot be interfaced to each other, simply because they are inherent parts of a whole. There are no such problems in any modern ERP software packages.

•    Odd report formatting concerns bring you to the era of early mainframe  environments—in which black spreadsheets are needed to set up the initial spreadsheet layout (field length, number of fields, etc.). How can this be compared with such highly powerful and flexible analytical tools   as business intelligence (BI) applications? Is there a need to specifically require cell font formatting or rows sorting capabilities? I don’t think so. It is there by default.

•    Having a user’s query as the only way to obtain current information instead of seeing it on the screen, is a big weakness of AS400 software. Still many of the AS/400 programs show users very little  except menu screens, lists of running jobs, and a few information fields. Thus users are still concerning about running queries instead of using visual and user-friendly reporting and data mining tools.

•    Green and black screens are the most visible attributes of AS/400. It  is quite obvious that there is nothing to discuss here; however, it is fair to say that too many different bright colors, too much animation, and a wide variety of fonts and styles available in some modern software applications quickly become a substantive irritating factor.

•    There are multiple user concerns about programming and coding, as AS/400 systems require the user to remember and type program codes and be a “light” programmer. I don’t think it is abnormal when an accountant wants to have, say, pseudo-coding capabilities in a new financial system.

•    Another worry seems to be obsolete; running multiple “engines” is no longer required. Lots of errors and other problems were related to the simple fact that one or another software engine is not running for some reason.

•    The ability to see a document or the results of a report on the screen before printing is still considered a problem in the AS/400 world. This type of functionality is now available to every PC user, and raising this question in terms of new enterprise software requirements is quite strange.

So, you can imagine how saturated with manifold IT-related issues the typical day of an AS/400 system user can be and what level of  software problems that user is fated to resolve or avoid on a daily basis.

No doubt, AS/400 systems provided outstanding input into the world of ERP during their time—and nobody is arguing against that.. Hopefully the most recent releases and versions of the system are much more user-friendly and do not need accountants, buyers, and other regular users to possess the level of technical and programming skills needed to simply navigate and perform basic work functions.

The reason many companies are still using AS/400-based ERP systems is rather simple. At the time they entered the market in the 1970s and ’80s, the first generations of material requirements planning (MRP) and ERP systems were very expensive, and required an extensive infrastructure; thus, they were affordable mainly for large manufacturing, retail enterprises, and banks.

Nowadays, those AS/400 customers have become very complicated businesses with dozens or even hundreds of remotely located subdivisions, plants, or branches. Let’s say an average manufacturing company has 60 plants and distribution centers worldwide, and is going to launch an ERP implementation project in order to replace its existing application. Because of its complexity and size, this level of business requires only tier-one ERP software, for which implementation time in the best-case scenario (using standard implementation methods and standard techniques) cannot be performed in less than six months per plant. Assuming that the company is able to replace the system at six remote sites a year simultaneously, it would take a total of 10 years. New software can become obsolete within that time, and the cost of this implementation would be significant—even for a company of such size.

As a conclusion, I should note that there are absolutely no reasons to be so detailed about remembering all the problems of obsolete applications and in transforming them into new system requirements. Similarly to the medical term “phantom pain” referring to when a patient experiences pain in amputated limb, users of old AS/400 systems still struggle with issues that have been solved years ago. The IT world is very different now. Existing AS/400 users will be surprised at how significantly ERP systems have changed and how far they have progressed since the days of green-black screens.

Share This

Comments

gary on 13 October, 2009 at 4:50 pm #

o


Jorgen Andersen on 14 October, 2009 at 2:33 am #

This is a very strange article. I am not a fan (defender) of proprietary systems but how can you ignore that the AS400 often is used as a cost efficient and stable workhorse in an ERP environment together with a lot of other non AS400 servers ? In such environments the “tier 1″ architecture is old history.


Alan Townsend on 14 October, 2009 at 4:29 am #

The only ERP software that I know is hooked onto the AS400 is JDEdwards World. There are still thousands of users on it and the green screens can be changed with the latest GUI upgrades. Funnily enough many users prefer the old green screens for data capture, its much faster than any mouse driven data capture. But if you like pretty pictures over functionality and fit for purpose go for it…


Konrad on 14 October, 2009 at 7:39 am #

After a long term evaluation process for an ERP to replace our AS/400 package I can absolutely say all ERP packages are dinosaurs locked in time. Windows standards have changed over time and most ERPs have the interface that was popular at the time. Task or wizard based interfaces are few and far between.
Most of the comments relating to the AS/400 above are silly and reflect a lack of knowledge, the equivalent of a user wondering where the “any” key is. Multiple engines? V6 or V8? Not be able to print preview? Really? Very strange!


Valere Pelletier on 14 October, 2009 at 7:44 am #

We run JDE World for years on AS/400 and this is the most stable and cost effective environment we ever used.
We run 2 AS/400 for all our worlwide operations and need only one technician to support. Compare to usual servers and you will see.
Green screen is not an issue for some users and the new gui version does the job for new employees…if necessary


Roelf on 14 October, 2009 at 7:59 am #

I also found this to be a strange article. To state that the functionality and flexibility of the ERP is limited by the OS and hardware of the AS/400 (iSeries, Seriesi) is not what we experience. Our ERP has seemless realtime interfaces between all modules (GL, WMS, MRP, manufacturing, data collection, Payroll, TA, AR, AP, CRM, logistics, web site, ebusiness etc.) without interruption 24 hours per day, 7 days per week in a multi company multi location environment. Only planned time the system is not available is for less than 30 minutes new years day early AM for an annual reboot. Any report can be reviewed before printing with standard user options like Operations Navigator, or as PDF or as .XLS. End user queries are created by tools like webquery, Crystal reports, MS Office, Open Office or the ERP’s internal report writer. Choice depends on user preferences, access allowed and level of experience user might have. This is not a limitation of the AS/400 but rather of training and keeping up-to-date on the ERP releases. As for green screens vs GUI interfaces, when given the choice, new users normally start out with the GUI (it looks cool), and then revert over time to the green screens for speed of data entry. All are given both options and most use some kind of combination of the two (viewing dashboards vs data entry for example). As for an accountant doing “pseudo coding” this is not allowed in our environment due to SOX rules. If they can not accomplish their task using the standard financial statement report writers with output to either .pdf or .xls for further analysis, they need to work with IT or the ERP vendor to resolve the issue. All this is accomplished by an IT staff of 2 individuals and one IT manager. That is why our company likes the AS/400!


Dave Bauer on 14 October, 2009 at 9:14 am #

How could this article even get get posted, it obvious that TEC did no research on this matter whatsoever…The AS/400 or IBM i has the ability to all over the above issues and more. the user interfaces can be whatever you want them to be including Java, VB. Reports of course can be viewed in many formats prior to printing, including PDF, xls, doc.

As far as ERP systems go, I would never use a application on a pc of hardware originally created for the home user and really hasnt as far as technology goes hasnt evolved nearly as far as the IBM i…if you want to run a business then use a business computer not a personal computer with a so called server OS on it


Kramer on 14 October, 2009 at 9:38 am #

We’ll get on to a 20 or 40 year old elevator without a second thought, or a 20 or 40 year old air plane. But when it comes to information technology there is this myth that old is no longer viable.

Data is data. All a computer knows, all it’s ever known is how to add an compare bits. Newer means it just can do it faster or more chunks at a time. The software on top of the system, may not always leverage this, but that is why it is called software, it can be changed.

I watched companies throw out robust and reliable VAX/VMS systems and replace them for newer, less reliable, hardware. Why? because VMS locked them into green screens? No. But the perception was that the web front ends and graphical user interfaces are only possible through new technology.

I had a friend who wrote Tetris on a green screen. I wrote mine sweeper for the green screen.

One does not have to throw out their “vintage” hardware to support modern processes. It’s a tool, it’s all how you use it.

Besides that, how is it that the new user interfaces are better? I am all for new technology and advancement of technology, it’s what I make my living on. But I have watched procurement specialists toggle between as many as 20 screens in some systems to get the information they needed to make one informed decision. In talking to them, they speak of the vintage system, “It was all green, but at least everything I needed was in one spot. Now I have dual monitors to get more stuff to display at once and I still have to go to this screen, then that one, and so on before I have what I need before I make a judgement call.”

Great advancement. Although good for people like me who take the poorly implemented user interfaces and consolidate them to ONE screen again in a web-based format so they also get the pretty colors and lose the concept of it being vintage through behind the scenes the machines are about as old as they are and often older.


Jeff Olen on 14 October, 2009 at 9:53 am #

It’s interesting to note that the author of this article doesn’t mention which ERP packages he is referring to. I suspect that the issues that are mentioned in the article came not from the latest versions of JDEdwards, Xperia or MAPICS. The evaluations are most likely based on the experiences with in-house ERP systems that have been developed over the 20 year period that the writer refers to. Or possibly old unsupported versions of the name brand products that the in-house developers have take over developing and supporting.

I see this sort of thing on a fairly frequent basis. The staff and management of a company is convinced that they are “limited” or “constrained” by the abilities of the IBM i (the name of the new generation of AS400s). Nothing could be further from the truth. The sad truth is that these companies are limited by the skill set (or lack thereof) of their IT staff. Many of these developers have been working on the AS400 (and its predecessors) for the better part of 25 years. During that time they may have kept up with some of the enhancements to RPG, the primary development language on an AS400. I emphasize MAY have kept up with SOME of the enhancements. The vast majority of these developers have not kept up with the changing times. They don’t know SQL, Java, PHP, MySQL or .NET (all of which run native on the IBM i). The don’t know how to develop a GUI interface or a “preview” for a report. Now the system itself is paying the price for their lack of knowledge.

The truly sad part about this is that the IBM i is perhaps the most reliable and scalable system on the market today (just as it was 20 years ago). You say you want an “open system”? Again the IBM i is an open system.

Next time check your sources before you print this sort of skewed view of a product.


Kallol Nandi on 14 October, 2009 at 11:21 am #

I fully agree with Jeff Olen. There are two problems: 1) New generation technologists normally do not get a scope to try out this platform - so to them it remains as unseen, old technology, etc. When they become technological decision makers in addition to above factors fear of unknown comes to play and generally they try not to get in System i world. 2) Exiting System i technical user communities at large lag by about 8 years. It is sad but true. Primary reasons are “do not touch when your application has no issues” corporate policy, and not much new applications are coming up using the latest technology available System i.

Just as a practical example: We have developed a best-of-breed WMS Application using latest technology and methodology on System i. It has all features and functionalities mentioned in this chain of reply to the article and it is seamlessly integrated to any system and application regardless of platform, database, technology.

This platform is unparallel for its simplicity, robustness, scalability, durability, and interoperability.


Aleksey Osintsev on 14 October, 2009 at 2:29 pm #

First of all, I appreciate all of your comments.
To address some of your points, here are my comments:

1. Everything I have posted is based strictly on my own experience and many conversations with existing AS/400 users. I have not invented anything specifically for this post.

2. Jeff is right - AS/400-based ERP applications that I was referring to were internally developed quite awhile ago. Those packages went through multiple upgrades but the core logic and interfaces weren’t heavily modified. And the truth is that those 20-30 years old systems are still running without significant changes—and thousands of users are still struggling with the interface, reporting, and other odd issues. I saw this same scenario at the company I used to work for years ago and originally I decided that this was an exception to the rule. Years later, after becoming more familiar with different businesses in different areas, I was surprised at how many companies use the first generation software with no intensions of replacing it; so now I am not sure that was the only exception.

At the same time it is fair to say that original AS/400 systems and their successors have no peers in terms of stability and robustness per cost ratio. I am not trying to argue this fact.

3. To Kallol: Would it be possible to have a look at the system that you are referring in your comment? If you don’t mind, we can schedule a briefing. Please e-mail me directly at aosintsev@technologyevaluation.com so we can set that up.
Thank you,
Aleksey


Gabriel Gheorghiu on 14 October, 2009 at 2:59 pm #

In ten years or less, most of the business software users will be part of the generation Z (people born between 1990 and 2000).

As users, but also as customers, they are more interested in flexibility than robustness.


Joseph Jackson on 14 October, 2009 at 9:03 pm #

Movex (Lawson) is traditionally run in an iSeries / AS400 / System i environment, although I believe it also runs on Windows and Unix now. The current release is Java code, but much of this has been ported from RPG, a proprietary IBM language that was most popular on the AS/400 (and before that, System 38).

I have not been an iSeries user for about 5 years, but at that stage the iSeries held the top benchmarks for java performance and also the highest number of concurrent Lotus Notes users. Also, the structure of the system lowers the administration cost of the box (ie: less techs to keep it going). I have never worked at a site where there was an iSeries DBA - in start contrast to EVERY other platform I have worked on.

It definitely isn’t mainstream, but the platform is far from dead. With regards to the ERP offerings, while they aren’t as deep as other platforms, what is there is complete and current and can cut it with the best of ‘em.


Dan on 15 October, 2009 at 5:12 am #

Quick input: I became IT Director 2 years ago at a company that fit this description (old, custom implementation on an AS/400). The issue was not the AS/400, but the IT Director who clung to the old ways. In less than 6 months we had built new applications on the AS/400, in modern languages using SQL. We were able to elegantly keep the parts of the old system that worked (base accounting), and yet build modern applications on the same platform. Invoices, statements and POs now go out as emails with PDF attachments (or as faxes), 12 branches, each with their own local AS/400s support the AS/400’s beautiful implementation of Remote SQL.

We developed all new Purchasing, receiving, payables, inventory, etc… using a new look for green screens that supports the mouse for vertical scroll bars and buttons, and the input is always “Google” like (enter the vendor’s phone# if that’s all you can think of, and we’ll show you their activities).

Deployment could not be easier. Each branch can ease into the new system on their own pace, taking on one module at a time. This is key for a small company with scarce resources for training.

Technical details: Many of the new applications were built as Stored Procedures, “(business logic APIs if you will) and serve our e-commerce web-site (and will soon serve other applications). We did all of it with 1.6 humans, and a part time outside developer.

Our biggest competitor has 7 full time IT people.

‘Nuff said.


Ed Jones on 15 October, 2009 at 5:23 am #

The key issue is that risk aversion has caused stagnation in many situations. The iSeries / IBM i platform is as robust and scalable as anything on the market however the perception is that it is vintage. This means that the problem is typically in the software not the OS or hardware.

The fact that a 10+ year old green on black system will run a multi billion dollar organisation isn’t the issue, however because it isn’t presented as web or windows, or doesn’t support a more modern workflow, it is seen as legacy.

Organisations often operate on older applications with minimal overheads and little pain but this often means that the people responsible for the system don’t like to change it. Change introduces risk and as we all get older we become more risk averse. The net result is that tension builds up within an organisation so that instead of working with the IT folk on an evolutionary path an exec team will take a view that the only way forward is to rip and replace core systems.

It’s a simple math problem. If an application is providing an 70% solution (i.e. it’s running the business today but could be better) any new system will typically still only deliver at 80% because you must customize and extend it to suit your particular organisation. The net result is millions of dollars + long elapsed time + significant risk to the business to implement a new system. Compare this to a 1/10 of the spend with a shorter delivery timeline with much lower risk to get your existing system to 100% and you wonder why we’re still talking about this topic.

Particularly given todays economic climate, I’m seeing the large, never ending replacement projects, not getting exec sponsorship whereas a modernisation project will. Here’s an example of what I’ve been describing - http://www.lansa.com/casestudies/cinram.htm

A software problem compounded by risk aversion causes stagnation.


Martin Fincham on 15 October, 2009 at 6:12 am #

Aleksey, I suspect that you already realise that inadvertently lumping all AS/400 (now the IBM i) ERP apps into the same bucket does you and your paying clients a disservice. To your credit, you seem willing to look further into this topic and so I encourage to cast an eye over our native IBM i ERP package: http://www.lansa.com/services/erpframeworks.htm

Needless to say, it does not suffer from any of the limitations articulated in your original post - all modules are integrated, have a GUI, web extensions etc. We also bring the solution to market with a ‘post-modern’ business model; open source software. Yep, we ship the source code and don’t charge maintenance fees. Many users of legacy (read stable) ERP apps have recoiled against ever-growing maintenance fees levelled by vendors and thus develop somewhat of a love-hate relationship. In our model we can provide the tools and teach the skills, or deliver a complete solution via our services team, or some hybrid in-between. I can introduce you to our ERP Practice Leader if you want to follow-up.


Thedi Grau on 15 October, 2009 at 8:09 am #

Great article and right on the money. There is nothing wrong with the AS/400 it is probably still the greatest piece of HW ever made. The problem is IBM. They missed the boat or should I say shuttle since things happen so fast in this industry for two reasons. 1) IBM neglected to recruit ISV’s to port their applications to this platform. 2) Within IBM’s development the AS/400 is always the last platform to adopt new technology, be it the Data Products, Websphere, Tivoli or other products. You can preach as long as you want if you don’t have followers (ISV’s) and treat your own child as a stranger, how can one expect other people liking this baby. Customers are left with two options; buy a new ERP system on a competitive platform or what we see increasingly more is to put a portal in front of the AS/400. At the end of the day it is about competitive advantage and Total Cost of ownership. AS/400 has lost that battle and companies using this platform are falling behind.


Chris Hird on 15 October, 2009 at 9:21 am #

Thedi, sorry but this is not a great article. Aleksey has adjusted his stance a little by restating that this is his experience which is not necessarily that of others but he is still mis-informed about the IBM ‘i’ and its capabilities.

The IBM ‘i’ has grown with technology as it becomes available, unfortunately many of the developers and ISV’s have not. The IBM ‘i’ is not always the first to get the latest and greatest technology, we know that, but when it does it is pretty sound and stable!

We have often questioned our future strategy with the IBM ‘i’, mainly because of the general noise we see around the industry about the platforms future. We will however continue to support the platform in any way we can and will not stand by and watch the demise of a great platform.

If this kind of story is pushed out with no response from people who know better then the customers will start to believe that noise about the IBM ‘i’, this will eventually result in them gaining the same unfounded opinions Aleksey has.

IBM has no need to stand behind the paltform, they are only interested in making more money. If a customer is looking to move away from the IBM ‘i’, IBM is more than willing to help them. I have been informed by some very large IBM ‘i’ users that IBM is actively trying to get them to move to AIX and ditch the IBM ‘i’, why because its more profitable to sell them new software and services than it is to continue to take the maintenance the IBM ‘i’ provides them today.

Aleksey, I hope you find the time to look at some of the software others have mentioned above, perhaps then you will write an article about the real IBM ‘i’.


Aleksey Osintsev on 15 October, 2009 at 9:36 am #

To Martin Fincham:
I appreciate your suggestion. I have visited your website and found that your ERP solution looks different from other AS400 based systems known to me. Could you please send me an e-mail to discuss it further? It could be a good opportunity for me and for the entire TEC reader community to see it from another angle.
Thanks!


Steve Fochler on 15 October, 2009 at 12:39 pm #

Nothing like a “phantom limb” post to get the IBM “i” crowd in an uproar!

I agree with most postings here since as we demonstrate our PHP applications for the IBM “i”, the typical response is, “I can’t believe our box can do that!”.

I am surprised not to hear more about the green nature of the IBM “i”. Fact is, power consumption of one box versus racks of servers is far less and more eco-friendly.

Since many companies are looking for ways to “go green”, reducing the server footprint of their datacenters by housing most if not all of their applications on the “i” will get it done!


hornetzvillespi on 28 December, 2009 at 8:42 am #

Of phantom limbs and AS/400

Ensuring that your AS/400 system and infrastructure is secure is far from a trivial undertaking. These complexities often lead to shortcuts, and all too often, to serious exposures remaining in place.

But how do you ensure that the security is appropriate and up to scratch? How do you know that there are no major exposures? How do you audit and review it methodically?


RAFAEL on 4 March, 2010 at 1:47 pm #

I got the feeling TEC is loosing its view. The posting in strange, and if it is so narrow in reach as for one people personal experience should not be share in a profesional envirinment.

May facewook be a better place


Rob on 27 April, 2010 at 10:27 am #

Although it is always nice to read an article about the AS/400(ok ok, the ‘i’) I must say that it paints quite a simplistic picture of the platform.

The AS/400 can do everything that other platforms can do while still remaining the most reliable database server around. The fact that a lot of customers do not realize this(also due to the abysmal (non-)marketing by IBM) is obvious. But as Steve Fochler said : a lot of the image of the AS/400 is based on the ignorance of managers and key ICT-technicians. The moment an AS/400 analyst has had his or her training he or she begins work and lots of managers then think that these people do not have to study the AS/400 anymore. After all: They passed their exams in 1992! There should be way more focus on training the ICT-/AS/400-staff in new technologies as they emerge on the platform.

The company that I work for atm uses several big AS/400s as core-machines, surrounded by almost every platform you can think of. The AS/400 is mainly used as a database-platform while the applications themselves move more and more to separate Intel-based servers. Of course the old green-screen stuff is still active(and used very very much) but we have opened up the machine to work together with other platforms as they are needed. You mentioned something about the lay out of reports etcetera. We use Crystal Reports, WebQuery/400 etcetera. All WYSIWYG, all very flexible, giving very slick results. Sending those reports via email etcetera? No problem whatsoever.
It really works like a dream and it costs a whole lot less than the alternatives that we have studied.

Technology ages slower and slower nowadays; the difference between an 8080 processor and a Pentium IV is a lot bigger than the difference between an 21th century AS/400 and an Intel platform. As a matter of fact: In several respects the AS/400 hardware sweeps the floor with Intel’s.

I’m just saying : By all means modernize en upgrade. But don’t throw out the baby with the bathwater.

Regards,

Rob.


Phil on 9 November, 2010 at 3:49 pm #

iSeries? Now you mention it we do have one of those. DBA? No need. It just works away. This is serious gear that does a serious job without drama. Hype is for the bunnies and fadists. I wish memory was cheaper though!! My 1c worth.


Matt on 6 September, 2011 at 9:21 am #

There are more issues with the AS400/iSeries/IBM i then people are pointing out.

The hardware is rock solid, the software is OK, but ultimately it is just a very expensive DB2 database that doesn’t even support all of the DB2 features (because they are built by different DB2 teams at IBM).

Want a Dev, Staging, QA, and production environments with AS400? Good luck with that, you are looking at a huge cost to buy several new IBM i machines, or you can create partitions (still expensive). On Windows or Linux environments we have the ability to fire up virtual machines (VMWare, Hyper-V) before an RPG programmer can finish his/her “Hello World” program.

What we are really talking about is exactly what Rob is talking about, their machines are basically database servers at this point as you rewrite all that RPG code to more modern platforms.

We actually have statistics of some of the rewrites we did from RPG and JAVA to .NET and the code reduction was unbelievable. 30% at the low end, but often more then 70% as measured by lines of code was reduced during the migration to more modern programming languages. Not only was the code more readible, it was also more maintainable as a result.

So anyone out there thinking of “modernizing”, you can keep the database, just get rid of the RPG!


John on 6 September, 2011 at 9:26 am #

One other thing to think about, people these days unit test their software. Try find a unit testing software as good as NUnit, MBUnit, or any of the vast number of open source unit testing frameworks out there for the IBM i.

They just don’t exist. If you want to build robust software using RPG, good luck. Your better of reformatting the OS and putting on Linux on that Power 6/7 machine instead of being limited by the AS400 OS and start writing in Java or better yet .NET. People who say “well you can run java on AS400″, have not looked at the performance comparisons.


AS/400 on 3 October, 2011 at 3:32 pm #

Thanks for this article - like reading your blog!

Thomas D.


Nate on 25 July, 2012 at 9:57 am #

I was looking to TEC for info on IBM business partners and iSeries/AS400 related application packages. Instead I found this piece of fiction masquerading as an article.

Having read this article I am now considering a career change to that of an author of science fiction and fantasy writings and TEC will have the privilege of first submission (but not exclusive rights of any kind).

My first story will be about the return to MRP business applications that run on the iSeries. MRP will stand for ‘Mind Reading Processing’. The business applications will run totally on thought control from the users. They can think databases, reports, displays, drilldowns, BI, and self-aware interfaces into existence simply with the power of their minds. No longer will users be confined to having to use keybards, mice, or voice entry to get things done.

Everything will be done utilizing the power of the human mind (play eerie,spacey, sci-fi music now).

The future is upon us!


*Name:
*E-mail (private):
Web site:
*Comments: