Welcome Login

For current information from GSA about COVID19 please click HERE

You are here

IAE Frequently Asked Questions (FAQs)

Please find below the Integrated Award Environment's (IAE) most Frequently Asked Questions. Questions are asked and answered pertaining to IAE's industry outreach events, documentation locations and links, overall business policies, and general questions as well.

You can submit questions you would like answered and added to this always-growing list by emailing us at IAEOutreach@gsa.gov.

- The IAE Staff


Presentation Documentation FAQs


1. Q. Are the presentations and documentation from Industry Day events available online?

A. Yes, you can find the materials on Interact at the following locations:


2. Q. Could you email the Meeting Space chat log to the group?

A. We include all of the questions entered into the chat log by the group attendees in the Question and Answer session.


3. Q. What is the best way to find out about changes? Through the Interact environment? Can you detail what has already been rolled out?


A. The IAE Industry Community on GSA Interact is and will remain the primary source for IAE stakeholders to find the latest published information about the IAE organization and the development of the SAM environment. In FY15, IAE focused on creating the Common Services Platform, the architectural foundation on which the award environment will be built and hosted. System roll-outs will begin in FY16. Information about the IAE Common Services Platform can be found here.



General Development FAQs

1. Q: What is the y scale unit on slides seven and eight of the presentation deck?

A: The graphs shown on slides seven and eight in the Industry Meeting 4-07-14 presentation (available on interact.gsa.gov) are normalized to show the maximum value as one (1). Our primary interest here is not to show absolute sizing, but the variability of system usage over the course of months, weeks, and days.


2. Q: Do you have measurement of Help Desk call volume that has been adjusted to remove the 2013 excess demand that occurred during the initial SAM implementation?

A: The first quarter figures on the graph on slide seven of the Industry Meeting 4-07-14 presentation were influenced by the initial SAM rollout. However, a significant design goal of the new IAE environment is to ensure that similar unplanned traffic spikes do not affect system integrity or availability. As such the figures as presented do represent demand profiles that the final solution may need to support. Please note that providing an end-user Help Desk is not part of the technical scope being discussed. The Help Desk call figures are provided as a readily understandable metric to illustrate the fluctuating level of user interaction throughout the year. Even as SAM has stabilized, we see significantly higher volume of system and help desk usage in the latter part of the fiscal year. The Common Services vendor will need to account for the variance of demand across the year in a manner most cost-effective for the government.


3. Q: Can you expand your thoughts on prototypes?

A: The refinement and decomposition of Backlog items is anticipated to be separate from the Sprint - and to some extent Release - level planning done by individual teams. The Government, in conjunction with the Technical Governance Support Contractor, will manage the overall Backlog refinement process. One tool that may be employed at the Feature level may be prototypes but it is likely that those created during Backlog refinement will be low-fidelity. Contractors and development teams will control how prototyping and other development activities are handled within individual Release and Sprints. For example, higher fidelity prototypes may be developed as part of an R&D spike.


4. Q: Do you consider prototypes to be separate sprints?

A: Details on individual sprints will be left to the Common Services and Core Development teams.


5. Q: Why separate the Common Services and the Core Development development teams?

A: From a practical perspective, the graphic shown on Slide 15 of the Industry Meeting 4-07-14 presentation, is intended to show a Common Services Contractor perspective on the IAE operating environment. A requirement of the IAE environment is that the Common Services Contractor must be able to work with multiple teams, including development teams from other contractors (tasked with building specific business functionality required by IAE) as well as other entities who may provide code that is subsumed into the IAE code baseline. The Industry Day scheduled for April 29th will examine in more detail the relationship between individual development groups.


6. Q: Will the Common Services development be completed prior to the Core Development engagement?

A: The Common Services activities will create a platform for other capabilities. The first of the common services capabilities will be delivered before the core development begins. After that initial delivery, the development teams will work in parallel. The upcoming Industry Day on April 29 will have more details.


7. Q: What is the expectation for moving existing accounts to the new common environment?

A: This is yet to be determined. Proposed architectural solutions likely will drive these kinds of technical decisions. However, it is expected that migrations will maintain and improve data quality and will result in minimal disruptions to user activity in IAE systems. This means that the government will want to consolidate user bases across the systems and information across the existing systems as much as possible without significant negative effects to the user experience.


