Wednesday, April 19, 2017

Fintech Disrupts Wealth management

Today a typical mutual fund or a ULIP fund in India charges 2.75% for managing your money.

Plenty of investors would be surprised at what a large proportion of their returns go to expenses. 2.75% sounds like a modest figure. However, that's 2.75% of the total amount, which includes the principal which is yours to begin with. The service you get, which you are paying for, is getting returns on your money. When seen with this perspective, the expenses charged can be very high.

With Robo advisors on the horizon, how long can fund managers charge such high fees?

The concept of "robo-advice" The use of automation and digital techniques to build and manage portfolios of exchange-traded funds (ETFs) and other instruments for investors has gained significant attention within the wealth management industry.

Current robo-advice capabilities remain fairly basic. In general, they use simple surveys to profile clients and to assess their needs. An asset allocation is proposed, adjusted and implemented.
Portfolios are monitored, re-balanced and reported on. Robo-advice streamlines the account opening process, and its ability to transfer assets is increasing. All in all, it represents a useful basket of services at an attractive price

Robo advisor can reduce the fees charged for managing your money to less than 0.5%, and it presents investors with an interesting value proposition.

Although robo-advice to date has gained only a minuscule share of assets under management, I expect Robo-advice to grow rapidly in next few years. I anticipate that competition, innovation and new technology will dramatically increase robo-advice capabilities in the near future. Future
versions will consider the client's complexities by adapting questions based on earlier responses to fully understand investor needs.

In developing a financial plan, they can assimilate multiple goals, including college savings, planned home purchases, retirement, protection needs, estate planning and the need for health care and/or long term care coverage. In proposing investment solutions, they will be able to
incorporate outside assets, handle individual securities, ladder bond portfolios, consider low tax basis holdings, and allocate around illiquid positions. They will help clients understand their portfolios by providing information and learning in the context of the financial results and market information being presented.

There are also elements of the roboadvice experience that clients prefer over traditional models. Investors like the privacy offered by a digital solution and the ability to learn, and to chart their own path. These benefits will be expanded on in future releases.

Over the next decade and beyond, emerging technologies, such as cognitive computing, will power major advances in robo-advice capabilities. We anticipate a rapid evolution towards an automated advisor assistant that can even provide complex advice, and that will also allow clients to interact with the digital assistant in a multi-step process rather than a one-time effort. This will help to serve clients even more effectively.

Over time, investors who have low-cost and reasonably effective alternatives to traditional wealth management programs will not be willing to pay premium prices unless they see real differentiation and value.

Financial advisors will remain central to wealth management, but robo-advice will add new capabilities that wealth management firms will need to adopt and integrate.

Fintech Disrupts Wealth management 

Although a high level of disruption triggered by FinTech is already beginning to reshape the nature of lending and payment practices, a second wave of disruption is making inroads in the
asset & wealth management sectors.

A survey done by Price Waterhouse Cooper's found that this financial houses are already feeling the heat. Nearly 50% of insurers and asset and wealth managers consider their respective industries will be the most disrupted.

The investment industry is also being pulled into the vortex of vast technological developments. The emergence of data analytics in the investment space has enabled firms to hone in on investors and deliver tailored products and automated investing. Additionally, innovations in lending and equity crowd funding are providing access to asset classes formerly unavailable to individual investors such as commercial real estate.

When asked which part of the Financial Services sector is the most likely to be disrupted by FinTech over the next 5 years, 74% of insurance companies identified their own industry, 51% of asset managers said their industry will be disrupted.

Venture capitalists are looking very closely at start-ups dedicated to reinventing the way we invest money and buy insurance. Annual investments in InsurTech start-ups has increased fivefold over the past three years, with cumulative funding of InsurTechs reaching $3.4bn since 2010.

The pace of change in the global insurance industry is accelerating more quickly than what is being imagined. The industry is at a pivotal juncture as it grapples with changing customer behavior, new technologies and new distribution and business models.

Tuesday, April 18, 2017

20 Basic ITIL Metrics


ITIL breaks major IT functions down into nice bite sized processes — ripe to be measured with metrics. Here are 20 of our favorite metrics for ITIL processes:


Incident and Problem Management

1. Percentage of Incidents Resolved by First Level Support 
Support costs can be dramatically reduced when first line support resolves basic issues such as user training, password problems, menu navigation issues etc... The target for this metric is often set above 80%.

2. Mean Time to Repair (MTTR) 
Average time to fix an incident. Often the most closely watched ITIL related metric. It is not unusual for MTTR reporting to go to CxO level executives.

3. Percentage of Incidents Categorized as Problems 
The percentage of incidents that are deemed to be the result of problems.

4. Problems Outstanding 
The total number of problems that are unresolved.


Service Desk

5. Missed Calls
The number of times someone called the help desk, were put on hold and eventually hung up. May include the number of times someone called when the help desk was closed. Impacts customer service and core metrics such as MTTR.

6. Customer Satisfaction 
Usually captured in a survey. Try not to go overboard: asking for feedback in an inappropriate way can irritate customers.

7. Staff Turnover 
Service Desk jobs can be stressful — retaining experienced staff is critical to optimizing core ITIL metrics.


Change Management

8.Number of Successful Changes (change throughput) 
Change throughput is a good measure of change management productivity.

9. Percentage of Failed Changes 
A change management quality metric — can impact customer satisfaction and availability management.

10. Change Backlog 
Total number of changes waiting in the queue.

11. Mean RFC (Request for Change) Turnaround Time (MRTT) 
The average time it takes to implement a change after it is requested.


Release Management

12. Percentage of Failed Releases 
The percentage of releases that fail — a key Release Management quality metric.

13. Total Release Downtime (TRD) 
Total downtime due to release activity.

Availability Management

14. Total Downtime
Total downtimes broken down by service.

15. Total SLA Violations 
Number of times that the availability terms laid out in SLAs were violated.

IT Financial Management

16. Percentage of Projects Within Budget 
The percentage of projects that did not go over/under their prescribed budget.

17. Total Actual vs Budgeted Costs 
Total actual project costs as a percentage of budgeted project costs. Calculated for an entire project portfolio. A number over 100% indicates over spending.


Service Level Management

18. Total SLA violations 
The number of SLA violations in a given period.

19. Mean Time to Resolve SLA Violations 
The average time it takes to restore SLA compliance when a violation occurs.


Configuration Management


20. CI Data Quality
Percentage of CIs with data issues. Can be determined by sampling methods.

Fintech needs DevOps, Analytics & Robotics

Note: This article was co-authored with Saraswathi Ramachandra

Fintech has taken the financial world by storm over the last few years and continues to transform the way people use financial services.

In recent times there has been a definite emphasis on the demand for digital transformation of banking & financial services. Fintech has evolved to address this demand. The term Fintech often refers software applications & tools that provides banking & financial services to customers over Internet.

Fintech also represents a massive digital transformation of banking & financial services. All CEOs of Banks & financial services firms are now aware that Fintech is critical for success.  This digital transformation is making every bank & financial company into a software company.

One of the foundations of digital transformation is using software applications to constantly create new channels to engage customers and to keep employees productive.

Fintech is all about delivering financial services to customers on 24x7x365 and this implies delivering quality software releases that meet or exceed user expectations. The pressure on delivering quality services with software - implies firms will have to deliver software in a continuous mode - also called as DevOps mode of delivery.

DevOps model was developed for Ecommerce & Cloud services - where organizations deploy new software several times a day with a very short development-to-deployment cycles. DevOps transforms the way organizations develop, deploy, monitor, and maintain applications, as well as modifying the underlying infrastructure.

DevOps has quickly evolved from a niche concept to a business imperative and now Fintech companies are striving to incorporate DevOps tools and principles.

In this article, Here are six key points that ensure success of Fintech.

1. For Fintech to be successful, DevOps must have buy-in from leadership

DevOps is not about changing the way software is deployed. DevOps is a way of transforming the way business delivers financial services profitably.

The value of successful DevOps is already quantified. According to the 2015 State of DevOps Report, organizations that effectively adopt DevOps deploy software 30 times more frequently and with 200 times shorter lead times than competing organizations that have yet to embrace DevOps.

