Alibaba Cloud

Alibaba's statement on IP EXPO LONDON was plain and clear - tell us what you need and we'll do it for you, let's work together for our mutual benefit.

It didn't take long - Alibaba Cloud came to Europe. Although Alibaba has a quite efficient payment system that they technically polished in China while processing huge number of transactions on the daily basis, in Europe they started with offering just traditional cloud infrastructure. I can't wait and see what kind of other offers would follow.

How Alibaba presence looks from a consumer perspective? I've got a quick example - during Alibaba's 11.11 event I bought two 5000LM X800 'tactical' torches (they are great for cycling!) for a half price of one. I got them from an eBay seller who most likely proxied Alibaba transaction on that day.

If supply chain, online catalogues, shopping carts, checkouts and delivery of purchased items are all done under the same umbrella (Alibaba), what would happen to current distributors of Chinese goods in Europe and programmers that provide support for their online transactions? How would Amazon and eBay compete with Alibaba?

What kind of services (MaaS, SaaS, PaaS, etc) and APIs would Alibaba provide for its European infrastructure? I hope we'll find it out pretty soon.

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.

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.

Microsoft Workshop: Developing for Internet of Things, London

The workshop took place in Microsoft office at 100 Victoria Street. The crowd was pretty big. First we came through a couple of presentations and then did three labs. Overall, the workshop was very interesting, it gave a good overview of what IoT consists of, where we are with it at the moment and how it would possibly evolve in near future. See below some take aways that I think could be helpful to review later on.

Our presenters were:

• Paul Foster, DX Microsoft UK, and
• Robert Hogg, MVP, Microsoft Integration, MD Black Marble

Some notes:

1. There are open source IoT frameworks (for example, check out AllJoyn)
2. IoT provides Data-Driven Insights (Telemetry):
1. More efficient use of resources (cost reduction, environmental impact)
2. More targeted products and services (social impact, increased revenue)
3. While working with connected devices, it's very hard to predict in advance what data will be useful. The important data may not be what was expected in the beginning. Therefore:
1. It's tempting but likely inefficient to try for business transformation in the first step.
2. Need to think about not only device telemetry but also diagnostic telemetry.
4. Privacy and security have to be addressed at very early stages.
5. Although the ability to control devices remotely could be quite helpful, in the beginning designers may need to get used to work with devices that provide one-way communication only.
6. Microsoft goal to support in Azure ANY device!
7. https://www.wirelessthings.net
8. Hortonworks Sandbox is a free installation of Hadoop that comes with sample data and tutorials. It could be installed on a personal computer - it's a great tool to start playing with real Hadoop.
9. Lots of interest in R programming. R is used in practically all universities across UK and investment banking. Many R scripts come for free from academia.
10. Practical Data Science and support for it is quite popular within nowadays business activity.
11. Microsoft provides free consulting advises for IoT initiatives.

Some slides:

1. It is expected that interest in IoT will get into initial peak then it may cool off with gradual and steady grows of popularity afterwards:

2. Different level of IoT evolution:

3. ToDo roadmap:

4. Variety of IoT devices:

5. IoT challenges:

6. Pattern to start with:

7. This is what Microsoft offers on Windows Azure for IoT:

8. Some IoT problems that could be solved with Windows Azure:

9.

10.

11. This Event Hub is already available in Windows Azure. In fact we used it in our first lab.

12. Stream Analytics is also already available in Windows Azure. We used it in out second lab.

13. Stream Analytics front-end in Windows Azure looks almost as simple as this diagram:

14. I'm not sure if it's really a 'pattern' but it's good to keep in mind that volume of incoming messages in IoT could be really huge:

15. Possible IoT participants:

16. This slide represents a great desire to keep IoThings under a tight control. We'll see if it would become a reality or stay just a dream:

17. This is what Event Hub on Windows Azure is capable of:

18. When I see such slides I think more and more about Lua, Barracuda Embedded Server and Express Logic:

19. Network security means encryption. I'm not quite sure why does a message from, say, a temperature sensor that has only two fields - IP address and temperature value - have to be encrypted? Keep in mind that millions of such messages would need to be decrypted at the Event Hub on arrival...

20. More about security:

21. It's good to know that there is the IoT Suite. We didn't play with it, so I don't really know how it looks like:

22. More concerns about IoT:

23. I guess that if you would follow one of the last two links, you might find this presentation in an original file:

24. These are three labs that I did on that day. First two required configuration on Windows Azure. In last one I used a Raspberry platform as a sensor that sends messages to the Event Hub configured in the first lab. I should admit that it was quite interesting to do this. Event Hub with Stream Analytics looked very similar to CEP (Complex Event Processing) that I worked with before.

25. Azure community is steadily growing. I have already booked a place for IoT & Data Hackathon in Reading and hope to put some info about it on the web as well:

26. It seems that topics on this slide and many more could be learnt on Microsoft workshops in London for free:

27. More events:

28. More links:

29. And more links:

A Potential Need for Commodity Price Engine

Introduction

Commodities market has experienced significant turbulence in recent times, possible returns and diversification benefits offered by commodities have attracted some investor interest. Derivatives have an important role to play in encouraging a further activity on this market, and this requires wide availability of pricing tools to improve price transparency and investor confidence. However, in contrast to other markets, there is an absence of such pricing tools for commodity derivatives due to their inherent complexities and this is the impetus behind the idea of development of a Commodity Price Engine described in this post.

Situation

Recent fluctuations in demand for raw materials is expected to continue for some time. High volatility in commodities market has led to certain growth in the derivatives market as commodity producers and consumers sought ways to hedge against adverse price movements.

