copyright © 2006 data access technologies, inc
Post on 23-Jun-2015
140 Views
Preview:
TRANSCRIPT
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
Page 3 Copyright © 2006 Data Access Technologies, Inc.January 2006
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
Page 4 Copyright © 2006 Data Access Technologies, Inc.January 2006
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
Page 5 Copyright © 2006 Data Access Technologies, Inc.January 2006
Business Concerns
Goals
Policy
Customers
Costs
Agility
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
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
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
Page 6 Copyright © 2006 Data Access Technologies, Inc.January 2006
Incorporating Legacy Analysis
Page 7 Copyright © 2006 Data Access Technologies, Inc.January 2006
Value derived from the architecture
Business Concerns
Goals
Policy
Customers
Costs
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
One GSA Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
One GSA Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
ComponentAcquisition Specification
TechnologyInterfaces
Test &SimulationOMB 300
FEA/FTFBRMSRMDRM*
Business Driven Technology
Facilitating Business Processes
Adapters
Components
DataXBRL
Page 8 Copyright © 2006 Data Access Technologies, Inc.January 2006
Focus on the Business Model
Business Concerns
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
One GSA/FMEA Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
Page 9 Copyright © 2006 Data Access Technologies, Inc.January 2006
How does XBRL fit in?
XBRLConcepts
XBRLInterfaces
SystemComponent
One GSA/FMEA Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
One GSA/FMEA Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
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.
Page 10 Copyright © 2006 Data Access Technologies, Inc.January 2006
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
Page 11 Copyright © 2006 Data Access Technologies, Inc.January 2006
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)
Page 12 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 13 Copyright © 2006 Data Access Technologies, Inc.January 2006
“One GSA” Disciplines (Simplified View)
Financial Management
Policy
Acquisition
Human Resources Marketing
Property ManagementSolutions
Business Intelligence
Focus of FMEA
ServiceInterfaces
Page 14 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 15 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 16 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 17 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 18 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 19 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 20 Copyright © 2006 Data Access Technologies, Inc.January 2006
Example Activities
ActivityActivity
Incoming business
transaction
Incoming business
transaction
Outgoing business
transaction
Outgoing business
transactionWork RoleWork Role
Page 21 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 22 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 23 Copyright © 2006 Data Access Technologies, Inc.January 2006
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
Page 24 Copyright © 2006 Data Access Technologies, Inc.January 2006
Business Concerns
Producing the logical model
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
One GSA/FMEA Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
Page 25 Copyright © 2006 Data Access Technologies, Inc.January 2006
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
Core Financial System Specification
Service Interfaces
Enterprise ComponentsWork Components
Service Manager ComponentsBehavioral Specifications
Data ModelMessage SpecificationsData Manager Components
Persistent Data Specifications
Computation Independent Model Platform Independent Model
Page 26 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 27 Copyright © 2006 Data Access Technologies, Inc.January 2006
Example Work Role (from CIM)
Related to Customer Orders
Related to Receivables
Page 28 Copyright © 2006 Data Access Technologies, Inc.January 2006
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
Page 29 Copyright © 2006 Data Access Technologies, Inc.January 2006
Business Concerns
Producing Web Services
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
One GSA/FMEA Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
Page 30 Copyright © 2006 Data Access Technologies, Inc.January 2006
Core Financial System Specification
Service Interfaces
Enterprise ComponentsWork Components
Service Manager ComponentsBehavioral Specifications
Data ModelMessage SpecificationsData Manager Components
Persistent Data Specifications
Core Financial System Specification
Service Interfaces
Enterprise ComponentsWork Components
Service Manager ComponentsBehavioral Specifications
Data ModelMessage SpecificationsData Manager Components
Persistent Data Specifications
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)
Page 31 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 32 Copyright © 2006 Data Access Technologies, Inc.January 2006
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>
Page 33 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
Page 34 Copyright © 2006 Data Access Technologies, Inc.January 2006
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.
top related