8. Q: Will the pre-production development and test environments be the responsibility of the Common Services contractor?

A: The ‘production environment’ and the ‘other managed environments’ will be provided and managed by the Common Services contractor (see slide 15 of the Industry Meeting 4-07-14 presentation at interact.gsa.gov). Unmanaged environments will be provided by individual development teams. There will be more about this during the next Industry Day on April 29.


9. Q: How frequently will you release code?

A: We anticipate that code and related assets will be published at the end of every development sprint. We currently are targeting two-weeks sprints.


10. Q: How will the programs openness affect your interaction with other agencies?

A: We intend that our openness will facilitate our interaction with the agency users; they should be able to take advantage of openness to ensure improved integration with IAE, greater awareness of change, and improved access to tools which can be leveraged across the government.


11. Q: When you will publish the first materials as part of the Transparency Initiative?

A: The current series of industry days are part of the Transparency activity and first materials to be published are already available at interact.gsa.gov. Over the coming months you will see a gradual increase in the breadth and sophistication of the materials available as the program matures its processes.


12. Q: How do you see the governance of who/when/how users will use the API's?

A: IAE already operates a number of APIs. Private write APIs exist to connect IAE systems to contract writing systems used by the CFO Act Agencies and read APIs are available both publicly, for example the FPDS Atom feed, and privately for specific intra-government data transfers. The governance that is already in place for these APIs will be expanded to support a broader range of systems and organizations. The IAE program is in the early stages of establishing these expanded procedures for managing and approving access to APIs. In particular allowing individual external organizations write access is actively under consideration, for example, to allow creation or update of an entity registration. The scope of responsibilities of the Common Services contractor include ‘API Management’. This activity includes reviewing applications for API keys, forwarding requests to the government for approval, monitoring usage patterns of individual key owners and monitoring overall usage of IAE APIs.


13. Q: Will there be a draft SOW/PWS released for the Common Services and Technical Governance opportunities?

A: At this time the government does not have an update on the acquisition timeline.


14. Q: Can you expand your thoughts about protecting and ensuring the fundamental quality of the data itself; will the data be correct, complete, or consistent?

A: An important element of building trust with our customers and partners is to help all parties understand both the syntax and the semantics around the data. Some - but of course not all - concerns about data quality can be traced to misunderstandings around what the data actually means and attempts to use it to describe things that it was not intended to cover. Our Transparency work is part of a long-running activity to understand the data and to connect producers and consumers of that data to maximize the value both derive from it.

Much of the work IAE has to do around data management is to establish the constraints which define what “quality” means within IAE and assure users that we are meeting that definition.

Specific successes to date in the area of data quality include improvements throughout the SAM by enforcing the requirement that all registrants interested in contracts with the federal government provide representations and certifications; this was not true in CCR and ORCA. Further, we have established improved data checks across the system to ensure validity of the data. However, we still are maturing to allow for deeper discussions about what data quality in IAE means.


15. Q: Could developers have access to the same tests that GSA is using?

A: Yes. We anticipate publishing everything related to the application including the source code, infrastructure configuration scripts or recipes, defects, commit logs and automated tests. It is our goal to be able to push all the automated tests including the load testing scripts to allow third parties to run a full suite of tests if desired.


16. Q: Could you please define who makes up the group of people or entities that you consider "third party" and who will control the value and contribution made by 3rd party organizations?

A: Third Parties are any group not specifically contracted by IAE and might include private individual, universities, companies, non-government organizations or other government agencies. Some of these groups may be interested specifically in the code base of IAE, for example a university could use the code base as a case study in computer science. Other Third Parties may be consumers of IAE data, or may have the ability to submit write transactions through IAE APIs. Third Parties may also be organizations involved in data standardization activities or private citizens who have an interest in the progress of IAE. The Third Parties need not be providing direct value to IAE. However, if they wish to submit pull requests that would add capability to IAE, those requests would be evaluated within the context of IAE’s governance, security, and any other obligations the program needs to meet.


17. Q: While the IAE is being developed, could GSA provide a simulated API so that developers can start writing and testing their code earlier rather than waiting for the IAE to be finished.

