solution architects working group (sawg)

28
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)

Upload: aamir97

Post on 28-Dec-2014

351 views

Category:

Technology


1 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Solution Architects Working Group (SAWG)

SAWGSolution Architects Working Group

Overview of Mission and Objectives

XML Working Group MeetingJune 19, 2002

Federal Enterprise Architecture - Program Management Office(FEA-PMO)

Page 2: Solution Architects Working Group (SAWG)

2

Presentation Areas:

Federal Enterprise Architecture Program Management Office (FEA-PMO)

Solutions Architect Working Group (SAWG) Charter

Component-Based Architectures (CBA)

Page 3: Solution Architects Working Group (SAWG)

3

Federal Enterprise Architecture Program Management Office (FEA-PMO)

Discussion Topics:

BackgroundAccomplishmentsNext Steps

Page 4: Solution Architects Working Group (SAWG)

4

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

Page 5: Solution Architects Working Group (SAWG)

5

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

Page 6: Solution Architects Working Group (SAWG)

6

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)

Page 7: Solution Architects Working Group (SAWG)

7

Solution Architect Working Group (SAWG) Charter

Discussion Topics:

Leadership TeamMissions and GoalsKey Objectives

Page 8: Solution Architects Working Group (SAWG)

8

Leadership Team

Bob Haycock

SeniorSolution 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

Page 9: Solution Architects Working Group (SAWG)

9

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

Page 10: Solution Architects Working Group (SAWG)

10

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

Page 11: Solution Architects Working Group (SAWG)

11

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.

Page 12: Solution Architects Working Group (SAWG)

12

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

Page 13: Solution Architects Working Group (SAWG)

13

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

Page 14: Solution Architects Working Group (SAWG)

14

Component-Based Architectures

Discussion Topics:

Attributes of a Component-Based ArchitectureTechnology Selection CriterionLogical ArchitecturesDeveloping Solutions

Page 15: Solution Architects Working Group (SAWG)

15

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

Page 16: Solution Architects Working Group (SAWG)

16

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

Page 17: Solution Architects Working Group (SAWG)

17

Components provide a basis for the rapid assembly of business and cross-agency solutions

Public/Citizen ServicesCustomer

FirstGov(Point of Entry, Authentication, Service Directory)

- Online Rulemaking and Management -(Conceptual Design)

DOT USDA EPA HHS ENERGY INTERIOR

Shared/ReusableComponents

Agencies

Policies,Local repositories

Content Management

PolicyRepository

Policy Search EnginePolicy Profile

Publishing CalendarDiscussion Forums

Policy Review

Alerts and Subscriptions

Feedback

FAQ’s, Links

Publishing

Rules

CommonBusiness

Processes

Content Publishing

Government Services

Conceptual

Conceptual

Page 18: Solution Architects Working Group (SAWG)

18

Component architectures require the use and implementation of technologies that are

Cross platform and operating system independentMature (not antiquated) and proven across the marketInfrastructure independentStandards based (i.e., w3.org)Non-proprietary and extensibleEasier to deploy and integrate Decoupled and loosely integratedInteroperable (when needed)Best practice enabled

Federal (CIO Council, NIST, GAO) Industry (Carnegie Melon, Gartner, Commercial) State and Local

Page 19: Solution Architects Working Group (SAWG)

19

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

Page 20: Solution Architects Working Group (SAWG)

20

J2EE / Web Services .NET / Web Services J2EE / Email or FTP .NET / Email or FTP

Cross Platform Portability / OS Independent

Mature (not antiquated) Technology Loose Integration of Heterogeneous Systems

Infrastructure Independence Standards Based Non-proprietary Extensibility Ease of Development / Integration Application Interoperability Final Analysis 22 / 24 17 / 24 16 / 24 13 / 24

Scale

= low, = medium, = high

Industry technologies provided the basis for platform selection and FEA-PMO guidance recommendations

Page 21: Solution Architects Working Group (SAWG)

21

Platforms have advantages and disadvantages that should be weighed against agency capabilities

Microsoft .NET Java 2 Enterprise Edition (J2EE)

Web ServicesFTP/Email

CLR – Common Language RuntimeC#, J#, COBOL, Visual Basic

Single PlatformOpen Language ArchitecturePotentially easier to develop in (e.g., VB)Emerging Technology

JVM – Java Virtual Machine