They also have 60 times fewer failures, and recover from those failures 168 times faster. Those are impressive numbers and define why succeeding at DevOps is so important for organizations to remain competitive today.

While it takes a new set of tools to implement DevOps, Successful DevOps adoption is more than just a specific set of rules or tools, and it can mean different things to different organizations. There are many definitions about what DevOps is — maybe it's about continuous delivery, or it's about release speed and quality, etc. The important part is that however you define DevOps for your business, your explanation should be clear and consistent.

DevOps is not about release speed — it's about meeting the increasing expectations of consumers. DevOps  is not about continuous delivery — it's about streamlining development and removing deployment hurdles in order to function more efficiently.

As Fintech solutions evolves, DevOps becomes the key to deliver changes rapidly. If top leadership is not buy into the DevOps model then it's a much greater challenge - to succeed.

To succeed in Fintech, DevOps must reach its full potential. This implies changing the way the organization fundamentally operates and that requires leadership support to approve, support, and in some cases be willing to lead this transformation.

2. Fintech Software quality is measured by customer experience

Fintech success greatly depends on meeting or exceeding customer expectations. Fintech software is not just a bundle of software, it is about how the bundle of software come together as a whole and offer meaningful, timely and valuable services to customers.

In hyper-competitive landscape, software has to be delivered continuously and with quality. DevOps is the process that delivers continuous improvements. DevOps also addresses the need to streamline software development and removing deployment hurdles in order to function more efficiently.

Knowing the quality of customer experience implies collection of metrics. One needs to look holistically about metrics. Collecting & analyzing metrics which tell how effectively customers are using the software and how well the software is working.

This implies measuring standard ITIL metrics such as Mean Time To Resolution (MTTR) or Mean Time Between Failure (MTBF), Mean RFC Turnaround Time (MRTT), Total Release downtime (TRD) etc can give a lot of meaningful data. But it may not be effectively measuring what customers doing and how well the software is working, this requires Application Performance Monitoring tools.

3. Application Performance Monitoring tools are critical for Fintech

How well a software performs has a direct impact on customer experience. For example, if a transactions take additional time to complete, then customers will not be satisfied with the product.

This implies measuring application performance. There are several tools that measure application performance: Tools that measure application response times, Application read/write latency,  Application resource utilization, Simulated synthetic transaction times etc. This will help spot problems in real-time and respond quickly to mitigate problems.

The key with APM is that it can provide rapid situational awareness or instant visibility into emerging problems so that the right actions can be taken immediately to avoid negative user impact. When APM is integrated with DevOps, software development teams can know what is happening at customer site and respond quickly. This can ensure quality customer experience.

4. Fintech needs lots of data collection & analytics

Analytics are essential for all areas of business, especially when it comes to improving your software strategy. In order to make sure your applications always live up to the quality expectations of your users — and to stay ahead of your competition — investing in an effective analytics solution should be your main priority.

Fintech requires collections of vast amount of data - both in terms of machine telemetric data, APM metrics, DevOps Metrics, ITIL metrics, customer usage metrics ( when, where, how, often) etc.

This data must be analyzed. An ideal analytics solution will be capable of easily correlating application performance with user engagement and business data in order to ensure that all software decisions support and drive desired financial outcomes.

Fintech requires agility in all aspects of business. Manual processes and human intervention impede that agility as they are time-consuming and prone to error.  Analytics also enable for rapid automation. Once data is analyzed and results are known, several decisions and executions can be automated. This has led to a whole new field of software robotics in banks that can automate repetitive tasks for a more efficient workflow.

For ICICI Bank, these "software robots" have been deployed across functions in retail banking, agri-business, treasury, trade and forex. Software robots are being used to automate 20% of  banking transactions. The bank is expecting a significant improvement in its cost-to-income ratio once the initiative is rolled out in full.

Analytics is the compass that guides Fintech. The success of Fintech software is not in the software itself - it is how fast one can measure the effiency, effectiveness of the software and how quickly it can be improved.

Fintech is not just about the software itself;  It's about how that software connects with customers and partners to complete financial transactions - which generate greater value to users.  Understanding the value of analytics as a key element of success is crucial for long term success of Fintech products.

