- 3.Data: (3CJK)
- a. What are data services? (3CJL)
- Data services provide the means for business and application logic to access and change data in underlying repositories to support of businesses processes and functions. (3CJM)
- The FEA DRM delineates a set of services that architect should consider as they work so support business needs of their respective organizations. They include components such as: (3CJN)
- We have say what we mean by “SOA”. There are multiple correct definitions: (3CJU)
- Services may be broad, aggregate services like PERFORM RECRUITMENT. (3CJV)
- Another correct definition involves implementation of a capability in accordance with an architectural framework such as J2EE, W3C, OASIS, etc. (3CJW)
- The challenge for the architect is to determine which of the DRM delineated specified services are required to implement the broad, aggregate services required by his/her business. (3CJX)
- b. How does SOA make data services more agile? (3CJY)
- Data services will not by themselves increase agility. Organizations across the government are building in more or less consistent ways. N-tiered architecture: browser|web server|app server|data layer. Yet even when we build in accordance with this shared conceptual construct, we do not have interoperable services or data. We have to resolve to mediation, which in the long haul, increases complexity, not reduces it. (3CJZ)
- The trick is to come up with a common set of agree upon specifications/conceptual frameworks that provide that interoperability. The DRM gives us a high level framework. We need to take it to the next level of detail. (3CK0)
- Recognize the search engine have added huge value, but they are not the “end-all”, “be all”. We need to address the issues of data and privacy protection. Three key elements are needed to make data services work in this context: (3CK1)
- Data services specifications (3CK2)
- Common identities and identity management (3CK3)
- Common policy and policy management constructs. (3CK4)
- c. What is the role of standards organizations? (3CK5)
- In some ways, we’ve had about as much help as we can stand from standards organizations. As I mentioned, we have a vast number of different ways to build the same sorts of things in non-interoperable ways, all in compliance with standards. (3CK6)
- If we, the Federal Community, want interoperable data services, then we, the Federal Community, have to build a shared set of data services specifications. This a brassy statement, but there’s laws of physics involved here. (3CK7)
- d. What can and should be piloted? (3CK8)
- Interoperable data services specifications. (3CK9)
- The IC has developed a set of IC data services specifications that we belief have a low barrier to entry and are vendor independent. We’ve built them to align with the DRM. (3CKA)
- IF we can agree on a common governance construct at the Federal level, I believe the IC would want to give control of the specifications away. (Over to Roy) (3CKB)
- We are piloting. We would invite others. (3CKC)
- e. What is the AIC Data Architecture Subcommittee planning to do? (3CKD)
- The DAS has a number of working groups focused on data governance, XML Schema Interoperability. (3CKE)
- We have been working closely with Kshemendra Paul on NIEM, and both Kshemendra Paul and George Thomas on the SOA specifications. (3CKF)
- The key question from the DAS: Context! We will begin an effort to define the subject areas and entities of interest to be used to categorize federal data. (3CKG)