Multi-platformSingle language & open standards architectureComplex to develop solutions inEstablished and mature technology

XML Based data transmission

Requires little or no modification to infra.Easy implementationEmerging technologyEnables loose integration of heterogeneoussystemsSupported by J2EE and .NET technologies

Implemented for XML Based data transmission

May require additional holes in infrastructureAwkward implementationUses established and mature protocolsDifficult to support integration ofheterogeneous systemsSupported by J2EE and .NET technologies

D - Disadvantage A - Advantage R - Potential Risk

DAAD

RDAD

A

AADA

AADA

A

Page 22: Solution Architects Working Group (SAWG)

22

Quicksilver Initiative 2

Common Services

AuthenticationServicesUDDI

Quicksilver Initiative 1

EJB / Servelet Wrapper

SDK / API

Browser Client

HTTP / HTTPS

JDBC

XML Parser

COTS

Business Logic

Presentation /Interfaces Layer

TransactionMgmt.

OR Mapping

Web Services

Data Layer

RMI

DAO

SOAP / WSDL

Flat Files

RDBMS

Middleware

XM

L P

arse

r

Web

Ser

vice

s

Remote Browser Client

SOAP / WSDL

HTTP / HTTPS

JSP

HTTP / HTTPS

EJB / Servelets

RMI

Authenticated Request

Logical Architecture: J2EE, Web Services

Advantages• Adaptability, dependable, flexible, secure• Maximum use of industry standards• Minimal firewall issues

Disadvantages• Complex to develop components/solutions

Page 23: Solution Architects Working Group (SAWG)

23

Quicksilver Initiative 1

EJB / Servelets Wrapper

SDK / API

Browser Client

JDBC

XML Parser

COTS

Business Logic

Presentation /Interfaces Layer

TransactionMgmt.

OR Mapping

Data Layer

RMI

DAO

Flat Files

RDBMS

Middleware

Quicksilver Initiative 2

Common Services

AuthenticationServices

XM

L P

arse

r

FT

P /

MA

IL

Remote Browser Client

HTTP / HTTPS

JSP

HTTP / HTTPS

HTTP / HTTPS

EJB / Servelets

RMI

FTP

Authenticated Reaquest

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

Page 24: Solution Architects Working Group (SAWG)

24

Quicksilver Initiative 1

COM / COM+ (C#)

SDK / API

Browser Client

HTTP / HTTPS

ADO / ODBC

XML Parser

COTS

Business Logic

Presentation /Interfaces Layer

TransactionMgmt.

OR Mapping

Web Services

Data Layer

DCOM

DAO

Flat Files

RDBMS

Middleware

Quicksilver Initiative 2

Common Services

AuthenticationServices

UDDI

XM

L P

arse

r

Web

Ser

vice

s

Remote Browser Client

SOAP / WSDL

SOAP / WSDL

HTTP / HTTPS

ASPHTTP / HTTPS

COM / COM+ (C#)

DCOM

Autheticated Request

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

Page 25: Solution Architects Working Group (SAWG)

25

Quicksilver Initiative 1

COM / COM+ (C#)

SDK / API

Browser Client

ADO / ODBC

XML Parser

COTS

Business Logic

Presentation /Interfaces Layer

TransactionMgmt.

OR Mapping

Data Layer

DCOM

DAO

Flat Files

RDBMS

Middleware

Quicksilver Initiative 2

Common Services

AuthenticationServices

XM

L P

arse

r

FT

P /

MA

IL

Remote Browser ClientFTP

HTTP / HTTPS

ASP HTTP / HTTPS

HTTP / HTTPSCOM / COM + (C#)

DCOM

Autheticated Request

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

Page 26: Solution Architects Working Group (SAWG)

26

BUSINESS LOGICBUSINESS LOGIC

TRANSACTION MANAGEMENTTRANSACTION MANAGEMENT

PRESENTATION / INTERFACE PRESENTATION / INTERFACE

INFORMATION STORAGEINFORMATION STORAGE

CUSTOMERINTERFACING

SYSTEM

SECURITYSecurity 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 STORAGEInformation 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 LOGICBusiness 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 SECURITY

- Solution Design and Development -(Conceptual Framework)

Page 27: Solution Architects Working Group (SAWG)

27

Next Steps…

As you can imagine, we are drinking from a fire hose!!!

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)

Page 28: Solution Architects Working Group (SAWG)

28

Questions and Answers…