5. Fintech is not just about Software — it's also the way business operates

While Fintech delivers financial services to customers in a fast & efficient manner. Behind the software there is a whole big organization that needs to evolve to deliver quality software in fast continuous mode. Fintech requires continuos development, continuos integration and continuos delivery. The key to success is managing  the development and operations.

Fintech has evolved beyond a strictly software concept. Fintech involves software, IT tools,  applications, and the delivery of tech-based financial services, which in today's digital world is the responsibility of everyone in the company.

Effective Fintech operations involves the whole company collaborating more closely. Even a strictly IT based project touches other teams and departments — like HR or accounting. Those interactions can be roadblocks if they're bogged down in corporate bureaucracy.

Traditional banking corporate structures and processes inhibit efficient collaboration and impede productivity. DevOps culture is about breaking down silos, removing barriers, and improving communication between teams so employees are empowered to get things done faster and more effectively at the same time. It's important to make sure that everyone  understands the business importance of Fintech software, applications, and the competitive advantages of being more agile.

6. Successful Fintech solutions requires constant feedback and feed forward cycles

Fintech is based on agility. Agility implies faster collaboration within the banking organization and faster response to customer issues. The software tools and business processes for Fintech has to be built to deliver feedback or feed forward information throughout the organization.

Rapid data collection, data analytics helps in getting customer feedback in real time and this feedback can be passed to different functions of the bank. In order for different functions of the bank to interact smoothly and provide input that has value, one must have tools capable of focusing on different elements of the Fintech process that can present information in a context that's relevant to each group audience.

Contextual relevance is particularly important in feedback systems. Business operations must create dashboards that present information that matters to them. This enables all groups to monitor current operations and respond in ways that helps the whole organization function more efficiently.

Thursday, April 13, 2017

Fintech is built on Microservices


Today, we have the web at our fingertips. We are now deeply connected to Internet for most parts of our daily life. We are moving whole business segments from brick and mortar to the online space. That's not really big news - it is just called as progress and we observe it with more or less interest day in, day out. With the digitalization also comes a shift in the nature of the services offered to us. Consumers will change, the service landscape will change and banks will need to adapt - which means they will drastically change, too.

Customer centricity and brand value experiences are key for Banks

Banks are institutions which touch a multitude of business services. Banks are trusted by the customers more than any other business. If banks make use of their trustworthiness and develop a strong and intelligent branding, they have the chance to not only endure the great transformation of our service landscape, but to step out of it as the big winner.

Until then, banks will have to be open to tremendous structural alteration and put some serious effort into developing better customer experience. Because the change of the service landscape as we know it brings along increasingly sophisticated customers who are subjected to distractions from countless competing products and providers. If a bank can create an exceptional customer journey, it will rise again. If it cannot, it may just sink like a stone. Time to make a move, banks!

FinTech is now built on microservices

In the past two years, I have seen how Fintech has changed finance and banking . In next 20 years, banks will be a hub for financial services in one way or another, with these services developed in cooperation with, or solely by, third-party companies.

In retail finance, we can observe another trend: fragmentation. For ages, banks have been managing all the financial needs of everyone. Want to store your money securely? Bank. Need a loan for your house or your business? Bank. Need to transfer money? Bank. Especially these two areas of the banking business – lending and payment – have been subject to disruption by smaller competitors for some years now and banks have lost tremendous revenue to innovative and tech-savvy fintech companies. What used to be in the hands of very few institutions has been split up between numerous competitors.

There were only one a handful of options to get a loan ten years ago, which were mostly extremely time-consuming and involved providing loads of information about yourself. In this day and age you can choose between many online-lenders using sophisticated algorithms to calculate which loan you qualify for and you will receive the money only hours later. Payment has changed on several levels: not only are there several major service providers which integrate seamlessly into your preferred apps and services. But there are even alternative currencies such as Bitcoin and Ethereum based on the blockchain system.

Other areas will follow and the finance market will arguably become increasingly fragmented with more but smaller service providers, offering more diverse and individual products. Finance serves as a great example for how a new change is coming about, as the fintech scene is booming and most consumers have already used basic fintech products, if they are aware of this or not.

