Commodity Price Engine - Deployment Diagram

These are possible components for Commodity Price Engine that could be built on top of AWS or Windows Azure and be based on available open-source products and some modules developed in-house.

Brief Q&As About Solution Architecture

1. What would be the key artefacts that need to be delivered when defining a solution architecture?

Key artefacts present different views on solution design where each view is targeting specific user groups. For example:

1. Business architecture artefacts address business users, planners and business stakeholders.
2. Data architecture artefacts address database and system administrators.
3. Application architecture artefacts provide guidelines and instructions for software development and test teams.
4. Technology architecture artefacts are essential for infrastructure administrators, development team and system managers.
5. Security architecture artefacts address the development and test teams, system administrators, security auditors, business users and managers.

Solution architecture artefacts also depend on methodology used by an organisation that the solution is designed for. Popular methodologies include but not limited to TOGAF, Zachman, RUP, CMMI, FEAF.  Examples of key artefacts could be:

1. TOGAF:
1. Catalogues (role catalogue, product catalogue, data entity catalogue, etc)
2. Matrices (business interaction matrix, actor/role matrix, system data matrix, etc)
3. Core and extension diagrams (functional decomposition diagram, use case diagram, process flow diagram, event diagram, product lifecycle diagram, data security diagram, etc)
2.  Zachman:
1. Practically sufficient subset of Lists, Models, Diagrams, Specifications and Details documents that are based on 30 views of Zachman framework matrix – Why/How/What/Who/Where/When by Contextual/Conceptual/Logical/Physical/Detailed.

Sometimes a final Architecture Document could combine major views and present the solution to most user groups. From my experience I found that in some cases that require relatively urgent delivery, a properly built Business Requirements Document could become a part of the final Architecture Document. I published a short manual for such BRD on my blog at http://bananaqualitytester.blogspot.co.uk/2013/01/guidelines-for-business-requirements.html.

2. What would be the role of Solution Architect during the project lifecycle?

Solution Architect’s activity during the project lifecycle should be organically coupled with business stakeholders’ decision making, development team/s delivery progress and the end users expectations to ensure:

• Target architecture would accommodate any possible evolution of the business stakeholders’ vision of the future system.
• Development teams would follow the architectural guidelines without sacrificing quality, robustness and effectiveness of the future system.
• The end users have an early access to the system-in-development, play with it, test it and provide feedback to architecture and development teams.

It always a good idea to keep architecture artefacts such as definitions, models, diagrams, specifications, etc updated during the project to make sure they could be re-used in the future by the business users, help desk and system support staff.

3. How would a Solution Architecture work in the context of Waterfall and Agile methodologies?

Once all business requirements are clarified and understood, a typical search for a solution may include such activities as reviewing competitive technologies, evaluating open and commercial off-the-shelf products, building and testing prototypes, etc. In some organisations it’s called Research and Development (R&D) stage. The output of R&D stage is a solution design that is (or at least very close to) target architecture that would be eventually defined in such documents as Architecture Document mentioned above.

Waterfall methodology is acceptable in cases when business decision about future system is final and a chance for any changes is very low. In this case R&D stage is paramount for the whole project as the solution architecture artefacts would be translated into project management timelines, delivery milestones, QA test case scenarios and system releases. Given the importance of R&D, it would make sense to spend more time on avoiding any ambiguity during reviewing business, functional and non-functional requirements, looking for possible issues with off-the-shelf products and stress-testing prototypes to ensure a delivery of a flawless solution.

Agile methodology doesn’t require absolutely complete set of requirements, giving it a chance to evolve during the system development. From high-level perspective, an agile project could be represented as follows:

The straight lines coming from the centre (epicentre) are individual use cases, circle lines are delivery milestones and the red spiral line is actual system development that ‘covers’ use cases (and milestones) more and more with each iteration until all of them are done (or delivered). In this case the core system functionality (area around the epi-centre) is paramount and requires clear prioritisation by the solution architect. Because of project agile nature, it is expected that solution architecture artefacts would evolve during the project and therefore should be continuously updated by the architect and those changes propagated through all teams involved into the product delivery.

4. What process steps would be expected between the capture of requirements and start of the coding?

These steps may depend on architecture methodology used in the organisation (TOGAF, RUP, Zachman, etc) as well as the type of given project (waterfall or agile). They may include:

