• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Solution Architects Working Group (SAWG)

Solution Architects Working Group (SAWG)






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Key Talking Points: Firstly, thank you for giving us the opportunity to speak at the XML Working Group Forum. Cognizant of time, I organized the presentation into three focus areas: The FEA-PMO, what it is, accomplishments and next steps High level review of the SAWG charter and objectives High level overview/main bullet points supporting Component-Based Architecture implementation – this is a key area where we feel the XML Working Group can really help us. More on that later in my presentation…
  • Key Talking Points: Basic background to why the FEA-PMO was established, our current accomplishments, and the next steps for the PMO.
  • Key Talking Points: FEA-PMO Background and Introduction Slides comments are sufficient.
  • Key Talking Points: FEA-PMO Accomplishments Creation of the Federal Business Reference Model (BRM) that identifies the business areas, business lines, and sub-functions across the Federal Government. We may want to talk through how it was validated by agencies and the new version is scheduled for release in mid July. Mark Forman cited the BRM in his June 7 th testimony to congress around HLS Creation of the SAWG w/Norman Lorentz (CTO Federal Gov’t) as the lead
  • Key Talking Points: FEA-PMO Next Steps Definition and validation of “governmentwide” reference models focusing on performance, application capabilities, and technologies/standards SAWG – provide leadership and guidance to support the E-Gov initiatives, create Intellectual Capital and establish linkages across governmentwide entities (i.e., Federal CIO Council, XML Working Group, etc)
  • Key Talking Points: SAWG We’ve shorted our 30+ page charter into a few slides that summary the SAWG leadership team, our mission, goals, and key objectives. Please feel free to stop me anytime if you have questions or comments…
  • Key Talking Points: Leadership Team/Org Chart The SAWG is staffed by some of our leading thinkers in their areas of expertise. For instance, Marion Royal is leading the charge on our XML strategy/support, while Roopangi Kadakia is provide leadership on how to host and deploy an initiative through FirstGov. As you will see, there are a number of vertical tiers, but we haven’t staffed all of them. If you are interested in helping the SAWG, please see me after the presentation.
  • Key Talking Points: SAWG’s Mission and Goals The SAWG was created with three goals in mind: 1. To help agencies and the 24 Presidential Priority E-Gov Initiatives leverage technology to satisfy business objectives and avoid duplication of efforts 2. Provide leadership and guidance in designing, selecting, and implementation their solutions. For instance, in areas of XML, are there any synergies with industry prior to developing a new schema. Or, if I need a schema supporting name and/or address, is there anything within the XML Registry that can be leveraged or expanded upon 3. Helping agencies build their initiatives using a framework supporting Component-Based Architectures – we’ll talk more about that later in the presentation
  • Key Talking Points: SAWG Objectives: Monitoring, Support, and Guidance – we want to help! We want to bring the right resources into the planning and implementation efforts. We are tightly coupled with the OMB Portfolio Managers and have setup processes to engage the SAWG. Generation of IC – we are developing a suite of intellectual capital for agency architects to leverage. While we have already released a white paper on Component-Based Architectures, we are beginning to develop materials to better assist agencies when making technology decisions. For instance – what exactly ARE Web Services, when is the right time to use them, what about the security standards? Marion and Jim are also leading a new survey that is expected to be released within the next few weeks to gain a better understanding of the technologies the initiatives are employing..
  • Key Talking Points: SAWG Objectives Architecture Assessment – gaining a better understanding of the problems and risks initiatives are faced with, to provide up-to-date experience for other initiatives to leverage. Identify and Leverage Linkages – there are several initiatives underway at this very time, how can the E-Gov initiatives leverage these capabilities. This is one of the reasons we asked Marion Royal to lead the XML charge, Tice DeYoung to lead security and authentication, etc. Also, I am meeting with Lee Holcomb later this afternoon to solidify relationships with the Federal CIO Council.
  • Key Talking Points: SAWG Objectives The SAWG is championing the specifications around how to implement a Component-Based Architecture to include the framework, tools, and processes embracing industry best practices and lessons learned. More on this later in the presentation… The Component and Services Directory is still in preliminary thinking, but it involves the XML registry, the Federal Enterprise Architecture Reference Models, and other directories to provide initiatives and agency architects with a forum that promotes reuse vs. re-build
  • Key Talking Points: SAWG Objectives We realize developing component architectures is the “holy grail” of software reuse. As such, we plan on making recommendations on training to support education and program management Communication and Outreach – As we speak, we are working on a website and set of tools to support the dissemination of expertise and collaboration amongst SAWG architects and the E-Gov communities
  • The ‘component based architectural framework’ is tier-based: Security Layer: acts more like a ‘wrapper’ that surrounds every other layer Presentation Layer: Users first access the system through a web application or an external system first accesses the system through a web service; this layer protects them from the ‘ugly details’ of the system Business Logic Layer : Contains the ‘doing’ activities (searching, filtering, computing, etc.). The components at this level should be written so that they are easily re-used within other systems. Transaction Management Layer : This layer acts as a ‘traffic cop’ between the requests from the Business Logic layer and the Information Storage layer. Ensures that requests are handled efficiently, securely, and properly. Information Storage Layer : Where all of the actual information is stored (ex. financial, information, records information, user information, etc.). Typically stored in a database or flat files.

