System iNetwork

September 2007

September 25, 2007 10:26 AM

Building Apps: Change Management or Chaos Management?

One of the major issues in software development is keeping track of what changes have been made to applications under construction or maintenance. Especially when more than one developer is working on a particular piece of software, it becomes far too easy for programmers to duplicate each other's work unproductively. One developer may inadvertently overwrite the work of another, a team may build incompatibilities or errors into code, and blocks of code may be rendered useless when conditional statements that would cause them to run are deleted. Plenty of unintentional problems can crop up, and these examples are just about coding steps.

The solution to these problems is to use software that provides some automation for software version control, compiling new builds and distributing them, organizing workflow and other processes, tracking change requests and incident reports, and auditing and reporting to management on these activities. Most people seem to agree that software of this kind is necessary and can pay for itself over time, even though the managers of many companies are reluctant to spend the money for it initially. The most common name for this product type is software configuration management (SCM).

System iNEWS covered the major issues surrounding SCM and highlighted the major SCM solutions for the System i market in its Software Configuration Management i5 Route Finder included with the March 2007 issue. The software requirements and players for System i have been the same since then.

One thing that remains confusing is how to refer to products of this type. There's really no general agreement. Not so long ago, they were called change management (CM) solutions. Then they were redubbed SCM. Lately, the IT industry has been moving towards a new name, application lifecycle management (ALM). And IBM, which certainly carries some weight, additionally refers to such solutions on its Rational website as "change and release management" and "build and release" management. But that's not the only problem.

Outside the System i market, there are some signs of disarray in this product area. Late last month, Borland Software Corporation released a survey about ALM use at 300 of its customer sites that shows 90 percent of those customers using "multiple ALM tools from several different vendors." Fifty percent are using four different tools, and 33 percent use three tools. What's more, 69 percent are supporting two or more development platforms (42 percent deploying to both Java and .NET environments), and 44 percent are using at least two separate development processes. That doesn't seem very orderly.

To put this in perspective, Borland's tools don't run natively under i5/OS, and its ALM suite consists of more than 10 products that, while integrated, individually focus on different aspects of planning and designing apps, defining their requirements, developing and managing processes, and serving apps to users. Borland also plays in the multiplatform space on purpose, so its customers are naturally going to favor those environments. But this isn't irrelevant to System i because many System i sites are multiplatform as well, and trends in the greater IT market have a way of catching up with System i sooner or later.

Borland's revelation struck close enough to home that MKS CEO Phillip C. Deck (whose company does produce three System i ALM tools) issued a same-day statement dismissing the survey results. "Borland's marketing machine may be working overtime on their ALM spin, but they aren't creating order among the chaos of heterogenous products with their totally different interfaces, data models, and workflow mechanisms," his statement said in part. Deck's recommendation is that customers need to look for "a unified solution for end-to-end ALM."

So it would seem that, far from being as simple and straightforward a product area as the term CM might imply, we have at least some disagreement about the best means to achieve it as well as difficulty nailing down what to call it.

Shakespeare's Romeo famously expounded on the meaning of names. In the centuries since his musings were put to paper, people have tended to quote him as much to show the lack of importance of names of things as to show the importance of agreement on nomenclatures. What we call products and concepts in the IT world in general, and therefore by extension the System i market, can be more crucial than we think because it's all too easy to overlook critical shadings of meaning. These can get lost in our rush to jargonize concepts and reduce them to shorthand references in conversation, as we all tend to do, and that can lead to discussions in which two people use the same words but are actually referring to different concepts. Tracking application development activity is turning into a technical area that holds that danger because CM, SCM, and ALM aren't necessarily different names for the same idea. They're each developing their own flavors.

CM's cachet is old hat. It has become too general because it started out meaning simpler processes, as an acronym it's too easily confused with configuration management, and at least for me, it's too tempting to think of it as chaos management, an oxymoron. SCM comes from an early software engineering book and focuses on the management methodology of individual software development projects. ALM, in contrast, views software development not as a project with a beginning and end but rather as a process that repeats more or less infinitely but follows the same basic steps. IBM's Rational site postulates a three-tiered definition. SCM is for "version control and parallel development support to manage and control software assets." "Software change management" products are for "defect tracking and automation of software processes." "Build and release management" products are for "accelerating, standardizing, and automating build and release cycles." To me, this sounds like a methodology that would apply best to a company that primarily produces software, proposed, strangely enough, by a company that produces software.

