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:
- consolidate IT operations on existing legacy applications in-house
- 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.
- componentized because we need to support the variability within different business sub-domains
- within many product areas, there are a lot of different types of overhead; there is also a high level of interconnected dependence
- 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
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
