Re: [xml-dev] Re: XML As Fall Guy

[cbullard@hiwaay.net]

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