How can we simplify this? SCM works as a model for building or revamping a single application or application system. ALM presumes that application development is never done, that as soon as you finish revising anything, it's on to V3 tomorrow with no letup. So SCM still seems appropriate for SMBs who want a new app, or to update an app, but then plan to run with that for a while. That's a common System i shop scenario. ALM-type development, though, is becoming the defacto situation in any enterprise that can't keep up with user and business demands for software changes. By the time IT delivers the goods, the next wish list is already on the white board. I think the worst of all worlds would be to have an SCM mindset in an ALM reality. Know anyone in that pickle?

What's the answer? I think Deck is right about this product area being chaotic, but I also think the chaos doesn't come just from the proliferation of ALM product approaches. It comes from the inherent chaos of application development having been an art rather than a science for decades now. Herding a catlike team of programmers or organizing a couple of handfuls of legacy apps into producing a unified outcome is similarly going to resist any one-size-fits-all approach. The bottom line is that when thinking of adopting any SCM or ALM product, your enterprise needs to do a lot of self-analysis first to figure out where your demand is on the SCM/ALM spectrum and what approach might work best. Starting a Google search for products should be anything but your first step.

Posted by on September 25, 2007 at 10:26 AM | Comments (0)

September 18, 2007 2:17 PM

What's Most Important to Have in a BI Tool?

"Knowledge is Power" is such a familiar truism that even Chinese fortune cookies occasionally remind us of it. That certainly holds even more true for running a business than many other activities in life, and therein lies the power of business intelligence (BI) applications.

There's probably no such thing as perfect intelligence, but the BI tool vendors, bless 'em, are doing their best to inch closer to that goal every day. But if you're looking for a new BI tool, or at least a better one than you may already have, what you're missing is a snapshot of where BI product feature progress stands today. So here at -- System iNEWS -- and SystemiNetwork.com, we've decided to present a buyer's guide to BI applications this December to help you compare and contrast the functions and features of as many BI solutions for the System i as we can.

That brings up the interesting question of what functions and features are most important to have in a BI tool. "That depends," would be the standard answer, "on the business needs." Those are different for everyone, affected by such widely varying influences as market, business size, business age, the nature of your products, your competition . . . I won't go on with examples because it's seemingly an endless list.

Similarly endless-seeming would be the list of features you'd come up with if you trolled all the BI solution sites and wrote down every function you saw touted in the online documentation. For example, you can't just analyze data with a BI tool. Depending on which one you're talking about, you can also analyze trends, segments, workflow, business performance, and metadata, not to mention your sidewalk multidimensional cube.

From where do you want to get your input? Your ERP, CRM, GL, or other applications? A data warehouse or merely a data mart? Web services, flat files, text files, relational databases, databases on other platforms, "unstructured data," MS Excel? Metafiles made up of joined DB2 files?

How would you like to navigate? Drill up, drill down, drill through, drill across, "drill anywhere?" How do you want to secure your data? 512-bit encryption or just 128-bit encryption? Or would you rather simply control user access? By individual or group? Or perhaps it would be best to base access restrictions on the data itself . . . but would that be access to fields, records, models, dimensions, or summaries?

How do you want your output? In what kind of a file? Spooled, PDF, XML, XSL, HTML, DHTML, ASCII, Text, or CSV? MS Word, MS Access, MS Excel, or Lotus 1-2-3? XBRL for you finance afficianados? Should the data go to a thin client, fat client, browser, portal, dashboard, scoreboard, or merely a printed report? Would that be a batch report, a standard report, an interactive report, an ad hoc report, or a custom-designed report? Illustrated with charts, tables, gauges, maps, grids, pinboards, or graphs? Displayed in a star or a snowflake schema?

You get the picture.

It will be a tall order to find a package available that does everything I've just mentioned, and we haven't even gotten into realms such as data cleansing, query building, multidimensional calculations, auditing, and workflow controls, have we? What's best, then, at least from the buyer's point of view, is to find the product that has the best combination of features to match enterprise needs. To do that, we all need an accurate map of what feature sets are actually available to choose from.

So please help me out here. What's important to you? If you had to buy a BI tool next week, what would you want to be absolutely sure it could do above anything else? By extension, what features do you want to be sure we ask all the System i BI vendors if they've got? Please let me know. We'll ask for you, and then you can read all about it in December.

Posted by on September 18, 2007 at 2:17 PM | Comments (4)

September 11, 2007 2:53 PM

The Compliance Cornucopia, Part II

My blog of last week on compliance products stimulated a surprising amount of response, private e-mails as well as public response postings to the blog itself. Because of the nature of those responses, I need to revisit the topic of compliance this week to correct and clarify some parts of last week's entry.

