Provide Required Technical Documentation

[mheadd]

In Section 3.01, the scope of work references documentation for accessing data in the ORCA system. This is likely a new document(s) that will describe the desired data access method.

[randyhart]

@waldoj I think this is one of those "tech documentation" things that we discussed at this afternoon's sprint planning.

[waldoj]

The problem here is that we don't yet know how vendors will access data in ORCA. @vrajmohan is working on that, but there's not yet a method that we can prescribe.

There's the added challenge that Vraj figuring out how to do this will surely be the easy part, compared to actually doing it. Inevitably, this is going to involve writing new methods and adding them to ORCA, then writing a REST layer atop that, then setting up access via the ESB. My hope is that we can do those two things in parallel. Much like writing the tests before writing the software, we can document how the REST interface will work (what a request looks like, what a response looks like), and while the procurement process is underway, DHSS IT staff can work on creating that infrastructure.

So that documentation will need to be a Markdown document on GitHub, and we should anticipate making constant changes to it, as internal development proceeds, to help potential bidders / bidders / the vendor understand the state of that work.

[mheadd]

This is also an issue that Joe will encounter as he continues working on the prototype.

[DanaPenner]

Simon to approve draft

[sztaylorakgov]

Just so I am clear, the link above points to language in section 3.01 that states:

The State of Alaska, Office of Children’s Services (OCS) requires agile developer services to deliver iterations of a secure system allowing mobile access to the states comprehensive data system, the Online Resource for the Children of Alaska (ORCA). The current objectives of the mobility piece are identified above in Section 2.01: Background Information. The State of Alaska will provide documentation on how to access data sources, describe existing authentication systems, and discuss how to deploy work to a staging environment This documentation is intended to be help interested vendors further understand the limits of their responsibility within the broader scope of ORCA.

Is that the language you are asking me to review and approve @DanaPenner ? Sorry if I'm not tracking well enough on this one.

[DanaPenner]

Eep apologies for the lack of detail @sztaylorakgov. I believe this document you are to review/approve is still in the works. Is that what you recall from today's meeting @mheadd, @randyhart ?

[sztaylorakgov]

@DanaPenner No worries! If I make a few more standups per week, I'll probably know what's going on 🤷‍♂️

[mheadd]

@DanaPenner @sztaylorakgov The section in the RFP linked above includes the language will provide documentation on how to access data sources. For the DPA procurement, this link was to a document that described prototype findings.

I was thinking that in this case, the proper target for that link might just be a link to the DHSS IT requirements doc, specifically the section on Information Exchange Architecture

https://github.com/18F/RFP-ORCA-Mobility/blob/master/5-Attachment%20A%20-%20DHSS%20IT%20Requirements%20Agile%20Acquisition.md#information-exchange-architecture

Thoughts?

[sztaylorakgov]

I think that makes sense, @mheadd. I am hoping we will also have some prototyping/de-risking documentation to point to as well for this ORCA effort. I think that material was invaluable to the DPA project.

[mheadd]

For now, I'm going to add the link note above to the RFP draft. We can add the prototyping/de-risking to the repo when we have them developed.