Copyright © 2006 Data Access Technologies, Inc.

Copyright © 2006 Data Access Technologies, Inc.

FMEA: A services oriented executable enterprise architecture for financial management

September Expedition Workshop

Cory Casanave

cory-c (at) enterprisecomponent.com

Page 2 Copyright © 2006 Data Access Technologies, Inc.January 2006

LOB

One-GSA Initiative

H.R.Finance

Marketing

PBS

FTS

FSS

Sch

edule

s

Build

ings

I.T.

Tele

com

s

Stovepipes

Un-Architected Solution Architected Solution

Auto

Supplie

s

One-GSASolutions

FAS


Approach

• Business focus, facilitated with technology

• Services Oriented Architecture (SOA) at both the business and technical level

• Described with Collaborative Role Interactions, Processes and Information models based on OMG standards

• Model Driven Architecture (MDA) to connect the business and technical architectures

• Web services as the technical interface to the line of business

• Tools Used– Component-X for Collaboration/Role modeling of the SOA– Magic draw UML for the information, data and message model– OsEra (open source eGov project) to generate web services


FMEA in Context

US Federal US Federal GovernmentGovernment

General Services General Services AdministrationAdministration

GSA GSA Office of the Office of the

Chief Financial OfficerChief Financial Officer

On

e G

SA

EA

On

e G

SA

EA

Fe

de

ral E

AF

ed

era

l EA

FM

EA

FM

EA

Financial Management Line of BusinessFinancial Management Line of Business


Business Concerns

Goals

Policy

Customers

Costs

Agility

Technology SpecificationWeb Services

WSDL, BPEL, XML Schema



Logical System ModelTechnology Services (t-SOA),

ComponentsInterfaces, Messages & Data



Business Focus Using Model Driven Architecture

One GSA/FMEA Business ModelBusiness Services (b-SOA)

Roles, Collaborations & InteractionsProcess & Information



Refin

emen

t & A

uto

matio

n

Lin

e-Of-S

igh

tC

om

pu

tati

on

Ind

epen

den

tM

od

el

Pla

tfo

rmIn

dep

end

ent

Mo

del

Pla

tfo

rmS

pec

ific

Mo

del

MDATerms


Incorporating Legacy Analysis


Value derived from the architecture

Business Concerns

Goals

Policy

Customers

Costs









One GSA Business ModelBusiness Services (b-SOA)


One GSA Business ModelBusiness Services (b-SOA)


ComponentAcquisition Specification

TechnologyInterfaces

Test &SimulationOMB 300

FEA/FTFBRMSRMDRM*

Business Driven Technology

Facilitating Business Processes

Adapters

Components

DataXBRL


Focus on the Business Model

Business Concerns








How does XBRL fit in?

XBRLConcepts

XBRLInterfaces

SystemComponent





Gen

erated

FMEA includes transaction andenactment as well as reporting.XBRL was one of many inputs.

FMEA must be able toSupport multiple interfaceStandards and technologies.XBRL is one of these.


The enterprise as services

• Think about the enterprise as a set of interacting roles providing and using services to enable agility, cost savings and an effective transition framework

• Externally– The enterprise is part of the global supply chain, providing services

to customers and using the services of suppliers

• Internally– Consider parts of the enterprise as providing services to other parts

of the enterprise, and in term using the service of others– Like everything was outsourced as a service, it just happens to be

done inside the organization.

• Business is modeled in terms of interacting roles – providing and using services – the essential concepts of business SOA


SOA Using Roles and Collaborations

• Role: A specification of the responsibility to perform specific functions in the context of a business process.

• Collaboration: A closed set of roles interacting to carry out a business process to achieve some joint purpose.

• Service: At the business level – a capability provided by one party to another.

• Protocol: A defined conversation between two roles providing and consuming services.

Commerce (Collaboration)

Buyer (Role) Seller (Role)Purchase(Protocol)


Collaborative Process ModelEnterprise Role. A major area of functional responsibility within the discipline of financial management.

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 or supported by an IT system.

Work Role. A role responsible for a specific functional area within an enterprise role, such as might be assigned to a single worker or supported by an IT system.

Activity. A specification of a business function in carried out the context of a work role.Activity. A specification of a business function in carried out the context of a work role.

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.

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.

Information Flow. An individual flow of information across a protocol or into or out of an activity.

Subactivity. A specification a subfunction within necessary to carry out an activity.Subactivity. A specification a subfunction within necessary to carry out an activity.


“One GSA” Disciplines (Simplified View)

Financial Management

Policy

Acquisition

Human Resources Marketing

Property ManagementSolutions

Business Intelligence

Focus of FMEA

ServiceInterfaces


Financial Management Discipline RoleProtocol representing delegated responsibility for interaction with

an entity external to GSA.

Protocol representing delegated responsibility for interaction with

an entity external to GSA.

Protocol representing interaction with another discipline within GSA.

Protocol representing interaction with another discipline within GSA.


Service Delivery Protocol