Still, this is only the tip of the iceberg in fintech and analogous to this, many business segments are already evolving. Or are about to.

Bank will become a hub for multiple types of services

In the past two years, I have seen how Fintech has changed finance and banking . In next 20 years, banks will be a hub for financial services in one way or another, with these services developed in cooperation with, or solely by, third-party companies.

Banking and finance are changing and so will insurance, healthcare, automotive, education and even agriculture or legal services. Many areas are ripe for disruption. Through collaboration and partnerships, banks, insurances, healthcare etc., could build strong bonds with customers and build a strong brand.

Introduction to Microservices

Microservices are a type of software architecture where large applications are made up of small, self-contained units working together through APIs that are not dependent on a specific language. Each service has a limited scope, concentrates on a particular task and is highly independent. This setup allows IT managers and developers to build systems in a modular way. In his book, "Building Microservices," Sam Newman said microservices are small, focused components built to do a single thing very well.

Martin Fowler's "Microservices - a Definition of This New Architectural Term" is one of the seminal publications on microservices. He describes some of the key characteristics of microservices as:

Componentization: Microservices are independent units that are easily replaced or upgraded. The units use services to communicate with things like remote procedure or web service requests.

Business capabilities: Legacy application development often splits teams into areas like the "server-side team" and the "database team." Microservices development is built around business capability, with responsibility for a complete stack of functions such as UX and project management.

Products rather than projects: Instead of focusing on a software project that is delivered following completion, microservices treat applications as products of which they take ownership. They establish an ongoing dialogue with a goal of continually matching the app to the business function.

Dumb pipes, smart endpoints:
Microservice applications contain their own logic. Resources that are often used are cached easily.

Decentralized governance: Tools are built and shared to handle similar problems on other teams.



History of microservices

The phrase "Micro-Web-Services" was first used at a cloud computing conference by Dr. Peter Rodgers in 2005, while the term "microservices" debuted at a conference of software architects in the spring of 2011. More recently, they have gained popularity because they can handle many of the changes in modern computing, such as:

  • Mobile devices
  • Web apps
  • Containerization of operating systems
  • Cheap RAM
  • Server utilization
  • Multi-core servers
  • 10 Gigabit Ethernet


The concept of microservices is not new. Google, Facebook, and Amazon have employed this approach at some level for more than ten years. A simple Google search, for example, calls on more than 70 microservices before you get the results page. Also, other architectures have been developed that address some of the same issues microservices handle. One is called Service Oriented Architecture (SOA), which provides services to components over a network, with every service able to exchange data with any other service in the system. One of its drawbacks is the inability to handle asynchronous communication.

How microservices differ from service-oriented architecture

Service-oriented architecture (SOA) is a software design where components deliver services through a network protocol. This approach gained steam between 2005 and 2007 but has since lost momentum to microservices. As microservices began to move to the forefront a few years ago, a few engineers called it "fine-grained SOA." Still others said microservices do what SOA should have done in the first place.

SOA is a different way of thinking than microservices. SOA supports Web Services Definition Language (WSDL), which defines service end points rigidly and is strongly typed while microservices have dumb connections and smart end points. SOA is stateless; microservices are stateful and use object-oriented programming (OOP) structures that keep data and logic together.

Some of the difficulties with SOA include:
SOA is heavyweight, complex and has multiple processes that can reduce speed.
While SOA initially helped prevent vendor lock-in, it eventually wasn't able to move with the trend toward democratization of IT.

Just as CORBA fell out of favor when early Internet innovations provided a better option to implement applications for the Web, SOA lost popularity when microservices offered a better way to incorporate web services.

Problems microservices solve

Larger organizations run into problems when monolithic architectures cannot be scaled, upgraded or maintained easily as they grow over time. Microservices architecture is an answer to that problem. It is a software architecture where complex tasks are broken down into small processes that operate independently and communicate through language-agnostic APIs.

Monolithic applications are made up of a user interface on the client, an application on the server, and a database. The application processes HTTP requests, gets information from the database, and sends it to the browser. Microservices handle HTTP request response with APIs and messaging. They respond with JSON/XML or HTML sent to the presentation components. Microservices proponents rebel against enforced standards of architecture groups in large organizations but enthusiastically engage with open formats like HTTP, ATOM and others.