A: The provision of publicly available test APIs is being considered and would fall under the API Management activity described in the Common Services process diagram shown on slide 7, Organization and Responsibilities. As part of the Transparency activities, developers will have access to all the code that implements the government’s side of the API and, with this, developers will be able to create a test environment that meets their specific needs. In addition we will provide access to both the requirement backlog and defect lists to allow vendors to understand planned changes and functional weaknesses within the code base. We are also considering allowing public submission of defects on the government maintained code base to allow third parties to identify deficiencies in the code base.


18. Q: Who is the new IAE Transparency Champion?

A: Ilias Panagopoulos joined IAE in May, 2014 as the Transparency Champion.


19. Q: Do you intend to use a core developer to modernize these systems?

A: The architecture presented at various industry days includes both a Common Services component and individual "cores" that represent areas of business functions. The three cores are pre-award, post-award, and entity management. Functionality built on these cores will be developed independent from the existing applications that form the portfolio of IAE managed applications. The three cores represent a high-level partitioning of business functions, and does not imply either that there will be three vendors nor one developer responsible for solution design and development.


20. Q: Do you intend to modernize eSRS and FSRS before migration to the core services platform in Spring 2015?

A: Work is ongoing to maintain the existing applications while the program moves forward with the new application and technical architecture.


21. Q: Are ACE, FACE, and PCE government-wide committees?

A: Yes, the ACE, FACE, and PCE are government wide. You can find more information concerning the ACE on the Chief Acquisition Officers Council website at: https://cao.gov/award-committee-for-e-government/.


22. Q: Is there a target date for when IAE is to come online?

A: The Integrated Award Environment (IAE) is an Office within the Federal Acquisition Service (FAS), which in turn is part of GSA. IAE is not itself an application, but the program office that manages a portfolio of individual systems that collectively provide acquisition assistance by the federal government. A complete list of the acquisition systems can be found at www.gsa.gov/iae.


23. Q: Can you point us to the SAM API link for more information?

A: You can find more information on the SAM API on GitHub at http://gsa.github.io/sam_api/sam/. In addition, there are many other GSA repositories available on GitHub at https://github.com/gsa.


24. Q. Will users be using GitHub to update out SAM information moving forward? Will this hub replace SAM, FPDS, etc.?

A. GitHub is being used as a tool specifically to support communication between the IAE program and the technical community. GitHub is not intended for non-technical audiences and its use is separate from the end-user services that IAE provides through sites such as fbo.gov and fpds.gov.

Artifacts produced by the IAE Program such as the SAM API, FDPS data and interface documentation, architecture and eventually code will all be available on GitHub, along with information that will allow the technical community to understand, use, comment on and contribute to the quality of these artifacts.


25. Q. FPDS data has historically been inaccurate. Is anything being done to ensure that the data pulled from FPDS is more accurate?

A. The program is progressing many activities related to data quality. We are addressing this through a number of on-going initiatives including:

  • Participation in government wide data standardization activities

  • Engagement with data providers, including the contract writing system vendors, Contracting Officers and the agencies and organizations that they work for, to address technical and procedural changes that can improve data quality

  • Education and outreach to users of FPDS, and more generally IAE, to assist in understanding the limits of FDPS data and how it can be and should not be used.


26. Q. Will confidential data about firms in SAM be maintained? For example, we have been told to protect our CAGE code as that is how we are paid, etc.

A. openIAE does not change IAE’s policy on maintaining the confidentiality of information stored within the IAE systems. openIAE’s focus is on making accessible to a technical community code, design and other related artifacts that make up the IAE systems.

We recognized early on that there is a balance to be struck between openness, security and confidentiality and we have implemented, and are continuing to mature, a set of internal controls that define both the policy and the practical steps to be taken when determining whether a particular artifact should be released. These controls are designed to ensure a consistent application of the program’s confidentiality and security commitments.


27. Q. Is GitHub for use by the general public?

A. GitHub is a commercial tool that is used by government, commercial groups and private individuals. openIAE embraces GitHub because it is the best platform available for social collaboration on code and code related artifacts while allowing equal access to any group, organization or individual who wishes to engage with the IAE program on that code base.


28. Q. What components of the conceptual architecture were released in your first release?

A. The hosting, I&AM, data lake, continuous integration tools, and security controls were delivered in the first release.


29. Q. Will FSRS be designed to record project data that are not funded with capitalization grant funds?

A. This will be determined as we work on focus groups with FSRS users; additionally, IAE develops its applications to comply with policy so any changes will also be aligned with policy as we consider adding new data elements.


