XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] 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]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS