[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: XML As Fall Guy
I look for low hanging fruit. For example, we see this big IT project where they "say" they want to integrate systems. What is the n of integration? IOW, start with existing forms. Do they really mean to put all of the data these capture into one honking relational system OR do they want to capture the same data and put it somewhere. 1. They really want the big bad relational system. Big dollars. Much business rule capture, much sorting and crunching down the names to fields and data types, much discovery of when is B = A OR B == A, much how do I decide when a name is a person or a person is a name, etc. We know the drills. Charge X. 2. The only want to get this data into the same place and get rid of the paper. AHA! Write XML docs that replicate forms, output PDF, tell PDF it is a form and let Acrobat Pro do its voodoo that it does so well, clean up the names and check the XML export (just in case I need it but I might not), write a web page to download forms/PDFs, write a web page to upload forms. Write a few more pages for finding forms. (Never said a word about validating did they? Good. If they do, I'll renegotiate and start working on the names in those data bags they've been collecting.) IOW, if you don't have to do it all upfront, don't. Plan to do some of it later and make sure it can be done. Some people don't want to replace paper; they want to quit killing as many trees. They don't want to reengineer all of their processes. They want to quit carrying paper back and forth from a flight line and stuffing in a desk and trying to find it later. They have these neat little tablets but they don't need them to think for them. They just don't want to scribble. The 99% problem is a problem of requirements. The better you are at this the better you can talk to the folk who don't understand the details by talking to them about what they do know and then making damm sure you can turn around and tell the folks in the basement precisely what to build. And if the customer begins to play wrong rock right rock, take a contract lawyer to the meeting. len Quoting Rick Jelliffe <rjelliffe@allette.com.au>: The enquiry into the Queensland debacle, where a $4 million project spiralled into maybe a $400 million mess, found that apart from personalities and capabilities and execution, the problem was the "shared services" myth. This says that if you have a few dozen disparate systems doing much the same thing, you should centralize. The trouble being, in reality, that if the disparate system all represent variant functionality, with not much in common, your customization effort can be much bigger than your platform effort. You still have to find and replicate all those differences: to me it is a classic case where a little bit of waterfall would be prudent: reverse engineer the current system before you design the next! At least then you know where you are up to... The government "shared services" efforts here in Australia have all been pulled back: the premise so often being wrong that the failure was guaranteed. As Gareth says, the US problem sounds similar: the problem being to cope with multiplicity not commonality, if I can paraphrase Kurt's early post. Rick On 27/11/2013 4:32 PM, "Gareth Oakes" <goakes@gpslsolutions.com> wrote:> On 27/11/2013 7:37 am, "cbullard@hiwaay.net" <cbullard@hiwaay.net> wrote: > > Simon sez: "Whatever the underlying story, I suspect we'll be dealing > with the reverberations from this for a while." Agree with this. The one thing for sure is that MarkLogic now has a big headache and a lot of damage control to worry about :) I think you'll find that now the spotlight is on those responsible for the Healthcare.gov project, they'll be grasping at any straw they can to spread the blame around. I'll bet that in the application they are using it for, MarkLogic is a sound technology choice. My conclusion: this smacks of a typical "big business" technology acquisition. We had an analogous problem over here in Queensland, leaving a $1.2B hole (search: Queensland Health payroll disaster). The somewhat amusing upshot being that IBM is currently banned from doing new business with the Queensland government. I wonder how much better these types of projects could go if a more incremental (Agile) approach was taken. The beauty of XML is that if you set the systems up right it can give you amazing flexibility and power combined. Cheers, Gareth Oakes Chief Architect, GPSL www.gpslsolutions.com _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|