Before I do anything else, I should correct a big oversight on my part, which was that I left out of last week's discussion two important product families, those of Bytware and Tango/04 Computing Group. Both companies spread these capabilities over multiple products that, viewed together, provide many of the capabilities I set out for compliance products. I certainly apologize to Bytware and Tango/04, and to all of you as well, for missing two important elements of the product set I'm trying to define.

Bytware's Network Security embodies most of the features I defined for compliance products. As far as its unique features, Network Security takes a somewhat different approach to compliance activities than many of the other products I profiled last week. It's network-based, and so by default is geared to multiple servers. After installation, it starts out by simply analyzing network traffic for a while, and putting information about, for example, which users (e.g., user accounts, group profiles, IP addresses) are accessing which system resources (e.g., databases, servers, libraries, commands, IFS objects) in a self-contained knowledgebase. At a management-defined moment, after matching user accounts with system resources they're allowed to access, and verification that all user accesses are appropriate, Network Security sets the default public access to all resources to "exclude." After that, no user of any kind can access any system resources unless they're given specific permission, for example via a private authority setting.

Network Security secures more that 120 server functions, includes a data-queue server that lets PC applications work with System i data queues, a database server that enables remote SQL access and controls use of two dozen database functions, and multiple FTP servers. It also embodies a DDM server, a network file server, a remote command server, a CTP signon server, and a Telnet server. Network Security provides additional layers of auditing and security for database files and libraries, IFS files and directories, and remote commands and program calls.

Network Security shares with other products the ability to let users that require temporary special authorities swap profiles with a higher-authority account to get them rather than having them assigned permanently. Network Security's capability also enables downgrading a user's authority by this means when appropriate. Network Security also includes a forensics capability. Bytware's is server-based, however Network Server can export data to PC-based .csv or .txt files for additional analysis. Bytware's Standguard Antivirus product provides antivirus protection. Bytware's Network Security, MessengerPlus, and MessengerConsole together provide monitoring of activities, settings, and values, as well as a system of alerts for meeting or exceeding user-defined thresholds.

Tango/04 Computing Group also has multiple products that, working together, can provide many of the functions I outlined last week for compliance products. VISUAL Security Suite (VSS) offers monitoring services for system and application events that it parks in an internal database for analysis, a firewall/application/device log analyzer, a business-impact analyzer for security events, and an event navigator. VSS audits Windows servers in realtime, as well as up to thousands of users, and monitors changes in user profiles, system configurations, folders, and system objects. It identifies disconnected user profiles. For exit-point protection, VSS relies on PowerTech Group's PowerLock Network Security product.

Tango/04 DataMonitor for iSeries audits data at the record level, tracks all database transactions, let users select specific data-record fields for auditing, can incorporate data from old journal receivers, generate grouped standard reports and customized subreports, and mask confidential data in databases.

Finally, another reader raised a philosophical point I'd like to address, and that is that there isn't any such thing as a compliance product category. "Compliance is an activity . . . not something a product can deliver. . .There is no category called 'compliance,'" this reader pointed out in part.

I agree that all those statements are true. The point I only implied last week but about which I see I need to be more explicit is that I think there ought to be a compliance product category. I'm trying to set about defining one. The reason I want to do that is that the concept of "system security," in my opinion, has become too broad. Security is an umbrella term that includes such functions as diverse as data encryption, user identity management, password administration, and intrusion protection, as well as all the auditing, data-screening, exit-point protection, system value and user profile administration functions on which the group of products I call "compliance" focus. Just as products that offer system security features were once considered part of a larger "systems management product" designation, I think it's time to pull out of the security products category a set of products that, at least partially, automate those aspects of system security that specifically meet compliance objectives.

SOX, HIPAA, PCI, and all the other alphabet-soup pieces of the compliance regulation edifice are here to stay. Congress may tighten a screw here and loosen a bolt there over the years, but these requirements are here for the lifetime of our careers. So that means compliance applications need to be part of the basic set of system functions. They should be as integral as backups. And if we consider compliance to be integral, we should have a designation for products that don't simply support compliance activities, as the whole stable of security products surely do, but rather automate them. Enough IT time and energy now goes into meeting compliance objectives that the convenience and reliability of a system that lets an IT manager figure out quickly what the auditors will see when they arrive could produce a tangible ROI. We should have a category all their own for the products that can provide this peace of mind.

So here perhaps, is the debatable point. Do you agree with me that it's time for compliance products to have their own category, with its own definition, consisting of its own specific feature set? If so, what should that features list consist of?

Posted by on September 11, 2007 at 2:53 PM | Comments (0)