30. Q. When will third party developers, part of the IAE ecosystem, be able to start developing their own applications against GSA's targeted IAE service ---- or a simulated or a "virtualized" targeted IAE service?

A. We expect to make this functionality available to third party developers in June 2015.


31. Q. Has the Common Services platform met all of their deliverables so that the Core Development procurement will be on time?

A. Yes, we are currently on time or ahead of schedule with delivery.


32. Q. While there has been significant discussion regarding high level objectives, I’ve seen comparatively little discussion regarding what is arguably the most import component of the system: the validity, accuracy and the consistency of the actual data within the system. What specific steps are GSA taking toward achieving complete and reliable data?

A. Data quality is a high priority and we are taking steps to make data quality issues visible, traceable, and easy to correct in our systems. Our intent is to be known for having high quality data - this is a major goal for the new award environment. We don’t own the data and still rely on our system users to support our aims and contribute to the goal of complete and accurate data. We collectively as a federal award community have an opportunity with the new award environment to make great improvements in this area. We have received a lot of input from our user community about this issue. We value this feedback and encourage people to continue to provide suggestions and concerns - because drawing attention to this area helps all of us contribute to a better award environment.


Depending on which application we are talking about, the sources of the data quality issues are different. Based on input we have received already, we are currently taking action on the following contributors to data quality issues:

  • There are policies that affect what we collect and how. We have identified policy-related issues and have started working with policy makers on long term solutions to make sure the meaning, purpose, and use of what we are collecting is clear and that our collection practices support the intent and meet the goals of the applications.

  • We have identified logic and features to the system to identify incomplete (missing) data and who is responsible for providing it - and support to keep people informed of what must be submitted and when.

  • We are improving and streamlining the data entry process (providing better validation of both format and content, making it easier to identify and correct errors, auto-populating more data fields, and making other improvements).

  • We are consolidating and improving the search process through modernized technology, rigorous testing and data model validation, and simpler, more complete search features.

  • We are updating data entry templates, in some cases to “treat data like data,” replacing text fields with appropriate numeric or other field types.

  • We have identified some of the key problematic fields, such as financial and location/geographic information, to dedicate additional effort to resolving.


33. Q. Are you planning to share the complete personas?

A. We are currently creating a strategy for keeping externally published personas up to date with our internally published personas as they continuously evolve. We have internally published personas as part of our team’s enterprise knowledge management system (Confluence). Once we have a process in place for keeping the external versions aligned with our working versions, we will post them online (likely using Interact). Please check back on Interact in early FY16.


34. Q. Did I hear you were creating a persona for a contract writing system?

A. We are creating a persona to represent external systems which connect with IAE systems. Contract writing systems will play a large role in shaping this persona. We would like to hear what system integrators need from our environment. If you would like to provide input to this persona (or recommend someone else to provide input), please contact our outreach team at IAEoutreach@gsa.gov.


35. Q. When will the Activity Address Code (AAC) changes to FPDS-NG be rolled out? We have not heard anything official since it has been postponed.


A. Below is the AAC schedule, planned to go to FPDS production on 4/1/2016.

Task Description




Development period (In Progress)




Setup Module (Complete)




Module 1 (In Progress)

Validating architecture/ Web Service implementation




Module 2 –

Application changes and initial linking of historical offices to AACs



Module 3-

Linking historical offices to AACs



Module 4 –

Open issues, Documentation/Report updates, etc.



Deployment to Beta



IBM regression testing



Agency validation of office codes



CWS Testing



GAT Testing



IBM fixes issues reported through GAT



Retesting of issues reported



Deployment to Production




35. Q. How about the user experience based on application response times?

A. We are designing our capabilities so we can adjust performance profiles in a flexible way; further, our geographic separation of cloud implementation will aid us in providing consistent service across the country. It will be key that we define our response time requirements as part of our story acceptance criteria as the applications are developed.


36. Q. Is the tentative rollout date of the new environment still 2016?

A. The IAE Product Roadmap explains the tentative rollout date of the new environment.


37. Q. Will the user personals be applied to any development activities in the existing systems?

A. The personas were created specifically for the new environment and don’t align well with the current and legacy systems. We found that capturing and sharing an understanding among IAE of people's’ future use of the integrated environment is of higher value than a focus on current system use cases. The personas drive high-level strategic and tactical decisions as well as application functionality design, and most of the changes to the legacy systems are specific in nature and inapplicable to the redesign of the award environment.


