The historical context:

In the late 80's software was passing from the mainframe domain to the desktop PC. It was an exciting time. Those software companies who had invested huge sums in mainframe programs told their clients that PC's were "just a fad" that would pass.

This was a mistake. They failed to realize the inherent desire of engineers to be in control of their own technical solution domain. They also missed the fact that the mainframe IT organizations were back-charging their departments with horrendous usage costs for each "CPU-based time unit" that they made the mistake of using. This charging method meant that users tried to limited usage (or their boss did) to avoid interdepartmental charges, and that was exactly the opposite of what you wanted engineers doing when they were trying to resolve tough process problems.

Those software companies who saw the writing on the wall invested in the major task of rewriting their software to take advantage of both the new availability the desktop machines offered, and the desire to have it there. Then there were others. They saw the desire, and understood the market change, but didn't want to make the investment, hoping they could continue to milk the investment out of what they had already written. So they wrote "wrappers". These were interface programs- shells essentially- that allowed the user to access program basic setup within the PC environment, and then fed the information in batch form to the mainframe. In some circumstances, the complexity of the application justified this approach, as PC's of the day weren't quite powerful enough to replicate the application. In others it was simply laziness and greed, or perhaps some hope that the naysayers were right- it was just a fad, and they were better off waiting until things changed again.

This pattern is repeating today in traditional process industries.

History repeats itself

Unfortunately, in the process industries, there is not a large appreciation for software standards of practice. This is not true in some other industries- financial, and risk management are two that come to mind. As a result, many of the software vendors who service the industry are hoping that most of their users are not aware of the thin-client revolution. The cost to redesign their applications (again) could be horrendous.

Living around Austin, Texas, we have seen software standards taken to their ultimate test. We were in the center of the dot-com (dot-bomb) revolution. The software platform necessary to support the dot-bomb revolution had four basic requirements. It had to be quick to develop; it had to be easy to install; it had to be easy to use; and it had to be cheap to maintain. Without those elements, you could not expect to sustain the minimal profit margins that these companies were expecting to make up in volume in a quickly evolving market. In many cases, it turned out that the volume was zero, so low percentages of zero caused for shuttered companies (and a flood of used Herman Miller chairs on ebay).

Shuttered companies aside, the design techniques and development platforms to support this software revolution are newly available. They are phenomenal in their value and reach. And they enable better software. Those willing to make the herculean effort to redesign on these platforms realize the instant resultant lower TCO (Total Cost of Ownership) for their clients. They also guarantee extended viability for their products as interoperability issues come to the forefront. this is very similar to the revolution caused by the introduction of the PC desktop in the '90's.

I want to sing the praises of the MS ASP.NET architecture. TiPS Inc. has made the large investment over the past few years of redesigning our products to work within this architecture. As a result, we become instantly interoperable with any and all other products built under this framework. Our clients avail themselves to our products over a true thin-client route that requires a dedicated investment to undertake and maintain.

unfortunately, this architecture allows the use of a ".NET wrapper" just the same as a PC allowed the use of a menu-driven batch file to be created. At any rate, it is only a wrapper- not a true thin-client application.

Buyer Beware

I recently saw a company advertising their "software suite that was built on MS. NET" Hah- the "suite" is a container built on .NET that then allows web-browser interface to these legacy applications. Their products they want to sell you under that container are still legacy products built several years ago. I guess the container or shell makes it viable to say the suite is "under" this framework.

In other industries, as mentioned before, the first questions asked of any software sealesperson are the right questions. They stop you mid-feature description and ask: Is the APPLICATION itself built on a thin-client architecture? If not, what is it built on? Any other answer causes no further questions to be asked. Yes, they will allow you to finish, and polite ones don't even look at their watches. These users have learned the Total Cost of Ownership (TCO) has very little to do with features of the software. Modern architectures allow any software to add features on request. But a bad architecture will live with you for many years, and make you wish you had asked certain questions up front.

A quick check you can employ is how does the application deploy clients? Do they have to be installed (even if automatically) on each machine, or do you just open up a standard application such as Internet Explorer, and have instant access to the application? Lack of a true thin client is a sure sign of a cluged application infrastructure. True .NET applications make full use of web services that is integrated into the microsoft framework.

Other signs to look for are: What about integration with MS SQL, and true real-time access to the SQL architecture? How long does it take to perform a query on real-time, instantaneous results? Are results available in real-time, or does data have to be batched in for occasional review? Does a different application require installation of another module?

What about ease-of-use? Does it seem intuitive to use? Can you just click on things and start to get answers? Is there an effort towards two-click resollution? Recall that this is the model that Microsoft brought to the industry. As an example: Though MS Word will do a lot of things, you can get in quickly and make a letter without ever studying all the intracacies. True industrial applications should offer this same level of ease of use. True .NET software developers strive towards two-click resolution.

Lastly, what about upgrade and maintenance issues? How much disruption is the release of a new revision going to cause when I need to install it throughout my system? Do I go to one point, and I'm done, or do I have to find all users, and upgrade their clients also? Vendors who are short on architecture usually try to lead the argument with features, or point to their strong services surrounding their software.

Review these issues when you are studying software purchases. You'll find that for many, software is a side-line to their main business- normally services. Such companies cannot usually be expected to keep up to date on the latest software development issues. As I have already mentioned in a previous post, that is not important to them if they are also going to be the users of the software. They know the command-line syntax to get around all of their software quirks.

We perform to these standards, but then, we live in the middle of the Austin software think-tank. The'd laugh us out of the neighborhood if we didn't perfrom to standards.

In sharing this with you, I am revealing the biggest fear of any software company. Someday, somebody will write the operating system that is so easy that 16 year olds will build what we've invested so much in within a three-day period. The tools will just be that easy. It hasn't happened yet, but the new software out there truly does offer levels of development speed and inter-operability that were previously unseen. For those few of us who have invested in this infrastructure, our clients will reap the benefits for many years to come.

For those of you who wish to understand this a little better, study the way vendors advertise their software in other industries (CRM, for instance) Go to their websites, and review their software descriptions. They don't even mention features. They just talk architecture. Sometimes, its difficult to even figure out just WHAT their software does (feature-wise). That's because their market is matured to the point that several generations of software maintenance have shown where the true costs of software reveal themselves. So, be aware, and ask the right questions, and watch for uneasy squirming. Educate yourself to, and examine what is termed "Total Cost of Ownership" (TCO) issues. Your company will be glad you did.