7 ms·

I'm honestly not sure why a better health exchange couldn't be built by practically any team. I've kept hearing on NPR that one of the big problems is that they

by tibbon 13y ago

I'm honestly not sure why a better health exchange couldn't be built by practically any team. I've kept hearing on NPR that one of the big problems is that they 'needed to make it talk to X number of other government/insurance service'. Have these people never heard of REST or JSON? The problems that the health exchange is facing seem to be largely solved problems and not ourside the realm of reasonable scalability. I'm good, but not amazing at development, and I think I could make Postgres do that is needed for this within a week or two.

acchow 13y ago
> Have these people never heard of REST or JSON? I think the difficulty is really in schema matching/mapping.
- hackinthebochs 13y ago
  Right. The systems healthcare.gov has to interface with are established and NOT subject to change. It is up to the new system to be interoperable with whats already there. And this is where this get hard: you have to be able to speak with a myriad of different systems, translate the data to and from the schema of each target system, and do it all securely and robustly. This is all much more complicated than most of the armchair critics realize.
  - lessnonymous 13y ago
    It sounds, to me, like they should have created a centralised spec for talking to these external system. Then created teams to build the interfaces between that spec, and the external systems. So for healthcare.gov to talk to Hospital Insurance Inc. it would actually talk to the Health Insurance Inc shim and THAT would talk to the third party. Now you have a small(er) definable project that a team can deliver and that can be tested. 100 shims later and healthcare.gov can talk to anything because they all (appear to) use the same interface.
eranation 13y ago
They probably heard of it, but they are probably using SOAP webservices or Java EE MQs
- jrmcauliffe 13y ago
  Or whatever came 10 years before that. FTP? Batch tape?
  - davidpardo 13y ago
    AS400 and undocumented fixed column ASCII files, probably. Been there, done that. It's not funny
patio11 13y ago
Man I hate it when HN makes me feel like a grizzled veteran of the technology industry, since I'm barely 30, but I suppose having ever worked with a legacy system qualifies me to comment here: Some challenges with "Just use REST/JSON and then Bob's your uncle:" 1) You will probably not have the source code of the system you are integrating with, which is likely a mainframe system written in COBOL. 2) The engineers who built that system are retired or dead. 3) The company which they worked for is no longer operating / was sold 15 years ago to IBM and then reverse merged into a different unit 7 years ago / lost all of its records in a fire / etc. 4) Your sole documentation is the dogeared paper copy describing file formats for their sole input method, CSV files, which was current as of its publication date, before you were born. 5) Your sole documentation incorporates by reference four other documents which, ahem, yeah. 6) You have a working test suite which accurately models the production system in all respects. It is the production system. Please do not run the equivalent of Accounts.all.delete when cleaning up from your test runs. (The system won't stop you from trying to do that. No, really.) 7) Praise God, there is actually a bridge between the mainframe system and the Internet, so at least you don't have to reverse engineer wire protocols. It was coded in 1996 by IBM's crack team of integration engineers. This will give you an excellent opportunity to brush up on your Java 3.4.1. It speaks REST/JSON, as long as as you spell REST/JSON "XML". Good news, though: your time spent learning the CSV file format won't be wasted, since the XML is just a straight mapping to it. Except for the four bugs in the mapping, which are dutifully recorded in a database in Hyderabad whose existence will be exposed to you 8 months into the project. Welcome to legacy integration! We hope you enjoy your stay.
- incision 13y ago
  Anecdotally, what's described here would actually be unrealistically optimistic given the context of Government where I have entirely too much experience. First, you can forget about having documentation of any kind or anything as recent as XML. Also... 8) Nearly everyone you need to interface with on the customer side is apathetic at best. More likely, they are plain adversarial for fear that the work you're doing will eliminate their jobs. A single person can plop themselves in your critical path and refuse to cooperate - millions of dollars or public safety be dammed - there is nothing you can do other than work around them. 9) You will need to coordinate with half a dozen other subs under the contract prime. Some of those subs will be unassailable due to pre-existing relationships. Others will depend on talent with a 10 hour time difference. One will suddenly be in charge of "testing" your code in order to generate more billable hours. You will be in a constant battle to avoid being used and abused by the prime to make up for the deficiencies of other subs.