38. Q. Is the core platform considered IAE or SAM?

A. IAE is the name of our organization within GSA. The IAE maintains the current systems and is developing the future environment. The platform in which all the IAE systems will be integrated will be called SAM. During the transition from ten systems to one environment, the entity registration and management system SAM.gov will remain SAM.gov, while the future award environment will be hosted on the platform transition.SAM.gov.


39. Q. What are general timelines for the existing applications?


A. The IAE Product Roadmap explains the tentative rollout date of the new environment.


39. Q. How are various user identities managed?

A. First, we want to emphasize the importance and role of our raw data library - our organized documentation of what people have said, including verbatim words people have written and our notes of conversations that took place. Our user analysis team, requirements analysts, product owners, and user experience team all recognize the importance of being able to ground our work in the stories people have told us and the requests they have made. We have a team of professionals who know how to take that kind of input, apply best practices, and build a polished, streamlined solution; but everything (from our policy recommendations to application features and priorities) is grounded in our collection of raw data.


We store our user identities (personas) internally using Confluence. This enables the entire team to access them as web-pages (with links other user analysis, journey maps, and raw data), allowing us to link JIRA tickets with personas, journey maps, and other user analysis. We can update personas as our understanding evolves and to have version control. We have PDF versions we can distribute externally and hallway posters, though updates to those are not as immediate.


Our user identities are based on our raw data and are managed leveraging our understanding of Scaled Agile - so we do different things at different levels.


  • When we look across the whole environment (the strategic or portfolio level of Scaled Agile), we have our personas. They are very broad and represent people (and sometimes whole institutions) who touch multiple systems. These personas communicate who we are considering in driving the environment; they provide names and faces to add an emotional component; and they summarize the most important goals across a wide group of people. They help us center and scope our applications and recognize strategic areas where we can provide the most value.

  • When we look at how to implement various capabilities or features (such as searching for a financial assistance program), we identify the persona that should drive it (in this case Financial Assistance Recipient), and we often have to go deeper into that persona. The Financial Assistance Recipient persona represents a variety of people and institutions and we have to focus in on a particular aspect of the persona, depending on the feature we are building. For our “searching” example, we would give heavy consideration to a story we heard about a community looking for federal assistance to build a health care center. For our FFATA reporting capabilities, we are also using the Financial Assistance Recipient persona but in this case we will give perspective of state governments a lot of influence.

  • At the team level, when we are detailing how our features will work, our user interface standards play a key role. Because we are trying to create consistency across the environment and create a fluid experience, industry best practices substantially influence our user interface. We do identify one to three personas to validate user interface decisions.


While the above description provides a general approach to managing our user identities, there are always exceptions we have to consider as well.


39. Q. Is it up to each agency on how their individual contract writing system interacts with IAE?

A. Yes. We will continue to support legacy interfaces in the interim and, similar to our planning around transition between SAM Extract formats, we will coordinate with agencies to transition between data interfaces as necessary.


Technical FAQs


1. Q: Are you expecting to meet any of the NIST 800-53 set of security controls with the goal of getting the infrastructure FedRAMP certified?

A: We expect to leverage an existing JAB or agency FedRAMP ATO and do not anticipate completing an infrastructure level ATO.


2. Q: Do you believe the concept being presented is in alignment with TOGAF?

A: The goal is to provide an architectural documentation that is consistent with TOGAF, but there is no specific requirement for it to be “TOGAF compliant”.


3. Q: Do you require any specific form of business process execution language?

A: The government is looking for the most appropriate design and implementation that best balances the Architectural Principles and will not specify or constrain particular technical solutions.


4. Q: What are the requirements for disaster recovery?

A: The hosting solution must be able, on an on-going basis, to accommodate multiple production-like environments, including short-lived environments that will support penetration or load testing. The hosting solution must also be able to accommodate the normal calendar and clock-driven end-user demand profiles. A ‘disaster recovery’ environment is not a requirement, but rather a choice that a contractor must make in determining how to cost effectively achieve the needs for availability, sustainability, demand, RTO, and RPO.


5. Q: Will new code be required for each container or will they contain existing OOTB technology?

