System iNetwork

June 2007

June 26, 2007 11:50 AM

Is Privacy Becoming an Ethical Dilemma for IT?

If you're an IT person, you should be quite aware of how serious a problem such issues as corporate data breaches, excessive employee use of corporate computing equipment to conduct personal business, and internal snooping by unscrupulous or just nosy fellow employees have become. That naturally leads to interest in methods of combatting these problems, such as data encryption software, corporate monitoring of Internet use, and security controls on data access.

On the other hand, particularly in the U.S., there has been a general drift in the culture away from too much "Big Brotherism," a fear that too much information in the hands of the government (and by implication, any authority figure) might end up being bad for us as individuals. This concern paradoxically grows as computer technology gets better, and with it, the ability of strangers to learn more about us than we're comfortable with them knowing. Although the tragedy of 911 has made us all grudgingly willing to put up with more security checks when we're travelling, and the knowledge that hackers and phishers are out there make us more wary about checking that the means of transmitting our financial information is secure and legitimate, most of us are still of the "OK, that far but no farther" mentality about security.

But I wonder if, for IT people in particular, there isn't actually a disconnect happening between our professional attitudes toward privacy and those that we hold as private individuals? More specifically, doesn't the very idea of, for example, monitoring fellow employees' communications, raise some ethical issues in and of itself?

