The Federal Enterprise Architecture A Way Ahead on Information Sharing

1. The Federal Enterprise ArchitectureA Way Ahead on Information Sharing Bryan Aucoin Chief Technical Officer Enterra Solutions baucoin@enterrasolutions.com

2. Agenda • Background • Some Core Concepts • A Way Ahead

3. First, Some Background • The DRM 2.0 Team did an analysis of: • The types of repositories that people generally build to store data, and • The types of services that architectures should consider to enable information sharing

4. Basic Data Sharing Conceptsin the FEA DRM: • Services provisioned depends on the type of data being exchanged. • Data Sharing Services Types: • Data Exchange • Data Access

5. Basic Data Sharing Concepts:Provision Services for Data • Types of Data Exchange Services: • Extract/Transform/Load • Publication • Entity/Relationship Extraction • Document Translation • Types of Data Access Services • Context Awareness • Structural Awareness • Transactional Services • Data Query • Content Search and Discovery • Retrieval, Subscription and Notification

6. Today’s World • Is built around network enclaves • Enclaves contain entire application stack. • The Internet is used as transport between enclaves. • Enclaves are protected by a DMZ • Portals, and an increasing number of services exposed through the enclave DMZs

7. One Emerging View… . . . Segregation of Services Shared Services Enclave(s) Shared Transport(s) • Web & Web Service Interfaces • Access managed at the enclave boundary Data Enclaves

8. The Way Ahead:Understand that there are three categories of data within the DRM and different rules apply to each. • Context: • e.g., stewardship assignments,entities of interest,subject areas of interest,source of record,source of reference,access management policy, etc. • Content: • The actual data within the repository • Structure: • Semantic Description • Syntactic Description

9. The Way Ahead:Understand that a small number of access policies are generally needed for any given data operation. • Open: • No restrictions to the data. • Group: • Access is granted based on presence in a group • Named Access: • Access to a specific object is based on presence in a list • Access = f (user, data object, environment) • Self Protecting Data • e.g., Digital Rights Management Note: For the architects and engineers out there, item 4 is probably the “canonical” representation of all of these. However, policy for data is defined within Communities of Interest by stewards. Stewards are generally business people, and we have to speak in their language.

10. The Way Ahead:Some thumb rules: • Context: In general: • Open read • Group write • Content: • Depends on the DRM Quadrant • For Analytical Repositories, generally group based access is good enough. • For Transactional Repository, access is generally managed by the application or service. • Structure: • Generally follows Content

11. The Way Ahead:On to Services: Policy Decision/ Enforcement • Longer Haul: Here are the things that become important in big information sharing networks: • A common approach to identities and identity management • A common approach to access policy definition and representation • A common set of patterns and approaches to provisioning data services. • Common approaches to representation of Context, Content and Structure. • Short Haul: • There’s plenty of • Low Hanging Fruit • Slow, Fat Rabbits • Posting open access context information on a public website is a good thing. • Next Steps for the DRM Community • Find Best Practices for these things • We’ll discuss some prospects today Service Request Containing an Identity Access Policy Defined by the Steward

12. The Way Ahead:Don’t forget the governance pillar! • The reference model management process will drive changes to the DRM. • What the Data Architecture Subcommittee is hearing from the Federal Community is: • Help us share best practices • Work with us to build actionable guidance on DRM 2.0 implementation • We need to forge the linkages.