The protocols between discipline roles are composites that “roll up” the set of services

provided by one discipline to another.

The protocols between discipline roles are composites that “roll up” the set of services

provided by one discipline to another.

The sub-protocols within a roll-up protocol model specific business services provided by a discipline.

The sub-protocols within a roll-up protocol model specific business services provided by a discipline.


Financial Management Enterprise Roles (Simplified)

Receivables Accounting

Funds Management Payables Accounting

Asset Accounting

Financial Planning

General Ledger

Cost AllocationCash Management

Financial Reporting

Financial Reporting collects financial data from all other enterprise roles.Financial Reporting collects financial data from all other enterprise roles.


Example Enterprise Role

Business service provided by this enterprise role.

Business service provided by this enterprise role.

Business service this enterprise role requires

from another role.

Business service this enterprise role requires

from another role.

Time triggers for scheduled events.Time triggers for

scheduled events.


Example Business Service Protocol

The protocols between enterprise roles model business services provided by one role to others.

The protocols between enterprise roles model business services provided by one role to others.

The protocol is initiated by a business transaction

request.

The protocol is initiated by a business transaction

request.

Responses to the request may indicate success or

failure.

Responses to the request may indicate success or

failure.

Note that, while one role initiates and the other responds to the protocol, information may flow both ways across the protocol.

Note that, while one role initiates and the other responds to the protocol, information may flow both ways across the protocol. Each accepted transaction effects

a change in the information and behavior of the receiving role.

Each accepted transaction effects a change in the information and behavior of the receiving role.


Activities and Choreographies

• Activity: A specification of a business function in the context of a role.

• Choreography: A specification of the sequencing of external interactions required in order to carry out given business responsibilities.– A work role is choreographed in terms of the activities required to

perform the business services provided by the work role.– A complicated activity may be choreographed in terms of

subactivities.– A subactivity (or simple activity without subactivity decomposition)

is choreographed directly in terms of the event-triggered sequencing of its acceptance of inputs and sending of outputs.


Example Activities

ActivityActivity

Incoming business

transaction

Incoming business

transaction

Outgoing business

transaction

Outgoing business

transactionWork RoleWork Role


Example Subactivity Requirements

Description: Record a new unfilled customer order, as established via a specific sales instrument. Generate general ledger transactions to increase Unfilled Customer Orders and decrease Anticipated Reimbursements.

Requirement RMA-03 Reimbursable agreement information. Capture and accumulate reimbursable agreement JFMIP Core Requirements information that includes the following: 2005 * Billing limit * Billing terms * Customer order amount * Amount obligated * Amount expended * Advances collected * Advances applied to earned revenue * Remaining balance on advances * Amount earned * Amount billed * Accounts receivable * Collections on receivables. Enable access to reimbursable agreement information by customer ID number, reimbursable agreement number, project, or fund.

Description: Record a new unfilled customer order, as established via a specific sales instrument. Generate general ledger transactions to increase Unfilled Customer Orders and decrease Anticipated Reimbursements.

Requirement RMA-03 Reimbursable agreement information. Capture and accumulate reimbursable agreement JFMIP Core Requirements information that includes the following: 2005 * Billing limit * Billing terms * Customer order amount * Amount obligated * Amount expended * Advances collected * Advances applied to earned revenue * Remaining balance on advances * Amount earned * Amount billed * Accounts receivable * Collections on receivables. Enable access to reimbursable agreement information by customer ID number, reimbursable agreement number, project, or fund.


Information Model

This means “zero or more”

This means “one or more”This indicates a compositional (as opposed to referential) association.

This is a constraint that defines the sub-classification.

An un-shaded class is further detailed on a different diagram.

A term in the vocabulary represents a class of things to be described.

A term in the vocabulary represents a class of things to be described.

Attributes specify descriptive information having simple types.

Attributes specify descriptive information having simple types.

Entities may be described as having a unique identity.

Entities may be described as having a unique identity.

A relation between terms is described by an association between classes.

A relation between terms is described by an association between classes.

A class may be specialized into sub-classifications.

A class may be specialized into sub-classifications.


Information Model: What Is It For?

Business transaction Business transaction

The information model details the vocabulary of the business entities and transactions used in the process model.

The information model details the vocabulary of the business entities and transactions used in the process model.

The process model describes how business activities are (or are to be) carried out.

The process model describes how business activities are (or are to be) carried out.

State changes due to the activities

Work role

Activities

Implicit memory of business information


Business Concerns

Producing the logical model








Platform Independent Model

Financial Management Discipline

Protocols

Enterprise RolesWork Roles

Activities

Information ModelClasses

Financial Management Discipline

Protocols

Enterprise RolesWork Roles

Activities

Information ModelClasses

Core Financial System Specification

Service Interfaces

Enterprise ComponentsWork Components

Service Manager ComponentsBehavioral Specifications

Data ModelMessage SpecificationsData Manager Components

Persistent Data Specifications


Service Interfaces