Four studies bring out the contrasts. (I should point out that none of these were done by companies offering System i products, but the idea I'm trying to get at is as valid for IT shops using System i machines as it is for those using any other platforms.) The first one was released last fall by Palisade Systems ( http://www.palisadesys.com ), a manufacturer of content and network-security appliances. "Sounding the Alarm on Internal Threats to Consumers' Sensitive Data and Employers' Proprietary Information" surveyed respondents in 171 government, university, and commercial organizations about internal organizational security hazards. What's significant is that among the corporate participants at U.S. commercial organizations, response was unanimous that all employee communications at work should be monitored to insure that proprietary company data, or identifying customer data such as Social Security numbers, weren't being transmitted. (Interestingly, only 11 percent of the respondents working for government agencies agreed with this stance.)

A second study, which I point to not because of any particular results but because it's typical of many you've probably read about over the past few years, was done by Vericept Corporation ( http://www.vericept.com ) and released last week. Titled "The Case for Data Leakage Prevention," it surveyed 206 security professionals at organizations with at least 1,000 employees in 21 vertical industries about the consequences of data loss. Nearly a third of the respondents reported a data breach in the last year and one-third of those people said the data breach caused a "direct loss of revenue." (Ten percent of respondents said they didn't know for sure if a data breach had taken place!)

The third study was commissioned by the Society for Human Resource Management ( http://www.shrm.org ) this year and reports the result that an average of one hour a day is lost to "cyberslacking" by employees engaging in such activities as looking up information of personal interest on the Internet, playing games, or writing e-mail messages to family and friends.

The final study I'll quote was released in November 2005 by WeComply ( http://www.wecomply.com ), a provider of business ethics and compliance training. This one asked 1,000 U.S. workers if they thought their personal computer activities at work remained personal or became their employers' business records. As you and I know, personal e-mails, Instant Messages, and personal web searches DO become employer business records simply because they're carried out on the employer's equipment. But more than half of those surveyed didn't know personal e-mail and unsent files become business records, 40 percent didn't realize personal web searches become business records, and two-thirds didn't realize that personal IMs to friends become business records.

Let's set aside the arguments that we don't know how valid the methodologies, the sampling techniques, the question wordings, and other aspects of how these surveys were conducted are. The specific numbers almost certainly aren't entirely accurate and some of the surveys are admittedly a bit old. But I think the tendencies they report are valid. And what do those tell us?

Unauthorized data transmissions and cyberslacking are real. The Vericept study and others like it show the problems are serious and must be addressed. The Palisade study shows an overwhelming majority of IT people think employee communications, and I think by implication Internet activities, must be monitored by a human to prevent abuses. Personally, I hate this idea, but isn't responsibility to the enterprise pushing IT in that direction? And doesn't mere contemplation of any monitoring program raise at least two ethical problems for all IT people?

First, given most people's expectations of privacy, and particularly in light of the large numbers of
end users in the WeComply study who seem clueless about the line between what's business and what's personal, isn't any monitoring program going to be viewed as a violation of trust by most of your end users? What a boost to IT's image that'll be! Granted, employees should know better than to use company computers and software for personal activities, but don't we all do things occasionally that we know we shouldn't? More to the point, doesn't this state of affairs mandate that if an enterprise institutes a monitoring policy, that fact needs to be regularly and publicly (and maybe even loudly) stated to the end user community? And doesn't it mean that secret monitoring should be considered unethical, no matter how high-minded the motivation?

Second, is IT really up to the task? I'm not talking about YOU, of course. We're professionals who would never, if assigned the job of monitoring our fellow employees' e-mail messages, read entire messages we thought were of a personal nature so long as we could tell no corporate or personal identification was contained in them. But what about that guy three cubes down who's always dishing the gossip and wondering out loud about the character of people who would do whatever it is he's on his soapbox about today? Would you want him reading all of your e-mail messages? After all, you're an employee like any other. You'd have to be included in any monitoring program, too. Or how about that woman who, most times when you walk into her space, just happens to be shutting down her browser, but not fast enough that you don't get a flash of that eBay logo? Should she be the one deciding whose Internet use is appropriate to the business? So if IT is going to be responsible for any kind of monitoring program, doesn't there need to be some sort of code of ethics or standards for the watchers? Which leads inexorably to the IT version of that classic dilemma: Who will enforce that code?

Monitoring employee computer activity seems necessary. Eventually it may become unavoidable. Any company that doesn't is being foolish, given just the risks and regulations we know about already. But doesn't IT have at least an ethical, and perhaps even moral, obligation to its users to do this very publicly and with careful consideration of end-user sensibilities?

Posted by on June 26, 2007 at 11:50 AM | Comments (1)

June 19, 2007 10:07 AM

Grid Computing: Still Gridlocked for the System i

One of the fun parts about being a products editor is that I get paid to keep my beady little eyes on new technology for the System i without having any responsibility for implementing it at my place of work. It's like pretending to be on a diet, but instead of eating my vegetables, all I really have to do is spoon down the ice cream. But occasionally, despite my relatively devil-may-care position, I still manage to be disappointed with System i technology. And one technology for the System i that definitely disappoints me is grid computing.

IBM launched its grid computing initiative with much fanfare back in 2003. It sounded great then and still does. We don't have to look far to see its promise. For example, there's John Palfreyman's white paper, "Grid Explained," at http://www-1.ibm.com/grid. He separates grid into three levels. Compute Grid, a "starter" level, "offers a way of speeding up a business application by sharing the processing work needed across several computers." Information Grid, an intermediate level, "gives rapid information access to all types and sources of business data from across the enterprise at users' workstations." Enterprise Grid, which Palfreyman describes as the "ultimate form," lets users "execute their most demanding business applications in the minimum time possible and get instant access to all information."

Just taking this at face value, Compute Grid sounds like a great environment for running ERP or manufacturing applications, for instance. Multiple tasks that feed information to each other could run in parallel and come up with answers faster. Manufacturing companies could more quickly figure out complex manufacturing orders that require many materials and actions to assemble the final goods for shipment. And I don't know about you, but Information Grid is just screaming "data warehousing" to me. Remember all those anecdotes about figuring out that diapers sell better when they're stocked next to the beer so busy dads can buy both without looking for either when they're making a run at halftime? What other secrets does your enterprise data have locked away if you could just get the processing power to uncover them? Finally, Enterprise Grid really sounds like having it all, doesn't it? Complex systems of applications running together to propel business activities and keep every user with a need to know informed up to the minute. That could just about be computing paradise from an end user's point of view.

Granted, economies of scale of this magnitude are mainly going to be affordable only for large companies. But those enterprises are out there in our market, some running dozens of System i machines throughout their organizations. Even some medium-sized companies could surely benefit from this technology, too. Harnessing all that capability in more efficient ways is just what grid computing is designed to do. And really, isn't that what the promise of business computing in general is all about: Mobilizing these tools we've invented for ourselves to run our businesses more efficiently? I'd say so, but . . .well . . . grid on the System i . . . it just isn't happening, is it?

OK, back to earth. Sure, when IBM announced this technology, we all expected it would be a little while before it showed up on the System i. And it sort of has shown up, but only sort of. Let's take IBM's own explanation of its "Grid and Grow Express Implementation" program at http://www.-935.ibm.com/services/us/index.wss/offering/its/a1025916, which would seem to be a logical first place to go for information for someone thinking about a grid computing implementation. Except that document states quite plainly that to implement grid, you need to be running Red Hat or Novell SUSE Linux Enterprise, AIX 5L, or Windows. Granted, there are some people running those OSs in LPARs somewhere on their System i machines, but it's not very many yet. So the rest of us are just out of luck?

IBM does offer the IBM Grid Toolbox V3 for Multiplatforms, its "integrated toolkit for creating and hosting grid services," which does support the System i. At http://www-03.ibm.com/grid/solutions/grid_toolbox.shtml, IBM even states that tools for System i support will be available for electronic download as of June 25. That's next Monday.

Or is it? I'd feel a little more confident about that date if it weren't for the facts that IBM refers to this as "support for OS/400 on IBM System i" (shouldn't that be "i5/OS?"), the Grid Toolbox V3 solution brief document to which this page links is copyrighted December 2003, and even the Palfreyman white paper is copyrighted January 2005.

So is this new information or just a forgotten corner of IBM's web site? Whether it's really taken four years for this technology to become available on the System i's native OS, or it's actually been around for a couple of years and nobody's noticed, this certainly seems to be evidence of a lack of emphasis somewhere. And that's unfortunate, because even if there has been a lack of demand in the market for it, grid computing on the System i is a technology that seems to offer some of the best of what computing should be all about.

Posted by on June 19, 2007 at 10:07 AM | Comments (1)

June 11, 2007 2:27 PM

When Does a Query Tool Become a BI App?

I've just spent a couple of days researching a product roundup on query and reporting tools. (You'll get to see the results in the Route Finder insert of our August issue.) That exercise brought home to me once again just how fuzzy the dividing lines are getting to be between such concepts as "query and reporting tools," "business intelligence applications," "executive information systems," "data warehousing solutions," and utilities that help developers query databases as part of building such applications. And I guess I forgot to mention online analytical processing apps, extraction/transformation/loading utilities, and decision support systems, but you get the idea.

It's not that what each of these application types does is imprecise. With nearly any search engine, any of us could come up with explanations for all of these terms in about five minutes that would show a separate, well-defined area of the business intelligence (BI) turf for each one. The fuzzy part is where any company's solution stops being one BI product type and starts being another. And, more unfortunately, how some people are coming to refer to BI in general.

Query and reporting tools are a good example. You might think it would be fairly easy to come up with a short list of products that let you structure a database query and write the results into a predefined report template and send it to the boss. It isn't, really. Because most programmers could do that ad hoc on their own, vendors of third-party products realize that to sell software, their product has to do a little more than that, even if the intended audience is a bunch of relatively nontechnical end users rather than programmers. So the vendors add more features, more spoon-feeding so even a nontechnical administrative assistant can use the software, more output options, maybe an analysis tool. . . Pretty soon, though, you've crossed the line to a BI app. But where exactly did that happen?

I turned to an expert for help: Scott Steinacher, our technical editor who focuses on BI (and who happens to be the author of the cover article for the Query and Reporting Route Finder in August). I asked him, "Where do you draw the line between a 'query and reporting tool' and a 'business intelligence application?'" His answer was pretty much what I feared.

While he drew a distinction between BI and data warehousing because the latter "implies a specialized database built specifically to support analyses," he also admitted that any more "both terms are used interchangeably" and that, when you really got down to it, a list of query and reporting tool products had to include all products of any BI type because all offer query and reporting functionality. But really, among those who aren't BI experts, aren't all these BI product types and terms becoming somewhat interchangeable?

Another area of blurred lines are several products in the application development tool area. Mrc offers m-Power and mrc-Productivity Series, two solutions known primarily for helping developers build System i apps in Java and RPG, respectively. Developers can use both to create queries and associated reports that they then pass on to end users, so can they be employed by an end user to query databases and generate reports? I asked Heather Gately, mrc's marketing director, and she assured me they can. "Yes, end users can use [both products] themselves to query the database and create reports, etc. In fact, we have many customers who do just that." There are other products that are primarily programmer tools that also provide a query and reporting function, such as Linoma Software's Surveyor/400, but this example makes the point.

So where do the lines get drawn between these product types? I realize one can make the argument that this is a discussion without a real meaning if you look at products being important only in terms of the functions they offer. You buy software that does what you need it to do and on a certain level, who cares if the vendor calls it query or BI or decision support?

But that's only true to a point. And that point is when your CIO says to your IT manager, "we need a BI app, go find us a good one." What does she mean when she says that, and what does her IT manager think she means? Probably more discussion takes place, but maybe it doesn't, and maybe it does but doesn't do much good. The IT manager might be afraid of appearing to be ignorant or rude if he should ask the CIO to define what she thinks a BI app is. But maybe they actually have two different concepts in mind. One wants a data warehouse, the other is thinking of a nifty little query-and-report writer that end users can check order volumes and customer credit status with.

If we can't agree on terms, if we don't really know where a query tool stops being just a query tool and turns into a BI app, a fundamental miscommunication can take place that maybe no one sees until considerable time and money's been spent following the wrong path. So I leave it to you, the jury. Where should the lines be drawn? When does a query tool become a BI app?

Posted by on June 11, 2007 at 2:27 PM | Comments (3)

June 4, 2007 3:34 PM

A Thoroughly "Modern" Muddle?

One issue threatening the System i's mere existence is the misperception by IT managers and the executives they report to in some enterprises that the System i is "old technology." (We're talking here just about conventional wisdom among some people who mistakenly think they're informed about business computing.) Simply put, the issue is that some people who heard about the AS/400 back in the 90s, and then quit thinking about it, have the idea that nothing's really changed since then except maybe some processors and the name IBM glues to the machines they ship. Their expectation is that things aren't that up-to-date on our favorite box anymore and that software running on it just isn't modern enough to handle the needs of a 21st century enterprise. You and I know this isn't true, but I wonder if the way we talk about what constitutes modernization sometimes isn't contributing to the problem.

"Application modernization" is in some ways one of the most talked-about, thought-about, and written-about issues for the System i. But what do we really mean by that term? And doesn't the context actually change depending on whether the discussion is about tools and techniques for helping developers modernize applications or whether we're talking about packaged software? System iNEWS has published scads of articles and newsletters on the former, but let's think about the latter for a minute.

Let's say you're either an IT manager, or someone who's been charged by the IT manager, to make some recommendations about buying packaged software to "modernize" your company's operations. There's not enough time to develop or re-engineer existing apps, so this can't be about tools. It has to be about packaged application software. To make it more convenient, we won't even make ourselves think about how we might need to adapt the software to the needs of the business, or vice versa, we just have to obey the mandate to "modernize."

And that's really the problem. There's a whole continuum of levels of application modernization, and people often aren't specific at all about where in the spectrum their expectations fall.

At the bottom, we have the simplest approach of screen-scraping, which converts green-screen interfaces to Windows-type GUIs. Sometimes, end users are happy just with that. Give 'em a GUI, and the agitation for moving to another platform calms down to an ignorable level.

Another notch up is to provide a browser interface (BUI) so customers and business partners can more easily access those apps. Maybe we should even specify that applications use a Model-View-Controller structure so it'll support GUIs or BUIs. Oh, but you need that BUI to display on PDAs or cell phones so your people in the field can send and receive information to and from the apps? Well, that's only a little more complicated.

Of course, what if you need to incorporate some workflow elements? Let's say you need to slide that order past the accounting department to make sure the ordering company has a good credit standing. And maybe this order includes some installation services, or goods from another part of the company, so you have to talk to another application, maybe on another platform, requiring use of XML or some messaging protocol to provide that link.

Or maybe "modernization" means having everything written in one language, like Java, that will facilitate running applications on most any platform, and simplify application maintenance and customization across all platforms in the enterprise.

And maybe you even have the misfortune of working for that proverbial company whose CEO read in some magazine some place about how efficient and wonderful a services-oriented architecture (SOA) is. Companies don't need applications anymore, they just need a bunch of web services that do everything. "Why can't we have that here?" (Not that SOA is a bad idea. In fact, if you're going to go through the pain of moving to that kind of a structure, at least you know it will be something that could work well for many years.)

To be honest, if you hear anyone talking about application modernization with no context, that person could mean any of these degrees of technology, or anything in between. And unfortunately, let's say among executive types whose depth of technology knowledge may be shallower than the splash of coffee you spilled on your desk this morning, the conversation could actually mean all of them.

So what's "modern" to you? If you had to buy some software that would "modernize" your enterprises' apps and operations, what features would be necessary to qualify for that description in your environment? Is there some point on this feature scale at which we should stop calling it "modernization" and instead be thinking of it as part of the required baseline for any app? Or has "modernization" become too all-encompassing a term to let any discussion be more than a muddle?

Posted by on June 4, 2007 at 3:34 PM | Comments (17)