sanderjd 13y ago
This may be the most hubristic comment I've ever read. No, you could not "make Postgres do what is needed for this within a week or two" just because you've heard of REST and JSON.

by tibbon 13y ago

acchow 13y ago

> Have these people never heard of REST or JSON? I think the difficulty is really in schema matching/mapping.

hackinthebochs 13y ago
Right. The systems healthcare.gov has to interface with are established and NOT subject to change. It is up to the new system to be interoperable with whats already there. And this is where this get hard: you have to be able to speak with a myriad of different systems, translate the data to and from the schema of each target system, and do it all securely and robustly. This is all much more complicated than most of the armchair critics realize.
- lessnonymous 13y ago
  It sounds, to me, like they should have created a centralised spec for talking to these external system. Then created teams to build the interfaces between that spec, and the external systems. So for healthcare.gov to talk to Hospital Insurance Inc. it would actually talk to the Health Insurance Inc shim and THAT would talk to the third party. Now you have a small(er) definable project that a team can deliver and that can be tested. 100 shims later and healthcare.gov can talk to anything because they all (appear to) use the same interface.

eranation 13y ago

They probably heard of it, but they are probably using SOAP webservices or Java EE MQs

jrmcauliffe 13y ago
Or whatever came 10 years before that. FTP? Batch tape?
- davidpardo 13y ago
  AS400 and undocumented fixed column ASCII files, probably. Been there, done that. It's not funny

patio11 13y ago

Man I hate it when HN makes me feel like a grizzled veteran of the technology industry, since I'm barely 30, but I suppose having ever worked with a legacy system qualifies me to comment here: Some challenges with "Just use REST/JSON and then Bob's your uncle:" 1) You will probably not have the source code of the system you are integrating with, which is likely a mainframe system written in COBOL. 2) The engineers who built that system are retired or dead. 3) The company which they worked for is no longer operating / was sold 15 years ago to IBM and then reverse merged into a different unit 7 years ago / lost all of its records in a fire / etc. 4) Your sole documentation is the dogeared paper copy describing file formats for their sole input method, CSV files, which was current as of its publication date, before you were born. 5) Your sole documentation incorporates by reference four other documents which, ahem, yeah. 6) You have a working test suite which accurately models the production system in all respects. It is the production system. Please do not run the equivalent of Accounts.all.delete when cleaning up from your test runs. (The system won't stop you from trying to do that. No, really.) 7) Praise God, there is actually a bridge between the mainframe system and the Internet, so at least you don't have to reverse engineer wire protocols. It was coded in 1996 by IBM's crack team of integration engineers. This will give you an excellent opportunity to brush up on your Java 3.4.1. It speaks REST/JSON, as long as as you spell REST/JSON "XML". Good news, though: your time spent learning the CSV file format won't be wasted, since the XML is just a straight mapping to it. Except for the four bugs in the mapping, which are dutifully recorded in a database in Hyderabad whose existence will be exposed to you 8 months into the project. Welcome to legacy integration! We hope you enjoy your stay.

incision 13y ago
Anecdotally, what's described here would actually be unrealistically optimistic given the context of Government where I have entirely too much experience. First, you can forget about having documentation of any kind or anything as recent as XML. Also... 8) Nearly everyone you need to interface with on the customer side is apathetic at best. More likely, they are plain adversarial for fear that the work you're doing will eliminate their jobs. A single person can plop themselves in your critical path and refuse to cooperate - millions of dollars or public safety be dammed - there is nothing you can do other than work around them. 9) You will need to coordinate with half a dozen other subs under the contract prime. Some of those subs will be unassailable due to pre-existing relationships. Others will depend on talent with a 10 hour time difference. One will suddenly be in charge of "testing" your code in order to generate more billable hours. You will be in a constant battle to avoid being used and abused by the prime to make up for the deficiencies of other subs.

sanderjd 13y ago

This may be the most hubristic comment I've ever read. No, you could not "make Postgres do what is needed for this within a week or two" just because you've heard of REST and JSON.