350 likes | 577 Views
GSA Financial Management Enterprise Architecture. May 24, 2006. Agenda. Why Financial Management Enterprise Architecture (FMEA) Purpose Objectives EA Approach Model Driven Architecture MDA to SOA Items for Discussion. Why FMEA. Business Efficiencies Reduce IT Portfolio Duplication
E N D
GSA Financial ManagementEnterprise Architecture May 24, 2006
Agenda • Why Financial Management Enterprise Architecture (FMEA) • Purpose • Objectives • EA Approach • Model Driven Architecture • MDA to SOA • Items for Discussion
Why FMEA • Business Efficiencies • Reduce IT Portfolio Duplication • Utilize existing applications • Build out standard business processes • President’s Management Agenda – eGov • Plan the revolving and appropriations fund core accounting systems for a Financial Management Line of Business (FM LoB) serving GSA and other agencies. • Address immediate need to transform legacy applications into a cohesive financial management suite
FMEA Objectives • The FMEA product will accommodate Statutory, Office of Management and Budget (OMB), and GSA Functional requirements, such as tying to FEA reference models, and the goals of the FM LoB initiative, including: • achieving process improvements and cost savings; • standardizing business processes and data for customers and across GSA; • meeting business needs through ability to have standard interface with acquisition; • promoting seamless data exchanges among clients; • strengthening internal controls through interoperability; and • be consistent with the emerging GSA enterprise architecture. Be understandable and useable for Federal customers and GSA
PEGASYS Budgeting Planning Purchasing Accounts Payable Accounts Receivable Automated Disbursements General System General Ledger Credit Card Vendor External Reports > ExternalSystems TMR (6 D-N-P-V) FedPay (5 D-L-Q-K) PAR (3K-P-M-L) Labor Distribution (JL) FMS (9F-I) Bulkload (BK, BN, B*) Citibank Forms Import SV/PA/RC AE/ CX/ MI Transformation Box Batch Control Edit PAR Ref FEDEX .TRs Business Object for Pegasys, FMIS Financial Reports Online V I T A P Edit Conversion 131 VAT Extracting Process VATPROC Comprizon (1B, 1C, 1E) N.R.P ITOMS/OMIS (2B, 2C, 2E) Daily/Bi-monthly BILLINGS FAIM-FEDBIL(VL,UL, UQ, UJ) CSC-(LE) AUTOBILL(WQ, WJ, WL, WK ) TIRES (XL) TAP (8D-L-Q-J-I) RWA (QL, QJ, QQ) TOPS (HK) RENT (ZL) CBG (YL, YK, YJ) Manual Input (K*, DL, DQ) 159-459 (SL) GSAP(2J, H, G, N) RECEIVABLE 128-165-465 (FL) 420-488 411 (EL) VAT Splitter Process Data Elem Conversion 145 Performance Measurement Tool (PMT) TOPS (HB, HC, HE) Monthly Cost Allocation GSF (ML) 158-258-958 ITS TIRES 148 536 RPADS (GL) VCPC (1B,IE) FTS IFD GSAP InfoWizard UPPS (UE, UD) INVOICES (M7) DATA STORE Building Rent Project FDDS07 FDBX,RWA, FR2130, FDGSF,FR53FRIT FMIS Detail and Summary Query Tool STAR IRIS TOOLBOX
Enterprise Components in a Service Oriented Architecture • Enterprise Components must be independent & loosely coupled • While being able to interoperate with each other using services • Making the information system a lattice of cooperating components • Simulated or real Service Service Service Service
Development of Government-wide Policy Plan and Design Develop and Deliver Provide After Care Acquisition Value Chain Financial Management Services I.T. Services Human Capital Services Marketing Shared Services Value Chains • So why is this important?
Architectural Approach MDA, ADM and Executable Architecture
FMEA: MDA Top Down - ADM Bottom Up Discovery of System Details and generation of Technology Specifications is largely automated Model Driven Architecture (MDA) Architecture Driven Modernization (ADM)
What is Executable Enterprise Architecture? • Moves past a static process diagram to an organic model that is aligned with agency’s business and IT planning and existing infrastructure. • Model Driven Architecture (MDA) • EDOC – Enterprise Collaboration Architecture (ECA)
What does Executable EA Accomplish? • Aligns business cases with systems design/development within existing IT infrastructure • Collapses CPIC and SDLC cycles • Significantly reduces resource burden – ‘JIT’ 300 generation • Integrates metric analysis – prior to procurement or development effort • Performance Reference Model ‘line of sight’ from model simulation trace • Leverages open standards to build your EA • The end of modeling fatigue and paper tiger extinction! • Ensures agile, business driven IT management
Why Use MDA? • Framework for structuring business and technology specifications expressed as models • Separates platform independent models and technology specific models • Allows applications to be integrated by explicitly relating their models
Model Driven Architecture • Computation Independent Model (CIM) • The business model • Platform Independent Model (PIM) • Technology independent system specification • Conforms to the business model (CIM) • Platform Specific Model (PSM) • Technology specific (e.g., middleware, application platform, etc.) system design • Conforms to the system specification (PIM)
Enterprise Architecture Model (PIM) Refine/Iterate Live Process Simulation AutomatedModel Driven Architecture Business Process Architecture Simulator ECA Standard “Meta-Model”
Focus of FMEA Financial Management Policy Acquisition Human Resources Marketing Property Management Solutions Business Intelligence CIM: “One GSA” Disciplines
Receivables Accounting Funds Management Payables Accounting Asset Accounting Financial Planning General Ledger Cost Allocation Cash Management Financial Reporting CIM: Financial Management Enterprise Roles Financial Reporting collects financial data from all other enterprise roles.
Enterprise Role. A major area of functional responsibility within the discipline of financial management Work Role. A role responsible for a specific functional area within an enterprise role, such as might be assigned to a single worker and supported by an IT system Activity. A specification of a business function carried out in the context of a work role Subactivity. A specification a sub-function necessary to carry out an Activity Protocol. A defined conversation between two roles that may be extended over time. One role initiates and the other responds to the protocol, but information may flow both ways across the protocol Information Flow. An individual flow of information across a protocol or into or out of an Activity or Subactivity GSA’s FMLoB: CIM Decomposition Conventions
Example of Data Included in Processes:Receivable Establishment Message Model
Protocol WSDL Representation (PSM/SA, TRM) <portType name=“ChargeEstablishmentRequestInterface"> <operation name=“sendChargeEstablishment"> <input name=“ChargeEstablishment" message="tns:ChargeEstablishment" /> </operation> </portType> <portType name=“ChargeEstablishmentResponseInterface"> <operation name=“sendChargeEstablished"> <input name=“ChargeEstablished" message="tns:ChargeEstablished" /> </operation> <operation name=“sendChargeRejected"> <input name=“ChargeRejected" message="tns:ChargeRejected" /> </operation> </portType>
Each Work Component in the PIM implements a Work Role from the CIM Work Module PIM/PSM: Service-Oriented Component Architecture Presentation Tier Application Tier Data Tier Presentation Manager components provide user access to application services Service Manager components provide transactional implementation of application services defined in the CIM Data Manager components persist data between application transactions
Each Work Component in the PIM implements a Work Role from the CIM PIM/PSM: Service-Oriented Component Architecture Presentation Tier Application Tier Data Tier Presentation Manager components provide user access to application services Service Manager components provide transactional implementation of application services defined in the CIM Data Manager components persist data between application transactions System Assembly Subsystem
Provided services Used services Explicit cross-transactional coupling via the data tier Role for human participation in the process Presentation Manager Service Managers Data Managers PIM: Receivables Management Work Role
Recursive decomposition for ‘systems of systems’ modeling • Business processes described as a composition of services • Collaborative Role Interactions (CRI), service choreography • Services are realized by (a composition of) components Community Process (CoP) ROLE 1 ROLE 2 ROLE 1 P1 P2 ROLE 3 P4 P3
Contextualize Roles = Service Providers Collaborations GSA Enterprise Buyer Enterprise Seller Enterprise
Inner Roles = Service Granularity Compose Roles
Organize Conversations Choreographed by Roles Protocols
Summary of FMEA Project • Developed a standard set of business processes for financial management, including the core functions, plus fixed asset accounting, inventory, and • Standard processes are compliant with FSIO • Standard processes are compliant with FM LOB • Standard processes show interactions of functions • Developed data objects relevant to each business function and activity • Flow of data activity aligns with processes developed • Provides relationships among the data objects • Documented requirements and business rules • Requirements are compliant with FSIO • Requirements are compliant with FM LOB • Business rules include Federal rules, plus GSA specific rules • Generated Function Requirements and Interface Specifications
Key Thoughts • An agreed upon approach and methodology is the key, tools help • Utilize existing knowledge bases to cut down on rework and modeling/study fatigue • Business Drivers/Business Outcomes
Questions? Thank You to our Partners: GSA OCIO Logistics Management Institute Data Access Technologies