• Business, functional and non-functional requirements review and clarification.
• Business requirements update (see Guideline for Business Requirements mentioned above) and their verification with business users. These steps would help to build with business users unambiguous project vocabulary, learn more about their expectations, identify key people in their team and establish working relationships with them.
• R&D stage – please, see (3) for more details.
• Initial solution design.
• Verification of acceptability of proposed solution for existing or target infrastructure.
• Cross-check of proposed solution design with budget requirements.
• Validation of proposed solution design against system security constraints.
• Validation of proposed solution design against internal and/or external rules and legislation.
• Approval of solution design with key stakeholders.
• Final (or semi-final in case of agile) solution design.
• Creation of solution architecture artefacts - please, see (1) for more details.
• Definition of development environment. This may include continuous integration and automated testing, knowledge management system, issue tracking system, network topology (in case of delivering a Cloud-based solution), etc – this is a range of approaches that would allow to keep development process transparent to the architecture team as well as to other interested parties involved in the project.
•  Requirements for system test coverage.

NetKernel Takes Micro-Services to the Ultimate Level

While talking about such relatively new boys on the market as Vert.x, Akka, Chronicle, Kafka, Ready! API, RxJava, etc which certainly are great components for solutions that respond to current demand for micro-services, the mainstream seems to be completely missing such nice, mature and easy to use product as NetKernel. The latter one is not competing with newcomers and together they can comprise quite elegant solutions that any architect would be eventually proud of.

NOTE: This is not a promotion for NetKernel. I don't work for them. This is just an attempt to be fair to those that somehow happened to be on a side of the road.

Functional Requirements for Commodity Price Engine

Introduction

Commodity Price Engine is a derivatives sales tool and potentially a trading application designed specifically for the commodities market covering energy, base metals and agricultural products. It provides server based pricing and sensitivities for structures consisting of forwards and options that incorporate volatility skew and is designed to be delivered via the web and as native mobile applica- tions. The implemented functionalities in the prototype are detailed below, along with market data requirements and planned extensions.

Supported Underlying Assets

Commodity Price Engine supports any asset with forward curves and implied volatility surfaces. This includes exchange traded products with sufficient liquidity and products for which the user is able to supply the forward curves and volatility surfaces. A planned extension for Commodity Price Engine would build required curves and surfaces to accommodate structures on illiquid underlying assets.

Supported Derivatives and Valuation

Pricing and sensitivities are available for forwards, bullet and Asian options, and structures consisting of any combination of forwards and options. The valuation model takes into account volatility skew and has been benchmarked against commercial software used in investment banks. Price and sensitivities can be converted to any currency and standard metric units.

4. Sales and Trading Features

Commodity Price Engine would allow addition of sales and trading margins, shifting of forward curves and volatility surfaces for what-if analysis, solving for break even strikes for structures, generation of term sheets, and graphing of forward curves and payoff diagrams. It also would accommodate back-dated pricing for available historical data.

5. Planned Extensions and Enhancements

Additional features that are planned for Commodity Price Engine include:
- Construction of illiquid forward curves and implied volatility surfaces.
- Calculation of credit value adjustment (CVA).
- Computation of value-at-risk (VaR).

6. Market Data Requirements

Commodity Price Engine assumes availability of the following market data:
- Yield curves for required currencies (it would be possible to bootstrap yield curves from cash, futures, OIS, swap, and single currency basis swap quotes).
- Forward curve and implied volatility surface (it is possible to build volatility surfaces from market quoted option prices) for required underlying assets.
- FX forward curve and volatility surface for required currency pairs.
- Implied survival probabilities for relevant entities if CVA calculation is required (it would be possible to compute the survival probabilities from yield curves and credit default swap (CDS) spread quotes).
- Historical data for above if VaR calculation is required.
Market data can be obtained from commercial data vendors such as Bloomberg or Reuters (commodities data from such market data sources as ze.com will need to be supplemented by interest rate, FX, and credit data).

7. Technology Architecture

Commodity Price Engine architecture consists of server and client side components. The server side manages market data and could be loosely coupled with a grid of quantitative pricing libraries. The client side is the Graphical User Interface (GUI) that communicates with the server via secure protocol and could be accessed from desktops or a variety of mobile devices. Pricing libraries could be placed on the client side if required.

8. Conclusion

Commodity Price Engine would be a sales and trading application designed for participants in the commodities market who traditionally relied on investment banks for pricing support due to limited access to suitable tools. It would have the capacity to become a full-scale trading platform if supplemented with modules for connecting to trade booking and counterparty portfolio management systems.