Solution Architects Working Group (SAWG) Solution Architects Working Group (SAWG) Presentation Transcript

  • SAWG Solution Architects Working Group Overview of Mission and Objectives XML Working Group Meeting June 19, 2002 Federal Enterprise Architecture - Program Management Office (FEA-PMO)
  • Presentation Areas:
    • Federal Enterprise Architecture Program Management Office (FEA-PMO)
    • Solutions Architect Working Group (SAWG) Charter
    • Component-Based Architectures (CBA)
  • Federal Enterprise Architecture Program Management Office (FEA-PMO)
    • Background
    • Accomplishments
    • Next Steps
    Discussion Topics:
  • Federal Enterprise Architecture Program Management Office (FEA-PMO): Background
    • Establish a Federal Enterprise Architecture to facilitate the transformation to E-Gov
      • Enterprise Architecture Models (BRM, ARM, TRM)
      • Federal Enterprise Architecture Management System (FEAMS)
    • Support the implementation of the 24 Presidential Priority E-Gov Initiatives through the definition of a:
      • Solution Architect Working Group (SAWG)
      • Component-Based Architecture (CBA)
    • Identify Additional E-Gov Opportunities
  • Federal Enterprise Architecture Program Management Office (FEA-PMO): Accomplishments
    • Creation of the Federal Business Reference Model (BRM)
      • Define and Validate Federal Business Areas, Lines of Business, and Sub-Functions
      • Provides a framework for identifying opportunities for cross-agency collaboration and potential system redundancies
    • Establishment of the SAWG
    • Identification and release of the Component-Based Architecture
    • Providing on-going support to the 24 Presidential Priority E-Gov Initiatives
  • Federal Enterprise Architecture Program Management Office (FEA-PMO): Next Steps
    • Development of Additional Reference Models
      • Business Performance
      • Application/Capabilities
      • Technology and Standards
    • Solution Architect Working Group
      • Continue engaging with E-Gov Initiatives
      • Provide Leadership, Guidance, and Recommendations supporting:
        • System Architecture Planning and Implementation
        • Component-Based Architectures
        • The usage of XML, Web Services, UDDI, SOAP, etc.
      • Creation of best practice “check-lists” to support system implementation
      • Establish linkages to Federal CIO Council entities to help evolve guidance and recommendations (ongoing)
  • Solution Architect Working Group (SAWG) Charter
    • Leadership Team
    • Missions and Goals
    • Key Objectives
    Discussion Topics:
  • Leadership Team Bob Haycock Senior Solution Architect Roopangi Kadakia (FirstGov) Stuart Rabinowitz (GSA) Tice DeYoung (GSA) PRESENTATION Forms, Scripting DHTML, XSL, XML JSP, ASP HTML, JavaScript FirstGov Integration PLATFORMS & DB J2EE, .NET SQL, Databases Services Architecture BUSINESS LOGIC EJB, COM, COM+ UML, Use Cases SECURITY SSL, e-Authentication Encryption Security
    • Delivery Oversight
    • Communication/Outreach
    • Recommendations
    • Program Management
    OMB Portfolio Managers Managing Partners Industry Working Groups (i.e., NASCIO, w3.org), others Supporting Partners State and Local Norman Lorentz
    • Executive Management
    • Directional Oversight
    Roopangi Kadakia (FirstGov) Solution Architects Expanded structure based on demand of skills Marion Royal (GSA) MESSAGING SOAP Web Services XML ebXML Governmentwide Groups Industry
  • The SAWG was created to help the 24 Presidential Priority E-Gov initiatives succeed
    • Insight into (and across) E-Gov Initiatives
      • Avoid duplication of efforts
      • Leverage, share, and reuse technologies
      • Capture (and apply) lessons learned and best practices
      • Linkages to Federal Councils and Working Groups
    • Guidance and Leadership
      • Technology Selection and Recommendations
      • Solution Architecture and Blueprint Definition
      • Experience and Knowledge
      • Intellectual Capital
    • Transition Planning
      • Legacy Migration
      • Component-Based Architectures
      • Thinking “outside” the box
  • The SAWG has established several objectives and goals to help agencies and E-Gov Initiatives…
    • Monitoring, Support, and Guidance
      • Onsite visits
      • Architecture review
      • V&V, JAD, RAD Sessions
    • Generation and Distribution of Intellectual Capital (IC)
      • White Papers, Case Studies
      • Lessons Learned and Best Practices
      • Recommendations
      • Questionnaires and Surveys
  • The SAWG has established several objectives and goals to help agencies and E-Gov Initiatives, Cont’d…
    • Architecture Assessment
      • What should be leveraged, what shouldn’t
      • Existing vs. Targeted Solutions
      • Implementation Plans
      • Forecast Problems, Risk Mitigation
    • Identify and Leverage Linkages
      • E-Authentication
      • FirstGov
      • Federal Enterprise Architecture (FEA)
      • Governmentwide Entities
        • XML Working Group, CIO Council, etc.
  • The SAWG has established several objectives and goals to help agencies and E-Gov Initiatives, Cont’d…
    • Component-Based Architecture Specifications
      • Detailed Design, Examples
      • Tools and Techniques
        • Use Cases
        • Activity and Sequence Diagrams
        • Workflow, ERD
    • Component and Services Directory
      • Access to components (Industry, State, Local, Federal)
      • XML.GOV
      • Categorized by
        • Business Line, Functions and Capability
        • Technology Required, Usage Parameters
  • The SAWG has established several objectives and goals to help agencies and E-Gov Initiatives, Cont’d
    • Training Syllabus
      • Supporting Component-Based Development
        • Design and Development
        • Architecture
        • Program Management
    • Communication and Outreach
      • Website
      • Collaborative Tools
      • Linkages to Governmentwide Entities
  • Component-Based Architectures
    • Attributes of a Component-Based Architecture
    • Technology Selection Criterion
    • Logical Architectures
    • Developing Solutions
    Discussion Topics:
  • FEA-PMO has defined a Component-Based Architecture to support the 24 Presidential Priority E-Gov Initiatives
    • Select, recommend, and deploy sets of technology that are:
      • Reusable
      • Stable
      • Interoperable
      • Portable and Secure
    • Leverage emerging technologies and industry-proven standards:
      • Java 2 Enterprise Edition (J2EE)
      • Microsoft .NET
      • XML, XML Web Services
      • Commercial “off-the-shelf” tools and applications
  • Component-Based Architectures will allow the 24 Presidential Priority E-Gov Initiatives to
    • Identify and quickly capitalize on opportunities to:
      • Leverage, share, and reuse technology
      • Leverage cross-agency business functions
      • Streamline and improve information access
    • Reduce costs and risks associated with:
      • Legacy integration
      • Technology selection
      • Maintenance and support
      • Program management
    • Improve:
      • Quality and consistency of services
      • Customer support (citizen and intra-governmental)
      • Delivery, speed to market, shared services
  • Components provide a basis for the rapid assembly of business and cross-agency solutions Public/Citizen Services Customer FirstGov (Point of Entry, Authentication, Service Directory) - Online Rulemaking and Management - (Conceptual Design) DOT USDA EPA HHS ENERGY INTERIOR Shared/Reusable Components Agencies Policies, Local repositories Content Management Policy Repository Policy Search Engine Policy Profile Publishing Calendar Discussion Forums Policy Review Alerts and Subscriptions Feedback FAQ’s, Links Publishing Rules Common Business Processes Content Publishing Government Services Conceptual
  • Component architectures require the use and implementation of technologies that are
    • Cross platform and operating system independent
    • Mature (not antiquated) and proven across the market
    • Infrastructure independent
    • Standards based (i.e., w3.org)
    • Non-proprietary and extensible
    • Easier to deploy and integrate
    • Decoupled and loosely integrated
    • Interoperable (when needed)
    • Best practice enabled
      • Federal (CIO Council, NIST, GAO)
      • Industry (Carnegie Melon, Gartner, Commercial)
      • State and Local
  • FEA-PMO focused on the following foundations to support technology recommendations
    • Platform
      • The Foundation / Underlying Architecture
      • The Service Provider of Components
    • Data Format
      • Structure of Information
        • Easily Understood and Expandable
        • Leverages Industry Standards
      • Provides Common Vocabulary Capabilities (i.e., cross-agency)
      • Easily Integrated With Disparate Systems (i.e., legacy)
    • Messaging and Protocols
      • Manages the Delivery of Information
      • Leverages Industry Standards
  • Industry technologies provided the basis for platform selection and FEA-PMO guidance recommendations Scale  = low,  = medium,  = high         Ease of Development / Integration         Application Interoperability          Non-proprietary Extensibility 13 / 24 16 / 24 17 / 24 22 / 24 Final Analysis           Standards Based           Infrastructure Independence          Loose Integration of Heterogeneous Systems         Mature (not antiquated) Technology         Cross Platform Portability / OS Independent .NET / Email or FTP J2EE / Email or FTP .NET / Web Services J2EE / Web Services
  • Platforms have advantages and disadvantages that should be weighed against agency capabilities Microsoft .NET Java 2 Enterprise Edition (J2EE) Web Services FTP/Email CLR – Common Language Runtime C#, J#, COBOL, Visual Basic Single Platform Open Language Architecture Potentially easier to develop in (e.g., VB) Emerging Technology JVM – Java Virtual Machine Multi-platform Single language & open standards architecture Complex to develop solutions in Established and mature technology XML Based data transmission Requires little or no modification to infra. Easy implementation Emerging technology Enables loose integration of heterogeneous systems Supported by J2EE and .NET technologies Implemented for XML Based data transmission May require additional holes in infrastructure Awkward implementation Uses established and mature protocols Difficult to support integration of heterogeneous systems Supported by J2EE and .NET technologies D - Disadvantage A - Advantage R - Potential Risk D A A D R D A D A A A D A A A D A A
  • Logical Architecture: J2EE, Web Services
    • Advantages
    • Adaptability, dependable, flexible, secure
    • Maximum use of industry standards
    • Minimal firewall issues
    • Disadvantages
    • Complex to develop components/solutions
  • Logical Architecture: J2EE, XML over FTP
    • Advantages
    • Adaptable, dependable, flexible, secure
    • Maximum use of industry standards
    • FTP widely supported in legacy systems
    • Disadvantages
    • Complex to develop solutions/components
    • Firewall issues very likely due to FTP
  • Logical Architecture: Microsoft .NET, Web Services
    • Advantages
    • Supports multiple programming languages
    • Easy to develop in
    • Minimal firewall issues
    • Disadvantages
    • Early adopter of standards
    • Single platform only
  • Logical Architecture: Microsoft .NET, XML over FTP
    • Advantages
    • Supports multiple programming languages
    • Easy to develop in
    • Disadvantages
    • Early adopter of standards
    • Single platform only
    • Firewall issues very likely due to FTP
  • BUSINESS LOGIC TRANSACTION MANAGEMENT PRESENTATION / INTERFACE INFORMATION STORAGE CUSTOMER INTERFACING SYSTEM SECURITY Security provides an overarching framework that includes a series of defensive mechanisms and functions designed to protect the system, data and information from unintentional or malicious threats. INFORMATION STORAGE Information stored in persistent relational, object-based, and/or file based repositories is abstracted to hide the complexity of the storage system from the interfacing applications. PRESENTATION / INTERFACE Abstracts the complexity of the application from the user or interfacing applications. BUSINESS LOGIC Business functionality is modular and component based, enabling greater maintainability and interoperability. TRANSACTION MGMT . Ensures/optimizes access, quality, consistency, and integrity of operational data. To support reuse of components, solutions should be built using a tiered development approach SECURITY - Solution Design and Development - (Conceptual Framework)
  • Next Steps…
    • Establish linkages between governmentwide entities (i.e., Federal CIO Council, XML Working Group)
    • Expand the capabilities of the SAWG by enlisting more Solution Architects
    • Assignment of a Solution Architect to each the 24 Presidential Priority E-Gov Initiatives
    • Development and dissemination of Intellectual Capital (IC)
      • Checklists and strategies
      • White Papers and lessons learned
    • Help initiative understand, embrace, and deploy Component-Based Architectures
    • Launch of FEA-PMO and SAWG websites
    • Definition and validation of a Federally focused Application Capability Reference Model (ARM) and Technology Reference Model (TRM)
    As you can imagine, we are drinking from a fire hose!!!
  • Questions and Answers…