Computation Independent Model Platform Independent Model


Three-Tier Component Architecture

Presentation Tier Application Tier Data Tier

Presentation Manager components provide user access to application services.

Presentation Manager components provide user access to application services.

Service Manager components provide transactional implementation of application services.

Service Manager components provide transactional implementation of application services.

Data Manager components persist data between application transactions.

Data Manager components persist data between application transactions.


Example Work Role (from CIM)

Related to Customer Orders

Related to Receivables


Corresponding Work Component

Presentation Tier Application Tier Data Tier

Explicit component for scheduling triggers

Explicit cross-transactional coupling via the data tier

Role for human participation in the process


Business Concerns

Producing Web Services









Service Interfaces






Service Interfaces





Platform Specific Model

Core Financial System Implementation

Web Services

Enterprise Information SystemsSystem Components

System Functions

Data DefinitionXML SchemasData Bases

Data Base Schemas

Core Financial System Implementation

Web Services

Enterprise Information SystemsSystem Components

System Functions

Data DefinitionXML SchemasData Bases

Data Base Schemas

Platform Specific Model (PSM)Platform Independent Model (PIM)


MDA Generated Web Services Definition

<wsdl:portType name="CustomerOrderEstablishment.CustomerOrderEstablishment"> <wsdl:operation name="CustomerOrderEstablishment"> <wsdl:input message="tns:CustomerOrderEstablishmentPanopticInheritanceCluster“ name="CustomerOrderEstablishment"> </wsdl:input> </wsdl:operation> </wsdl:portType>

<wsdl:portType name="CustomerOrderEstablishment.CustomerOrderEstablishmentCallback"> <wsdl:operation name="CustomerOrderEstablished"> <wsdl:input message="tns:CustomerOrderEstablishedPanopticInheritanceCluster“ name="CustomerOrderEstablished"> </wsdl:input> </wsdl:operation> <wsdl:operation name="CustomerOrderEstablishmentRejected"> <wsdl:input message="tns:CustomerOrderEstablishmentRejectedInheritance“ name="CustomerOrderEstablishmentRejected"> </wsdl:input> </wsdl:operation> </wsdl:portType>

The primary port type has operations corresponding to the request flows in the protocol.The primary port type has operations corresponding to the request flows in the protocol.

The callback port type has operations corresponding to the response flows in the protocol.The callback port type has operations corresponding to the response flows in the protocol.


Example Transaction Message XML Document

<CustomerOrderEstablishment><customerOrderEstablishment>

<newOrder><customerOrder>

<customerOrderID> … </customerOrderID><customerOrderAmount> … </customerOrderAmount>

<orderingCustomer><customer>

<customerID> … </customerID></customer><party>

<name> … </name></party>

</orderingCustomer><controllingSalesInstrument>

<salesInstrumentID> … </salesInstrumentID> </controllingSalesInstrument>

… <lineItems> … </lineItems>

</customerOrder> </newOrder>

</customerOrderEstablishment><businessDomainTransaction>

<transactionID> … </transactionID></businessDomainTransaction>

</CustomerOrderEstablishment>

<CustomerOrderEstablishment><customerOrderEstablishment>

<newOrder><customerOrder>

<customerOrderID> … </customerOrderID><customerOrderAmount> … </customerOrderAmount>

<orderingCustomer><customer>

<customerID> … </customerID></customer><party>

<name> … </name></party>

</orderingCustomer><controllingSalesInstrument>

<salesInstrumentID> … </salesInstrumentID> </controllingSalesInstrument>

… <lineItems> … </lineItems>

</customerOrder> </newOrder>

</customerOrderEstablishment><businessDomainTransaction>

<transactionID> … </transactionID></businessDomainTransaction>

</CustomerOrderEstablishment>


Summary

• FMEA is a general architecture of the federal financial services domain, done by GSA.

• It supports both internal GSA needs as well as the “line of business”.

• It uses MODA and SOA to provide a business centric architecture, drilling down to technology models.

• Artifacts can be generated for model based acquisition, the FEA, testing, service interfaces, data management, workflow and components.

• FMEA is entering the next phase of acquisition and implementation.


SOA Demo

• The SOA Community of Practice is sponsoring a demonstration of the business value and technical feasibility of SOA. This demonstration will encompass the full life-cycle of a multi-party SOA solution using multiple participants and multiple technologies collaborating via SOA standards in an architected community.

• Goals;– To provide a concrete example of how the SOA approach provides business value

to a community– To provide confidence that the approach and technologies are real – secure,

reliable, performing and practical.– To validate that independently developed applications can interoperate using SOA

standards

• The subject scenario for this demo is the interaction between the HR and Financial lines of business

• There are multiple government and industry participants

• This will be shown at the upcoming SOA-COP conference in October.

• If you are interested in participating, please contact me.

Copyright © 2006 Data Access Technologies, Inc.

Documents

business level

set of services

business function

services of suppliers

consuming services

approach business focus

line of business tools

discipline roles