Presented at the Choose Forum 2010 in Bern.

1. Compliance in service-oriented
architectures: A model-driven and
view-based approach
Uwe Zdun
Software Architecture Group
Department of Distributed and Multimedia Systems
University of Vienna
http://cs.univie.ac.at/swa

2. 2 software architecture group
COMPLIANCE: THE PROBLEM
DOMAIN

3. 3 software architecture group
IT Compliance
IT compliance means in general
complying to regulations that
apply to an IT system
Examples of regulations are: Basel
II, IFRS, MiFID, Cobit,
LSF, Tabaksblat, Sarbanes-Oxley
Act
These cover issues such as
auditor independence,
corporate governance, and
enhanced financial disclosure

4. 4 software architecture group
Other Compliance Sources
Regulations are just one example
There are many other rules and
constraints in a software system
that have similar characteristics
Service composition/Deployment rules
Service execution order rules
Information exchange policies
Security policies
QoS rules
Business rules
Laws
Licenses

5. 5 software architecture group
Current Practice for Dealing with Compliance
Ideal case: A SW-framework
for automatically dealing
with compliance
Problem: It is impossible to
formalize all details of a
jurisdictional text
Interpretation by domain
experts needed
Complex references to other
(jurisdictional) texts
Hence, in many cases,
compliance today is
reached on a per-case
basis

6. 6 software architecture group
Issues with the Current Practice
Systems are
hard to maintain
hard to evolve or change
hard to reuse
hard to understand
It is difficult to ensure guaranteed compliance to
a given set of rules and regulations
It is difficult to keep up with constant changes in
regulations and laws
Domain experts are not involved enough

7. Compliance in SOAs
So far the SOA approach does not provide any clear technological strategy or
concept of how to realize, enforce, or validate various compliance concerns

8. 8 software architecture group
OUR APPROACH

9. Approach Overview
Models and
meta-models for
the specification
of the SOA and
compliance
concerns
Domain-specific
languages
(DSLs) and
architectural
views for
compliance
concerns
Model-driven validation and generation
of the SOA from the models
Execution,
monitoring, and
enforcement of
compliance
concerns in the
running SOA

10. Approach: Auditor’s View
Regulation /
Legislation
Norm/Standard
Controls
Automated
Controls
Report
Manual
Controls
Manual
Implementation
Risk
Management
Department

11. Regulation /
Legislation
Norm/Standard
Controls
Automated
Controls
Report
Manual
Controls
View-based,
model-driven
Approach
Generated
Implementation
Risk
Management
Department
Approach: Auditor’s View

12. 12 software architecture group
Architectural Overview
MDSD
Software
Framework
Repositories
Application Servers,
ESB
Online Monitoring
Offline Monitoring
Dashboard
Data
Warehouse
Verification
Tools
Compliance
Request
Language
Design time
Runtime

13. 13 software architecture group
Compliance Solution: Overview & Roles

14. 14 software architecture group
View-based, Model-driven Architecture
Separation of concerns using architectural views
Separate different concerns in view-based models
Separation of abstraction levels: Separate technical
and domain-oriented views
Integrate via model relations and matching
algorithms using the model-driven generator

15. View-based Modeling Framework (VbMF)

16. View-based Modeling Framework (VbMF)
Separation of concerns

17. View-based Modeling Framework (VbMF)
Separation of technical
and domain-oriented
views

18. Extended VbMF: Modelling and Integration of
Compliance Concerns
Core Model
Flow View
Model
Collaboration
View Model
Information
View Model
Intellectual property
and license
DSL
extends extends extends
BPEL
FLow View
Model
BPEL
Collaboration
View Model
BPEL
Information
View Model
extends extends extends
Business Process Modeling
QoS policy
DSL
Security policy
DSL
Compliance Modeling
annotates
Process-driven model
instances with annotated
compliance metadata
instance-of
Schematic Recurrent
Code & Configurations
generates
extends
Regulatory or
legislative
DSL
Compliance
Metadata Model
annotates
Documentation
generates

19. Domain-Specific Languages Tooling: High-level and
low-level DSLs
Business/Domain
experts
IT/Technical
experts

20. DSL – An Example
High-Level DSL - Editor
Low-Level DSL

21. Compliance Metadata-Model
A bridge between compliance concerns and SOA
elements
Compliance metadata model elements:
References to regulations, standards, norms, licenses,
etc.
Controls
Referencing Services, Processes, etc. (elements that implement
the control)
Control type (e.g., change management control)
Risks associated to the controls
This allows us to specify statements like:
“Service/Process X is a change management control,
defined in COBIT, to comply with SOX”

22. Model-Driven Tool Chain
Transformation
Templates

23. 23 software architecture group
Execution and Monitoring
Process
engine
Service
monitors
Other IT event
detector
Event Bus
Governance of
Compliance
Audit
Trail
Event
Model
Dashboard

24. 24 software architecture group
Compliance Governance Dashboard

25. 25 software architecture group
EXAMPLE

26. 26 software architecture group
An Example of Process Design

27. 27 software architecture group
Searching for process fragments realizing SOX 409
concerns using the Compliance Request Language
Query
Models

28. 28 software architecture group
No suitable fragments are found. We model the concern
using the MDD framework
Models
Generated Code
Verified Models
Generated CodeGenerated CodeGenerated Code

29. 29 software architecture group
Monitor The Process at Runtime
EventsEvents
Display Information
Display Information

30. 30 software architecture group
Analyze compliance violation: Perform root cause
analysis using the models from the model repository
Models
Compliance
Violation

31. 31 software architecture group
Root cause analysis and process redesign in detail
Before: sequential task execution; slow, lots of violations
MORSE Repository
UUID 1
formID = „Form8K“
duration = 2
unit = BusinessDays
...
: PublishDeadline
UUID 5
Business
process
engine
1. Deploy process models
Monitoring
Infrastructure
2. Emit events UUID 3UUID 2UUID 1
3. Get compliance models
(rules) for process
4. Process
and
analyze
events
UUID 1
Violation
detected
5. Retrieve responsible /
corresponding models
ID = „Sec 409 Real time issuer disclosures“
...
: ComplianceConcern
UUID 4
Compliance
governance
Web UI
6. Report violation
7. Root cause analysis / manipulation of model(s)
Assess
Intrusion End
yes
no
Personal info
lost or stolen?
Response Write
Form 8-K
Approve
Form 8-K
Publish
Form 8-K
!
UUID 3
UUID 2
UUID 4
UUID 5
Assess
Intrusion End
yes
no
Personal info
lost or stolen?
Response
Write
Form 8-K
Approve
Form 8-K
Intrusion
detected
Publish
Form 8-K
!After: parallel task execution; faster, fewer violations
UUID 1

32. 32 software architecture group
Lessons Learned
On The nature of business compliance in a SOA system
Scattered through many system’s elements at different
abstraction levels
Existing in different development phases: analysis, design,
implementation, and runtime
Enabling methods and technologies for business
compliance in SOAs should
Tackling the compliance from multiple perspectives at multiple
levels of abstraction
Taking into account for the constant needs for changes of laws
regulations, policies, etc., to ensure incremental compliance
Engaging relevant stakeholders (business/domain experts,
technical experts) by providing appropriate tooling and
methods

33. 33 software architecture group
Many thanks for your attention!
Uwe Zdun
Software Architecture Group
Department of Distributed and Multimedia Systems
University of Vienna
http://cs.univie.ac.at/swa