A: The containers are conceptual entities that allow technical capabilities (Nodes) to be deployed in different ways depending on particular needs. A production container may be implemented on FedRAMP compliant infrastructure, while a developer may deploy the same functionality in a ‘component’ container running on a virtual machine hosted on a laptop. These deployments are expected to be click-and-install using stack definitions or recipes. We expect that the development teams will build these functional capabilities leveraging a mixture of COTS and new code. Each functional component (node) will contain the intelligence to automatically adapt its configuration depending on the container into which a functional capability is deployed.


6. Q: Do you envision a data warehouse supporting the underlying query/report loads and/or "BI bubble" within the starship enterprise?

A: The Common Services scope of work provides technical capabilities to implement business functions. No specific business functions have yet been presented, so the business related requirements that may require a data warehouse are still pending. However, within the scope of the Common Services there are clearly requirements for bulk data capture, processing and presentation. The technical solution for this can be proposed by vendors. It should be noted that the containerization model any such capability needs to be available as part of all the environments.


7. Q: Do you plan on utilizing existing infrastructure owned by GSA?

A: IAE intends to use the existing infrastructure to continue supporting the legacy environments as necessary. However, the long-term plan is to transition away from significant reliance on that hardware to the containerized model; the implementation of this will need to support environments that can be created or torn down at-will, including the production environment.


8. Q: How does GSA plan to handle scalability within its architecture?

A: The best solutions will adhere closely to the architectural principles we discussed during the April 7 presentation. The government seeks a solution that is demand driven, deploying and paying only for the resources that are required, when they are required. There are many examples of demand driven implementations, including "spot pricing" for resources, video transcription services that charge by the minutes, image manipulation services that charge by the image and messaging services that charge by the minute for worker processes that respond to incoming messages. It is also worth noting that our "everything is a service" model should abstract the physical implementation of the architecture from the service that they provide. This opens up the possibility that the physical product that implements a technical function is different depending on the specific container into which it is being deployed.


9. Q: Is using a Master Data Management approach for organizations a part of the scope?

A: Yes, MDM is a critical part of our approach to treating data as an asset within IAE.


10. Q: Is OpenSchema support expected to support change in version to data schema, so old data does not need migration?

A: The specific technologies and approaches towards implementing both migration of data and support of the underlying environment are to be proposed by vendors interested in Common Services. It should be noted that vendors should consider that some of these legacy systems may be sunset over time, which would necessitate migration of the data. Furthermore, as data quality and data integration across what are currently silos is a focus of IAE’s goals, any maintenance of legacy capability needs to be weighed against those needs.


11. Q: Will the CI process include testing of 3rd party code to ensure that new releases don't break backwards compatibility with industry contributed code?

A: All code incorporated into the IAE common code repository will be maintained and supported by the government, no matter where the code originated. It is worth noting however that all code included within the common code repository must meet government quality thresholds which will include appropriate automated tests. Pull requests will be rejected if all the necessary components including adequate documentation and testing are not included.


As part of the Transparency activity the government will provide the complete testing environment as part of the publicly available code assets. For external organizations that develop and maintain code that is tightly integrated with the IAE code base, we will publish these code updates to the public repository at least at the end of every 2-week sprint. With a quarterly release schedule, third parties will be able to get approximately 12 intermediate builds to examine and test with their code prior to actual production deployment of a new release of IAE code.


12. Q: Are we still looking at the USPS's FCCX Identity Access Management as a viable cloud solution?

A: IAE is following the progress of the FCCX program and other similar initiatives with interest. The IAE PMO looks to the Common Services contractor to identify innovative solutions to address the short and long term needs of IAE.


13. Q: What is UI?

A: UI is User Interface, the component of a computer system that the user interacts with. Please find a definition here: http://en.wikipedia.org/wiki/User_interface


14. Q. Will GSA restrict a developer's access to the common services platform (CSP) by time of day, by amount of data used, etc?

A. The developers will not be limited by time of day, but they will be limited by usage.


15. Q. How do you see the core developer interacting with the CSP provider?

A. As described in the meeting, the core developer will use the CSP-provided marketplace to select components they need; they will use the containers designed and secured by the GSA and the CSP provider; and they will use the GSA-defined workflow processes to move their applications through the different environments within IAE. The IV&V/DevOps contractor will ensure that the Core developers’ tests are appropriate and provide functional coverage, and that they have been executed in the appropriate automation. The Core developer will not be responsible for deploying their application into production, but they will be responsible for ensuring their application can be deployed and meeting the quality standards that are set by GSA.