As applications get bigger, intricate dependencies and connections grow. Whether you
are talking about monolithic architecture or smaller units, microservices let you split
things up into components. This allows horizontal scaling, which makes it much easier to
manage and maintain separate components.

The relationship of microservices to DevOps
Incorporating new technology is just part of the challenge. Perhaps a greater obstacle is developing a new culture that encourages risk-taking and taking responsibility for an entire project "from cradle to crypt." Developers used to legacy systems may experience culture shock when they are given more autonomy than ever before. Communicating clear expectations for accountability and performance of each team member is vital. DevOps is critical in determining where and when microservices should be utilized. It is an important decision because trying to combine microservices with bloated, monolithic legacy systems may not always work. Changes cannot be made fast enough. With microservices, services are continually being developed and refined on-the-fly. DevOps must ensure updated components are put into production, working closely with internal stakeholders and suppliers to incorporate updates.

The move toward simpler applications.

As DreamWorks' Doug Sherman said on a panel at the Appsphere 15 Conference, the film-production company tried an SOA approach several years ago but ultimately found it counterproductive. Sherman's view is that IT is moving toward simpler applications. At times, SOA seemed more complicated than it should be.

Microservices were seen as an easier solution than SOA, much like JSON was considered to be simpler than XML and people viewed REST as simpler than SOAP. We are moving toward systems that are easier to build, deploy and understand. While SOA was initially designed with that in mind, it ended up being more complex than needed.

SOA is geared for enterprise systems because you need a service registry, a service repository and other components that are expensive to purchase and maintain. They are also closed off from each other.

Microservices handle problems that SOA attempted to solve more than a decade ago, yet they are much more open.

How microservices differ among different platforms
Microservices is a conceptual approach, and as such it is handled differently in each language. This is a strength of the architecture because developers can use the language they are most familiar with. Older languages can use microservices by using a structure unique to that platform. Here are some of the characteristics of microservices on different platforms:

Java
Avoids using Web Archive or Enterprise Archive files
Components are not auto-deployed. Instead, Docker containers or Amazon Machine Images are auto-deployed.

Uses fat jars that can be run as a process

PHP
REST-style PHP microservices have been deployed for several years now because they
are:

  • Highly scalable at enterprise level
  • Easy to test rapidly


Python

  • Easy to create a Python service that acts as a front-end web service for microservices in other languages such as ASP or PHP 
  • Lots of good frameworks to choose from, including Flask and Django
  • Important to get the API right for fast prototyping 
  • Can use Pypy, Cython, C++ or Golang if more speed or efficiency is required.


Node.js
Node.js is a natural for microservices because it was made for modern web applications.
Its benefits include:

  • Takes advantage of JavaScript and Google's high-performance, open-source V8 engine
  • Machine code is optimized dynamically during runtime
  • HTTP server processes are lightweight
  • Nonblocking, event-driven I/O
  • High-quality package management
  • Easy for developers to create packages
  • Highly scalable with asynchronous I/O end-to-end


.NET

In the early 2000s, .NET was one of the first platforms to create applications as services
using Simple Object Access Protocol (SOAP), a similar goal of modern microservices.
Today, one of the strengths of .NET is a heavy presence in enterprise installations. Here
are two examples of using .NET microservices:





Responding to a changing market

The shift to microservices is clear. The confluence of mobile computing, inexpensive hardware, cloud computing and low-cost storage is driving the rush to this exciting new approach. In fact, organizations do not have any choice. Matt Miller's article in The Wall Street Journal sounded the alarm; "Innovate or Die: The Rise of Microservices" explains that software has become the major differentiator among businesses in every industry across the board. The monolithic programs common to many companies cannot change fast enough to adapt to the new realities and demands of a competitive marketplace.

Service-oriented architecture attempted to address some of these challenges but eventually failed to achieve liftoff. Microservices arrived on the scene just as these influences were coming to a head; they are agile, resilient and efficient, qualities many legacy systems lack. Companies like Netflix, Paypal, Airbnb and Goldman Sachs have heeded the alarm and are moving forward with microservices at a rapid pace.