SATURN 2011 Session: Model-Driven Architecture (morning, May 19, 2011)

Notes by Jack Chen

Design and Implementation of an Agile Price Management Platform for Banking
Thipor Kong, Credit Suisse
Ulrich Hildebrand, Credit Suisse

Abstract and presentation slides

Two strategic directions being pursued:

  1. consolidate IT operations on existing legacy applications in-house
  2. trying to stabilize, renew, rebuild existing applications with new capabilities

Core banking processes

  • we don’t sell brokerage, payments, or custody as isolated offerings
  • key focus in Premium Private Banking on sophisticated banking solutions by bundling and integration

Current code base was designed in the 70s and 80s.

Many of the design ideas that are deeply embedded in these applications are centered around the operational processing, not the client relationship.

Tasked with building a new platform that handles client-centered pricing across all core banking processes.

Need to figure out what kind of architecture to use to solve this “matrix” overlay of cross-cutting concerns.

Currently have 20 product areas of core product offerings.

In the back, there’s a management and financial accounting suite.

In the front, there are price models in the form of tariffs;

  • ability to negotiate with the client and get rebates
  • want to give very sophisticated kinds of rebates

Must deal with an incredibly complex interconnectivity of the different ways the front and back are mixed.

Need an architecture to speedily provide an integrated pricing platform.

Decided against a monolithic platform that everyone must go through to get pricing.

Decided to go with a componentized platform.

  1. componentized because we need to support the variability within different business sub-domains
  2. within many product areas, there are a lot of different types of overhead; there is also a high level of interconnected dependence
  3. the most important reason is political, each component represents a sub-domain of the business that’s very insular

Effective reuse can be achieved only by a careful and differentiated analysis.

You must design for reuse; if you just call it reuse you’ll end up with clutter.

Reuse approach

  • a clear separation between data-driven applications and logic-driven applications
  • choose differentiated paths for different types of reuse

Two major approaches

  • use-case oriented, cut your service explicitly for each use case
    • benefit is that the service can be specifically tailored for each use case
    • danger is that you can get service explosion
  • data-oriented, compositional CRUD; danger is that you’re limited to single operations, single entity, and constraints are not enforced across entities

Alternative, combination, compositional CRUD

  • provide composable commands
  • the client sends a list of commands
  • the service works on a network of objects
  • provide a single transaction that allows the client to execute an arbitrary number of activities

Domain-driven design, with a twist

  • core domain logic; close set of java classes that capture the essence of how we do our business
    • anything that’s specialized or different is handled through interfaces
    • mixing in specific rules for a particular domain
    • separation allows development of domain-specific logic without having to worry about all of the underlying infrastructure

Creating the federated architecture (FA)

  • interoperability and control across semi-autonomous decentralized lines of business
  • defines what has to be shared, common concepts, and reusable components
  • complexities are due to local particularities and requiring a central locus of control

Q: How long did it take to switch to a federated model?

  • It took 4 months, the political discussion was what took the longest time.
  • bloody and messy, who has control of defining a project, programs, etc.

Q: How many years for the roadmap to implement this?

We’re in year 1, horizon of 3-5 years

Q: You have a set of shared components, how do you manage changes in the core components? (backwards compatibility)

We take a brute-force approach now. You have to become a software vendor within the company.

Using Architecture Models to Predict Software-Intensive Technology Deficiencies
Kristin Giammarco, NPS
Kimali Messado, CERDEC

Abstract

Interoperability of design

  • work in the context of an operationally realistic setting
  • enable a venue for various vendors to bring their products to see how they will interoperate in a deployed environment
  • a formal method for predicting interoperability
  • costly and tightly scheduled tests, need to predict to save on time and effort

Interoperability is more than compliance to standards.

Bridge the communities of software and system engineering. Using formal methods from the software within the system engineering context.

How can system architects contribute to the reduction of interoperability problems for systems?

Use cases are seen a lot of within the DoD, sequential models.

  • assess pair-wise interoperability issues
  • use a quantitative model to account for problems

Performer-driven analysis

  • performers are what we can see, what does things
  • observable things that exhibit behavior

Predicting in terms of model and see the system

Quantify in terms of being able to count something, missing relationships that could lead to oversights

Correcting in order to do something, modify or improve the design

Look at the properties and relationships to draw conclusions about interoperability.

Identify a characteristic of interest for a system design (interoperability).

Use architecture model classes and relationships that impact the design WRT to that measure.

Identify conditions and constraints to apply to classes & relationships.

Check completeness of those conditions in a model-validation tool.

Apply the conditions to a populated architecture model for analysis.

Identify a set of performers and their interactions.

Define a set of conditions that must be met for interoperability. These are rules imposed over the dynamic interaction between performers .

Example of analysis

Analysis of exchange of some order between the brigade and battalion

  • perfomers: brigade JCR (software platform) communicates to a battalion JCR
  • activity: sending the order from the brigade to the battalion
  • connector: some logical connection
  • standards: format of the message
  • interaction item: the message itself

Perform analysis of this system WRT to the seven necessary conditions (defined out of scope)

Unambiguous basis for interoperability assessment

Traceable to architecture model data

Tool-independent

Eventually automated

Necessary conditions, not sufficient conditions

Conditions do not identify all potential “mismatches” for interoperability

Performance may be a factor

Assessment done through pair-wise comparison

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s