When used for hedging purposes, futures contracts remove the risk of unexpected losses by providing price certainty, but for the same reason they also preclude the possibility of profiting from favourable price movements. As participants become more sophisticated, they naturally turn to options and other derivatives that allow them to obtain more flexible hedges and speculative positions.

At present, participants in the commodity derivatives market comprises primarily of large producers and consumers of raw materials, who have little choice but to use derivatives, usually over-the-counter (OTC), to hedge their positions, and large financial institutions that have the capacity to acquire necessary pricing tools to service this demand. But as regulators push more of these “standard” OTC derivatives onto exchanges to ensure greater transparency and competition, the derivatives market will attract broader class of investors attempting to take advantage of the benefits offered by commodities.

Complication

Although some commodity derivatives are already listed on exchanges and many others are traded over-the-counter, investors interested in entering this market are confronted with issues such as limited liquidity, poor quality of market data, and the absence of accurate pricing tools. These contribute towards the lack of transparency in the way commodity derivatives are valued, which adds to the perception of risks associated with these derivatives.

Liquidity and the quality of market data can only improve with greater activity in these derivatives, and for this to occur there must be more transparency and confidence in the way prices are determined.

Unfortunately, commodity derivatives have inherent complexities that require more advanced pricing tools than those used for derivatives in other markets. Although such tools do exist, their availability is limited to large financial institutions, and are included only in high-end commercial financial software. In order for the derivatives market to flourish, investors need a better understanding of the salient features of commodity derivatives and, more importantly, require access to quantitative tools for independent valuation of these derivatives with higher degree of confidence.

Solution

Commodity Price Engine could implement advanced pricing models for commodity derivatives and deliver these through platforms including the web, smartphones, and tablets. Salient properties of commodity derivatives and observed volatility skews in the market would be fully incorporated into the models to provide accurate valuation and flexible delivery platforms would ensure that these tools are available anywhere with access to the internet.

For reliability and scalability Commodity Price Engine could be deployed on a cloud computing infrastructure and be accompanied by a distributed data server that cleans and smoothes market data. The former ensures that intensive pricing calculations are available even on devices with limited computing power, while the latter eliminates, for most users, the non-trivial task of obtaining reliable market data.

In order to handle large number of concurrent user sessions, Commodity Price Engine could be enhanced with grid computing capabilities to ensure valuation requests receive faster responses even for complex derivatives and large portfolios. These features would enable small to medium sized market participants to independently value and monitor their derivative portfolios with confidence.

Conclusion

Higher returns and diversification benefits of commodities provide attractive trading opportunities and market participants seeking more tailored solutions for their requirements are naturally led to derivatives. With regulators pushing to move standard OTC derivatives onto exchanges, the demand for derivatives have a good chance to increase. A necessary catalyst to transform this increasing interest into growth in market activity is accessible quantitative tools that help bring transparency to this market, and this is precisely the role that Commodity Price Engine may play.

An Idea for a Telco Company

1. CURRENT SITUATION

Introduction of the Cloud removed any constrains in scaling infrastructures for SME companies. Nowadays PaaS and SaaS kind of services became a reality and in many cases it’s a practical and only way to extend business operations without substantial investments in expensive hard- and software.

The nature of software packages evolved to accommodate new runtime environments. Instead of keeping heavy software packages on individual platforms, their compute power is moved to horizontally scalable Cloud servers and their functionality is handled remotely via nice and intuitively understandable GUIs easily accessible from any stationary or mobile device. Modernised and newly created products from Microsoft, Adobe and Google are good examples.

Current technology trends are not industrially finalised yet and keep changing traditional approaches. For the purpose of this message, we could highlight three current distinctive practices:

-    Vendors deliver functionality in a modularised manner, when a consumer can pick up only useful services and pay accordingly,

-    Modularised functionality could be easily extended via well defined APIs that are progressively becoming standard part of such services, and

-    Deployment of customised environments with all selected modules (or services) could be up to 100% automated.

In regards to technical support and maintenance, consumer market has changed as well. Customers try to avoid unnecessary expenses for keeping in-house IT departments and started looking for available services (or service providers) elsewhere. Such demand created a new market for taking services from one or more vendors, combining them into bundles and selling them to right buyers.

2. IDEA

Given that, on the one hand, the market is getting saturated with new cloud-based modularised soft- and hard-ware services empowered by standardised APIs and, on the other hand, consumers look for customisable solutions, it could be a perfect time to build a business that connects one with another.

Such ‘connection’ could be done by creation of reusable scripts (or programs) that would automatically deploy a whole environment for an individual or a group of customers. Such environments should include build-in plug-ins for handling customer-to-Telco and Telco-to-vendor billing.

Scripts could be archived in a Library that would naturally grow covering more and more use cases. The Library would become company ‘know-how’ and its value could be measured by the number of use cases it handles.

3. POSSIBLE SOLUTION

a.     Allocate Cloud servers.

b.    Find vendors of modularised and API-enabled PaaSes and SaaSes.

c.     Create a team to build scripts for automated deployments.

d.     Organise development from epicentre out in agile manner covering more and more functionality within each cycle:

a.     Collect consumer requirements and find most popular scenarios (use cases).

b.    Build and test scripts to meet business requirements in current cycle.

c.     Deploy new environments and allocate some resources for their initial maintenance.

d.     Move scripts to the Library and repeat (d).

REFERENCES:

• APIs for Dummies
• Chief
• Puppet
• Salt Stack
• Docker
• Ansible
• Amazon EC2 API