Grants.gov and Mac issue highlighted again in WashPost

The Washington Post has a column today called Macs and Grant Site Just Don't Click to follow up from an article back in February. Rick Weiss has found some interesting facts:

• Northrop Grumman has been testing the PureEdge/IBM Workplace Forms Mac client and it's working. It's clearly not perfect (because it's beta software) but it's getting there. However, Northrop won't be sticking around to complete development on this before General Dynamics/Anteon rolls into town.
• General Dynamics/Anteon will be using off-the-shelf Adobe Acrobat eForms which will be modified "in minor ways to fit the requirements of the government's grant-application system".
• NIH's R01 deadline may be pushed back to accommodate rollout of the "new" Grants.gov system in March 2007. (Note that at yesterday's NGP meeting, Grants.gov said that the rollout will be on April 1, 2007.)

In effect, General Dynamics will inherit a half-finished Mac client and will introduce a whole new e-forms technology which will replace IBM/PureEdge or supplement it.

I'm not sure what to think of this. Our team proposed a different route: retaining the IBM/PureEdge clients and introducing the Mac client after extensive testing. Our main reasons for this approach were:

• [See change note below.] The e-forms issue is only one part of the problem: another part is the data brokering software in place, which is called InFlowSuite. It's my understanding (though I have no evidence other than here-say to back it up) that this software has some performance issues with regards to extracting data from the Grants.gov forms and passing them on through the system. In addition, the latest version of the PureEdge forms offers significant performance improvements over that being used at Grants.gov today. I've heard that the reason Grants.gov hasn't been able to use this version is that the InFlowSuite cannot accommodate the new software. So replacing InFlowSuite may be paramount to ensure Grants.gov's future utility, for things like S.2590, etc. Keeping InFlowSuite in place might therefore jeopardize project success -- but replacing it is also a costly proposition. We elected to replace it.
• Replacing all the existing e-forms would be costly and risk-laden.
• The Adobe suite doesn't have forms "stitching" built in; those tools were in alpha development as proposals for Grants.gov were being prepared.
• Solicitations are already out with closing dates after March 1, 2007, meaning that the new Grants.gov system will inevitably have to support the IBM/PureEdge forms anyway.
• We had a strong fallback position: If use of the Mac PureEdge client didn't work, we'd assess the level of effort required to switch to the Adobe suite, taking special consideration of the need for forms "stitching".

So balancing all of the technical and cost constraints, we elected to keep the PureEdge forms, at least as our starting position. I think this was a solid plan but it's not without its problems. While IBM will have a Mac client, there are no plans for a Unix or Linux client -- both of which Adobe can deliver today. Our assessment of grantee's needs, however, showed that Linux and Unix users are a very small minority of users. Given that millions of dollars have already been invested in the IBM platform by Grants.gov, it seems very hasty to discard it all in favor of an unproven, untested, and under-tooled alternative approach, to satisfy a really small population of users.

(Now I'll wait for Unix and Linux users to start throwing firebombs...)

I'll repeat this again in case I'm sounding purely cynical: We are customers of Grants.gov, and we have been great advocates of its adoption throughout government, despite the ire that this creates in some agencies. I really, sincerely hope that the new Grants.gov system is everything we all need it to be, and that General Dynamics/Anteon succeeds. And I also hope that we get more detailed information about their plan to create this success, very soon.

[Updated 9/14/2006, 13:30: The bulleted paragraph above that begins "The e-forms issue..." was changed. Upon re-reading it today, I think that the prior version of this paragraph made statements that were unfounded given the lack of available public information about the InFlowSuite and Grants.gov's system performance. I changed the paragraph to make it clear that the issues I mention are founded in here-say and not based on any documentation or information to which I have access. It's important to note here, I think, that I made this change of my own volition. I haven't been contacted by anyone (Northrop Grumman, Grants.gov, or anyone else) about this. Rather, upon reviewing the posting I realized I'd overstepped the bounds of known, public fact and wanted to correct that at the earliest opportunity. Thanks!]

Comments

[drrw]

Dave,

I disagree with the approach your team proposed.

1) PureEdge is dead technology - it takes 5Gigs of RAM single threaded per server to process the proprietary binary formats. That's a scaling nightmare. It needs replaced ASAP to enable broader access and allow GGov to scale.

2) We need open technology that is vendor neutral so the entire grants community can easily integrate forms and rules and develop community resources. Shared forms technology also fosters easy re-use.

3) Adobe forms is not flexible enough to do that - and in any case Adobe is killing that product in favour of AJAX. So GGov have made the same mistake again - selecting aging technology that is sole source and lacks flexibility and limited # of expert developers available for support /extensions.

4) Layered approach is essential - this is how the W3C designed XML - but vendors do the opposite - lock you into a single blob of technology that they own. What that does is limit extensiblity - for example - how does Adobe forms support the new single sign-on process? A layered approach allows you to plug-in components seamlessly from providers and services. That is also the message of web services and SOA.

[Dave]

Thanks, Dave, for your thoughtful comments. I don't disagree that e-forms technology is a relic-in-the-making. There will always be a place for it, of course, but other technology has already overtaken e-forms in many scenarios.

I don't think Grants.gov is ready for an AJAX-based approach. As you note, Adobe is presently moving towards that model -- but it's not there yet, and Grants.gov isn't about to become an early adopter. Politically, that simply wouldn't fly.

One might also argue the case (as Rob Fay has) for a Java client, or for XForms, or for many other technically-feasible-but-flawed approaches. We took the position that preparing for the future was most important, which is why we focused much of our attention on the data brokering architecture that would enable any number of forms technologies to be used (e-forms, web forms, XForms, AJAX-XML forms, etc.).

I don't envy the job of those in charge of Grants.gov. No choice they will make will ever be free of nay-sayers (like me, ho ho!). I do feel, though, that there are strategies that could be adopted today that would silence or at least placate many of them.

[Ray Blaak]

> 3) Adobe forms is not flexible enough to do that - and in any case Adobe is
> killing that product in favour of AJAX.

Adobe dumping forms in favour of AJAX? I don't think so. PDF is just too important a component of anything to do with a legal document. Also, as far as I know, Adobe's movements in the rich internet space come in the form of Flash/Flex, not AJAX as such, although Flex can certainly work with AJAX enabled content. At any rate, Flex and AJAX are front end client technologies, and even with them once still needs a backend document processing solution like LiveCycle.

[Arni]

Forget Adobe PDF. The PDF viewer has the same issues as puredge. Thick client.

Think simple HTML e-forms like Cardiff's cool LiquidOffice

[Dave]

Arni, the boat has already sailed and the Adobe forms are in full-force migration right now. I'm intrigued by the new e-forms products, such as LiquidOffice, which are striving for a more standards-based approach, but are they really mature enough for deployment on the scale of Grants.gov?