16. Q. How are APIs being protected and managed?

A. The APIs will be protected through a combination of API keys which will be assigned at an application level and the use of our identity and access management solution using an OAuth2 implementation for securing access to data at a user level. The combination will allow IAE to control which applications would have rights to, for example, write vendor data into our entity management solution. But it would further then ensure that access to individual entity data is controlled such that user access is controlled appropriately.


17. Q. Are the APIs going to be available for testing at the same time that beta UI testing is available?

A. Yes. As we are expressing an API-first implementation for our applications, we will be releasing the APIs concurrently with the applications.


18. Q. Please provide the specific link to the timelines of API changes and availability. I was not able to find anything concrete on the Interact website. As a CWS, we need to track this closely so our system can be integrated in the new site.

A. The APIs will be released concurrently with their applications; thus we expect to launch data interfaces quarterly in parallel with the applications which manage their data.



19. Q. In both the current and future stages, can the user manage their identities via self-service to help themselves and take the most of the burden away from GSA?

A. Permissions and roles is another area where we have received a lot of user input. Non-federal users, who currently have less capability in this area, have especially shown a lot of interest in having flexibility and more control over who can do what, how they manage their data, and how they deal with organizational changes (individuals moving and complete reorganizations). This is an area where we recognize, based on what we have heard, that we can have a lot of impact by executing well. The improvements will be incremental, but our intent is to provide our users as much control over their information as possible (subject to policy and security constraints). As we are developing and rolling out capabilities, user input will be critical to making sure we are meeting needs. If you would like to provide early feedback as functionality is being developed, please contact us at IAEoutreach@gsa.gov.


20. Q. Will one of the services already in the IAE PaaS be the underlying datasets of the systems listed? Or will developers essentially need to work with IAE directly to get access of the data? If the data will become available partially, is there a roadmap or prioritization of which data will be available as a service first, second, etc.

A. Public data will be available via APIs that do not require any direct intervention with IAE to get access to. The roadmap, at this point, is considered acquisition sensitive, so we will not yet release it.


21. Q. What about debugging?


A. For Java, debugging is available through configuration supported in most IDEs.


22. Q. How would it [the data lake] be connected to Data.gov?


A. The APIs fed from the data lake will be published on data.gov.


23. Q. You demonstrated the development of an interface; does the capability exist to develop a web service where IAE data can be consumed by my application?

A. Yes. That would just another type of application.



24. Q. Will IAE set standards on certain design elements? For example, adopting a baseline on the US web Design Standards?


A. The baseline is the CIO US Web Design Standards.


25. Q. Will the APIs for existing applications will still work? How will that be folded into the sprints? How do we know when we can test the use of the existing APIs?

A. We will be publishing alpha and beta releases quarterly. Feedback about these releases from users will be solicited on the openIAE site on GitHub.


26. Q. How is health of the apps monitored?


A. We will have a number of capabilities, for example an ELK stack for logging, the Simian Army and others which will support the monitoring and active management of the applications in operations.


27. Q. Will of of this be ready and available as part of the FBO and FPDS modernizations? Will the REST style capabilities be included as part of the timeline?

A. Yes. We are developing API-first.


Award Timeline FAQs

1. Q: When will the Common Services contract be awarded?

A: GSA expects to award the Common Services contract in FY 2014.


2. Q: When will the Technical Governance contract be awarded?

A: GSA expects to award the Technical Governance contract in FY 2014, almost concurrently with the Common Services contract.


3. Q: When will the DevOps/IV&V contract be awarded?

A: GSA anticipates that the DevOps/IV&V contract will be awarded in early FY 2015.


4. Q: You stated that the DevOps/IV&V contract is about to be awarded. Can you please clarify if and how the solicitation has been released for this requirement?

A. The solicitation was released in February 2015 via eBuy.


5. Q: What is the timeline for FPDS-NG modernization?

A. The FPDS-NG modernization will occur during three different releases in 2016. These releases are scheduled from May 2016 to November 2016.


Views: 1442

The Integrated Award Environment (IAE) is a government-wide initiative administered by GSA’s Federal Acquisition Service (FAS). We manage the suite... More

To stay informed on the group's latest updates, subscribe here.

  • kungfuai's picture
  • amheller's picture
  • tcox912's picture