Few years ago I watched a bank's branch working process.
Senior Bankers received a digital card which should be passed prior to executing operations requiring higher level of Authorization.
Other bankers has lower Authorization level. They did not receive these cards. They are prohibited from executing high level authorized operations.
The Computerized Branch systems were built according to the defined Authorization levels. However, Senior Bankers were busy. When another banker asked a senior banker to perform an operation very often he gave him his digital card instead of executing the operation and asked him to execute the operation behalf of the Senior and Busy Banker.
The real Authorization system was different from the formal analyzed, designed and developed systems.
The real system authorized every banker to execute most operations.
The formal system limited Authorization of non-Senior Bankers.
This kind of dissonance between implemented systems and real life systems is very common in other verticals as well as well as in other banks.
The most confident Business data and Reports
It includes data about Strategy, New R and D and new Products, Plans and reports and data summarizing overall Business Performance.
If such data will leak competitors could gain and the company's Business Results could be worse than the Results achieved if the data would not leak.
Naturally, only Top Management team members are authorized to access this data.
However, Top Managers are even busier than Senior Bankers.
They will do exactly what the Senior Bankers depicted in the previous section did:
They will give authorization to their Secretaries.
The real Authorization system is again different from the planned Authorization system.
Are the over authorized secretaries a bigger Security threat than the Top Management?
The Top Managers
A Top Manager can benefit a lot from not breaching Security by exposing or selling confidential data.
His salary is high and he may receive high bonus as well.
If he will sell confidential data to a competitor he may lose everything: No more high salary and high bonus but more than this: no other company will ever employ him as a manager.
The probability that CEO or other top manager will sell the most important confidential data to a competitor is extremely low.
It is reasonable that he is aware of the potential risk of exposing such data unintentionally to people who are not authorized to access it and avoid of that risk.
The Secretaries
A Secretary selling confidential data can lose less and win more than a Manager.
Her salary is far from being a high salary. She does not expect, and probably will never get, high bonus.
She may operate a little shop or other type of small business instead of working as a secretary.
The probability that she will breach Security and deliver intentionally confidential data is low, but it is significantly higher than the probability that a Top Manager will do it.
As far as exposing a printed report unintentionally is concerned, I am not so sure that the probability that a Manager's Secretary will do it is low.
It is all about Security Awareness. The Manager should be more aware and probably the Security team will periodically remind him of the Security requirements due to the high formal authorization granted to him.
Saturday, December 10, 2016
Tuesday, July 26, 2016
Do not ask: why Yahoo! is for sale? ask: why Verizon is acquiring Yahoo!?
According to Bloomberg, Verizon Communication Inc. has emerged as the most likely buyer of Yahoo! Inc.
The deal will may be announced in few days.
Nobody is surprised that Yahoo! is going to be acquired. It is a strong brand with quite good software products. However, for many years its Business results were not good enough.
Yhaoo!'s Search Engine was a leading product until Google dominated the market.
Since than Yahoo! replaced its top management and its strategy frequently.
It tried to acquire Google and Facebook and Microsoft tried to acquire it on 2008.
Yahoo!'s most successful investment was buying 35% of Ali Baba's stocks on 2005. 40% of its Ali Baba stocks were sold on 2012.
Other Yahoo!'s assets
Flickr - an Image hosting and Video hosting website
content services such as Yahoo! Finance
Tumblr - microblogging and social networking website
Communication services such as Mail, Messenger, Chat, Maps etc.
Why would a Telco company acquire Yahoo!?
Verizon is the largest USA based Telco company. On 2012 I mentioned Verizon Wireless's SOA implementation as an example of successful SOA implementation.
The reason that a Telco company will buy a company, which is less related to Telco is the diminish of its traditional Business Line, i.e. Voice Phone Calls, due to Voice over IP.
The same reason explains why a decade ago there were many successful Telco SOA implementations.
These companies need SOA Agility in order to transform their Business. For more details, read a post I wrote on 2013: IT and the Communication Industry.
Verizon's ambitious Goal
Verizon acquired Yahoo! in order to compete in the growing Mobile Advertising market.
Yahoo!'s advertising software is far from competing successfully with Google's advertising. However, Mobile Advertising is not yet mature.
Verizon will try to compete in this market with Google and Facebook.
Verizon already acquired AOL on 2015. AOL, a large mass media corporation was acquired for the same purpose.
In addition to its software Yahoo! contribute two significant assets which may support Verizon in accomplishing its ambitious goal. These assets are 200 million users and a strong brand.
The deal will may be announced in few days.
Nobody is surprised that Yahoo! is going to be acquired. It is a strong brand with quite good software products. However, for many years its Business results were not good enough.
Yhaoo!'s Search Engine was a leading product until Google dominated the market.
Since than Yahoo! replaced its top management and its strategy frequently.
It tried to acquire Google and Facebook and Microsoft tried to acquire it on 2008.
Yahoo!'s most successful investment was buying 35% of Ali Baba's stocks on 2005. 40% of its Ali Baba stocks were sold on 2012.
Other Yahoo!'s assets
Flickr - an Image hosting and Video hosting website
content services such as Yahoo! Finance
Tumblr - microblogging and social networking website
Communication services such as Mail, Messenger, Chat, Maps etc.
Why would a Telco company acquire Yahoo!?
Verizon is the largest USA based Telco company. On 2012 I mentioned Verizon Wireless's SOA implementation as an example of successful SOA implementation.
The reason that a Telco company will buy a company, which is less related to Telco is the diminish of its traditional Business Line, i.e. Voice Phone Calls, due to Voice over IP.
The same reason explains why a decade ago there were many successful Telco SOA implementations.
These companies need SOA Agility in order to transform their Business. For more details, read a post I wrote on 2013: IT and the Communication Industry.
Verizon's ambitious Goal
Verizon acquired Yahoo! in order to compete in the growing Mobile Advertising market.
Yahoo!'s advertising software is far from competing successfully with Google's advertising. However, Mobile Advertising is not yet mature.
Verizon will try to compete in this market with Google and Facebook.
Verizon already acquired AOL on 2015. AOL, a large mass media corporation was acquired for the same purpose.
In addition to its software Yahoo! contribute two significant assets which may support Verizon in accomplishing its ambitious goal. These assets are 200 million users and a strong brand.
Wednesday, June 29, 2016
Microsoft's LinkedIn acquisition: more warning signs ahead or a potential for improvement?
 |
| LinkedIn headquarters on Sterlin Court in Mount View California source: Wikipedia |
Microsoft and LinkedIn announced on 13th June that they have entered into a definitive agreement under which Microsoft will acquire Linkedin for 196 USDs per share in an all-cash transaction valued 26.2 billions.
On 2011 Microsoft acquired Skype. I had seen Warning Signs ahead. Will the agreed acquisition of LinkedIn stimulate new Warning signs?
On 2013 Microsoft acquired Nokia in order to compete in the Smartphones market. Microsoft is not a significant player in the Smart phones market.
Will Microsoft fail, as well, in the Social Networks market?
When Steve Ballmer stepped down as the CEO of Microsoft I updated my Vendors Survival post about Microsoft.
Almost a year afterward I revisited my forecast and I was more optimistic.
The reason for my optimism was Satya Nadella's new strategy: Cloud First.
Will Linkedin proposed acquisition be an additional step in the right direction?
Linkedin is a kind of Social Network. As far as the number of users is concerned, It is smaller than Facebook and Twitter.
Facebook has 1.65 billion active users, Twitter 310 million active users. Google+ 111 million users and LinkedIn 106 million users.
Facebook's revenues for 2015 were 17.928 billion USDs. Twitter revenues for 2015 were 2.21 billion USDs. LinkedIn revenues for 2015 were 2.99 billion.
Facebook has approximately 12,600 employees. Twitter 3,900 and LinkedIn 9,700 employees.
Probably, you do not need the data above in order to conclude that Facebook is the Leader of the Social Networks market.
It should be noted that the number of LinkedIn's employees is more than 2.5 times the number of Twitter's employees. It is more than 0.75 of the number of giant Facebook.
The relative large number of employees could be an indication of inefficiency and/or an indication of more complex systems.
LinkedIn is unique because it is a professional Network. Facebook and Twitter are Social networks.
However, the boundaries between Social and Professional are not clear.
For example, I am a member of two Cloud Computing groups. No doubt, that the LinkedIn group is professional, but is not the Facebook group professional as well?
Additional Functionality
As a professional Network, LinkedIn added functionality which is not required in a Social Network. For example, a resume and an endorsement mechanism.
Does the development and maintenance of additional functionality explains the relative high number of LinkedIn employees? probably it explains part of the additional employees number.
The other part should be explained by less efficiency.
If you are less efficient than your competitors you net income is lower. According to Wikipedia' Twitter's net income in 2015 was 521 million USD. LinkedIn net income in 2015 was only 166 million USD.
If you are less efficient than your competitors , you probably need that a larger company will acquire you.
First Take of LinkedIn future acquisition
It is a manifestation of a new Microsoft trying to compete in a new market of Social Networks.
Facebook and Google are players in that market.
Microsoft is not competing directly with market Leaders, such as Facebook, but will be a Leader in Niche.
It is a significant Niche of Professional Networking.
The Key Issues are:
1. is the price Microsoft is willing to pay for that acquisition a reasonable or is it too high?
In February 2016, following an earning report, LinkedIn shares dropped 43.6% within a single day.
Is this a Warning Sign?
2. Will LinkedIn efficiency improved?
3. Can Microsoft improve LinkedIn Business Model so LinkedIn revenues will grow?
LinkedIn revenues model is based on Advertisement. Will Microsoft be able to create new revenues sources or better Advertisement revenues model?
4. Will Microsoft and Linkedin Innovate and/or find additional Use Cases for LinkedIn technology?
Internal Enterprise Electronic Social Network Services is an example of additional Use Case.
LinkedIn could build a network for Microsoft's employees. Business Partners may join that network.
The new Professional Network would be based upon current LinkedIn offerings.
The network could enable better execution by Microsoft.
The same product could be sold to other companies by LinkedIn.
5. Will LinkedIn be independent entity or a unit within Microsoft?
On the one hand, Merge is not as difficult as merging two large companies, but it could be a death verdict for LinkedIn and its products and another failed investment.
On the other hand, LinkedIn's Business management should be improved.
Will Microsoft and LinkedIn find an optimal solution to this conflict?
Conclusion
Many question marks are included in the previous section.
I am not sure that this acquisition will be a failure such as Nokia acquisition, but the probability that this acquisition will leverage Microsoft's business is low.
Wednesday, May 11, 2016
Personal Devices Security lessons learned from my mistakes
 |
| A broad metal chain made of torus-shaped links Source: Wikipedia |
9 years ago I wrote a post titled: The Chain is as Strong as the Weakest Link in the Chain.
Based on my experience in a Penetration Test, I argued that human beings are the weakest link.
Many employees Security awareness is insufficient. Few employees are even motivated to breach Security.
As far as the home computing or the consumers computing is concerned, there is even less Security Awareness than in organizations.
I am a Security and Risk Management expert, therefore I should be aware of Cyber and Security threats and I should refrain from being damage by these threats.
I am certainly aware of them, however I failed twice by ignoring a potential threat.
This post is about lessons learned from my Security protection failures.
I love you - I hate you
Many years ago I received an e-mail message from a friend. My friend is an IT expert, who participated in a Security Software product development.
I did not suspect that the link I Love you will install a worm in my PC. I opened the link and the worm changed my Windows Registry file.
It duplicated itself as part of e-mail messages that was sent to all the people included in my address book.
I was aware of the problem shortly after my careless mistake.
A young guy whose girlfriend decided to end their relationship coded a worm using Windows Visual Basic Script and spread it.
The worm was named I Love you.
Cleaning my computer from I love you
1. I warned all my e-mail connection not to open the message.
2. I checked that I have an updated backup file.
3. I found and executed a program named "I Hate you" which was documented as a cure for "I Love you".
4. Few months later I discovered that the worm was not moved from JPEG files. Anytime I tried to open a JPEG file the worm was send by e-mail to all my connections.
5. I found another solution to the problem by searching the Web.
The new solution was not automatic. I had to clean the System and the Registry systematically step by step.
The Facebook Bear is a Worm
Recently I received few Facebook messages from a Facebook friend.
My Facebook friend is a Computers expert. The messages were part of a discussion on Bridge, however, a link to a video was included.
I pressed the link showing a bear which surely does not play Bridge.
The video was a Facebook Worm. All my Facebook friends received immediately a message from me including the Worm.
Cleaning my computer from The Facebook Bear
1. I warned all my Facebook friends by writing on my timeline that I was infected by a worm and they should not press the hyperlink included in the message sent by the worm and not by me.
2. I closed Facebook and open it again and Facebook notified me that a Trend Micro Security program is automatically checking and cleaning my Facebook application and data.
The program corrected the Security problem.
3. I deleted the infected message.
Analysis and Conclusions
In both cases I lowered my Security awareness because the sender was an Information Technology expert and because the sender is a friend of mine who sends many messages.
Quick identification of a Security breach was a key in solving the problem.
Lesson Learned
1. Always be alert and ready to identify Security threats.
2. Suspicious hyperlinks are suspicious hyperlinks. It does not matter who the message sender is.
3. In most cases it is possible to solve a Security problem, but quick problem identification is a must.
4. Notify all your connections about possible messages sent from your computer by worms. Tell them to ignore the message and to scratch it without reading it.
5. Do not postpone worms and viruses removal. As soon as you discover the problem stop working and try to fix the problem.
5. Full problem correction is a must.
Monday, April 4, 2016
Public Cloud Core Banking: Vendors Hype or Short term Reality?
Many large banks are IBM Mainframes users. They use mainframes for decades. They use other platforms as well, but their Core Banking systems are deployed on Mainframes.
Recently leading Cloud Computing vendors such as Amazon, Microsoft and Google approached large banks in order to start migration of systems to their Public Clouds.
I looked for evidence supporting the notion that Banks are transforming from Mainframes to Public Clouds. I found no evidence.
I am not the one to be blamed for not finding any significant evidence, because there is no evidence supporting the notion cited above.
Banks are using Public Clouds but...
Like many other organizations, banks are using Public Clouds applications. However, they do not use it for Core Banking systems deployment.
They use Public Clouds for applications which are less integrated with the Core Banking systems.
If they will not use Public Clouds for Core Systems, IBM Mainframes will be used for many years.
Public Clouds, Private Clouds or Hybrid Clouds
The answer to the question: Which type of Clouds are you using or you will use in the next years? will vary.
SMBs' frequent answer would be: Public Clouds
Large Enterprises' frequent answer would be: Hybrid Clouds.
Hybrid Clouds usage is based upon both Private Clouds and Public Clouds.
If you read a previous post titled: The Next generation of Private Clouds, you probably noticed that, according to Forrester Consulting's survey, building Private Clouds is a priority for nearly half of the large enterprises surveyed.
You may also noticed that 67% of the survey respondents said that access to Mainframe Data was critically important or very important in Clouds environments.
Conclusions
1. Large enterprises will continue to use Mainframes.
2. Large Enterprises will use Hybrid and Private Clouds. Mainframes will be part of Private Clouds.
Large Banks will not migrate of Mainframes to other platforms if they considering including Mainframes in their Private Clouds.
Business Barriers to Migration from Mainframes
Is there a Business Case for migrating Core Banking systems from Mainframe?
It is difficult to justify such a large and expensive endeavour.
The CEO or another manager would ask: What would we get for this multi year expensive endeavour?
The answer would probably be the same functionality.
Not the best answer for convincing Business oriented non-tech managers to spend a large amount of money.
Risks
1. resistance to change
Many of the current elderly Mainframe team members will not be able to adjust to new platforms and new development paradigm and tools. They are afraid of losing their jobs.
Some of them will resist the change and will not cooperate.
2. losing expertize
The IT staff maintaining current Core Banking systems has limitations, as far as new technologies and architectures are concerned, however some of the employees have deep understanding of current systems and the Bank's Business processes and Business goals.
They also know a lot about the Organizational Culture and about people working in the Business departments.
Many of these employees will retire or will be fired.
The new young energetic employees, replacing them, lack understanding and knowledge of the Business, the Organization and the People.
3. Bugs
Even in case of no resistance to change do not expect 100% accurate migration.
New bugs introduced to the new system imply cost and less satisfied customers.
3. missing Functionality
Undocumented functionality will not be part of the new Core Banking Systems.
The assumption that the documentation of complex old systems is full and accurate is an unrealistic assumption.
4. missing Data
Replace the word Functionality in the previous section by Data. Do not expect 100% precise data migration.
5. Misinterpreted Business Processes
The Challenges to BPM implementations include lack of Visibility and non-documented processes.
If the Bank migrating from Mainframe, did not complete its BPM implementation, some Business Processes in the new non-mainframe systems will not be identical to current Business
6. Co-existence and Migration process
After completion the development of new systems, these systems should be deployed.
Anything could get wrong during the actual migration process.
Additional Challenges
1. Security
Mainframes Security is better than other platforms Security.
In addition to the gap between Mainframe Security and Windows Security and Linux Security in non Cloud based environment, there is an issue of Public Cloud Security.
I am not sure that in house Linux and Windows based systems are more secured than Public Cloud based Linux and Windows systems.
However, customers perceive them as less secure because they are managed by employees of another company and because their systems shared resources with other enterprises' systems.
Systems and Data Security is more important to banks than to many other enterprises.
2. processing Large Amounts of Data
Mainframes are capable of processing large amounts of Data. High percentage of Business Data resides on Mainframes.
3. Scalability and Workloads Management
Current Public Clouds are based on Hypervisiors, Windows and Linux.
Are these Operating Systems capable of supporting large amount of concurrent Banking Transactions?
I doubt. My experience, as well as others experience, do not support the assumption that these Operating Systems will be capable of supporting and managing properly large number of concurrent Banking transactions.
Reasons to replace current mainframe Core Banking systems
1. Maintenance
Maintenance of old Legacy systems could be a nightmare.
Many of the people we wrote the programs 20 years or 30 years ago are not available.
The systems are not architectured well and are not structured properly. Usually the systems are large monolithic silos.
The code was changed many times by many different people.
2. lack of Agility and a long Change Backlog
The lack of Agility is an additional maintenance difficulty.
The Business result of the difficulty to change systems is a long list of unfulfilled change requests.
3. Skills unavailability
Young professional prefer to work with mainstream technologies and/or new innovative technologies. Gradual skills decline is a real problem in Mainframes environment.
Are there non-migration alternatives?
Basically there are two alternatives addressing Mainframes concerns without risky migration to other platforms:
1. Modernization
Systems modernization could be performed without migration.
The Modernized systems could be Service Oriented and may use advanced modern technologies, which are available on Mainframes.
It is not a Big Bang risky approach but it is still a long journey. Those who will decide to modernize their Mainframe Core Banking systems will use Mainframes for more than Short Term period.
However, after completing systems Modernization they will be capable of gradual and relatively smooth migration, if they will decide to migrate.
2. Core Banking Packages
Core Banking systems could be replaced by Core Banking packages. These packages resemble ERP products. Some of these packages can be deployed on Mainframes and on other platforms as well.
An endeavour of choosing a Core Banking Package and replacing current Core Banking Systems by it is also a long journey. Usually it is a longer journey than Modernization.
After completing the journey maintenance could be easier and cheaper, the dependency on employees is reduced and future gradual or complete migration from Mainframe is smoother and cheaper.
Migrated from Mainframe but not the Public Cloud
After long journeys to Modernization or Core Banking packages the last thing you would think of is another migration from Mainframes to another platform.
Few years later you may start migration to another platform. Even if someone will migrate to Linux or Windows the systems are still deployed in his Private Cloud (or not in any Cloud).
There are still significant barriers to Public Cloud based deployment.
I will name few major barriers: Local Regulation, International Regulation (e.g. Basel 3), Security and integration with other systems in the Data Center and in other Public Clouds.
Real World Case Studies? - Capital One
Amazon's leading Early Adopter is Capital One.
Capital One is a Credit Cards company and a Large Bank.
Capital Bank is using Open Source software, Microservices and Devops. Capital is performing transformation to Digital Banking.
Capital Bank's CIO Rob Alexander presented a Keynote presentation in last October at Amazon's re:Invent conference.
Alexander described how they start experimenting AWS in 2014 and how late in 2015, they launched production Mobile Banking applications based on Amazon's AWS.
I guess that the Mobile applications are using Mainframe Core Banking Applications and Data.
According to Capital One's CIO "the bank has been working closely with Amazon's team to develop the Security model".
For more details read:
AWS Case Study: Capital One
AWS reinvent 2015 keynote - Rob Alexander
The private Security model will be only the first step in a long process of development of industry Security standards and implementing these standards.
Me Bank
Me bank is a full fledged retail bank. The Melbourne-Headquartered company manages 20 billion $ in assets and has 800 employees who support 280,000 customers around Australia.
Amazon AWS is used for Development and Testing.
The Core Banking systems reside in the bank's Data Center.
For more details read:
AWS Case Study: ME Bank
ME Bank is not a large bank. I do not know if the Core Banking Systems were deployed on Mainframes.
If they were, I would not predict migration from Mainframe in the following 5 years.
Microsoft's partner: Capgemini
Capgemini partnered with Microsoft in order to provide Cloud based Services in Microsoft's Azure.
I did not find Case Studies in Capgemini's white paper Cloud Computing In Banking.
However, I found the following text: " Banks are expected to enter the cloud computing arena cautiously, with no single cloud services delivery model being a silver bullet for best meeting their demanding business needs".
Capgemini's white paper also discussing the first methodological step of choosing the right cloud model. The models are: SaaS, PaaS, IaaS and BPaaS (Business Process as a Service).
Microsoft's partner is preparing the methodology for banks entering the Cloud Computing arena. No Case Studies yet.
It should be remembered that the first banks that will use Azure will be smaller banks using Windows operating system and not Mainframe based large banks.
The Bottom Line
Mainframe was not dead in the 90ies and was not dead few years ago.
Large Banks will continue Core Banking systems deployment on Mainframes at least for the following 5 years.
Recently leading Cloud Computing vendors such as Amazon, Microsoft and Google approached large banks in order to start migration of systems to their Public Clouds.
I looked for evidence supporting the notion that Banks are transforming from Mainframes to Public Clouds. I found no evidence.
I am not the one to be blamed for not finding any significant evidence, because there is no evidence supporting the notion cited above.
Banks are using Public Clouds but...
Like many other organizations, banks are using Public Clouds applications. However, they do not use it for Core Banking systems deployment.
They use Public Clouds for applications which are less integrated with the Core Banking systems.
If they will not use Public Clouds for Core Systems, IBM Mainframes will be used for many years.
Public Clouds, Private Clouds or Hybrid Clouds
The answer to the question: Which type of Clouds are you using or you will use in the next years? will vary.
SMBs' frequent answer would be: Public Clouds
Large Enterprises' frequent answer would be: Hybrid Clouds.
Hybrid Clouds usage is based upon both Private Clouds and Public Clouds.
If you read a previous post titled: The Next generation of Private Clouds, you probably noticed that, according to Forrester Consulting's survey, building Private Clouds is a priority for nearly half of the large enterprises surveyed.
You may also noticed that 67% of the survey respondents said that access to Mainframe Data was critically important or very important in Clouds environments.
Conclusions
1. Large enterprises will continue to use Mainframes.
2. Large Enterprises will use Hybrid and Private Clouds. Mainframes will be part of Private Clouds.
Large Banks will not migrate of Mainframes to other platforms if they considering including Mainframes in their Private Clouds.
Business Barriers to Migration from Mainframes
Is there a Business Case for migrating Core Banking systems from Mainframe?
It is difficult to justify such a large and expensive endeavour.
The CEO or another manager would ask: What would we get for this multi year expensive endeavour?
The answer would probably be the same functionality.
Not the best answer for convincing Business oriented non-tech managers to spend a large amount of money.
Risks
1. resistance to change
Many of the current elderly Mainframe team members will not be able to adjust to new platforms and new development paradigm and tools. They are afraid of losing their jobs.
Some of them will resist the change and will not cooperate.
2. losing expertize
The IT staff maintaining current Core Banking systems has limitations, as far as new technologies and architectures are concerned, however some of the employees have deep understanding of current systems and the Bank's Business processes and Business goals.
They also know a lot about the Organizational Culture and about people working in the Business departments.
Many of these employees will retire or will be fired.
The new young energetic employees, replacing them, lack understanding and knowledge of the Business, the Organization and the People.
3. Bugs
Even in case of no resistance to change do not expect 100% accurate migration.
New bugs introduced to the new system imply cost and less satisfied customers.
3. missing Functionality
Undocumented functionality will not be part of the new Core Banking Systems.
The assumption that the documentation of complex old systems is full and accurate is an unrealistic assumption.
4. missing Data
Replace the word Functionality in the previous section by Data. Do not expect 100% precise data migration.
5. Misinterpreted Business Processes
The Challenges to BPM implementations include lack of Visibility and non-documented processes.
If the Bank migrating from Mainframe, did not complete its BPM implementation, some Business Processes in the new non-mainframe systems will not be identical to current Business
6. Co-existence and Migration process
After completion the development of new systems, these systems should be deployed.
Anything could get wrong during the actual migration process.
Additional Challenges
1. Security
Mainframes Security is better than other platforms Security.
In addition to the gap between Mainframe Security and Windows Security and Linux Security in non Cloud based environment, there is an issue of Public Cloud Security.
I am not sure that in house Linux and Windows based systems are more secured than Public Cloud based Linux and Windows systems.
However, customers perceive them as less secure because they are managed by employees of another company and because their systems shared resources with other enterprises' systems.
Systems and Data Security is more important to banks than to many other enterprises.
2. processing Large Amounts of Data
Mainframes are capable of processing large amounts of Data. High percentage of Business Data resides on Mainframes.
3. Scalability and Workloads Management
Current Public Clouds are based on Hypervisiors, Windows and Linux.
Are these Operating Systems capable of supporting large amount of concurrent Banking Transactions?
I doubt. My experience, as well as others experience, do not support the assumption that these Operating Systems will be capable of supporting and managing properly large number of concurrent Banking transactions.
Reasons to replace current mainframe Core Banking systems
1. Maintenance
Maintenance of old Legacy systems could be a nightmare.
Many of the people we wrote the programs 20 years or 30 years ago are not available.
The systems are not architectured well and are not structured properly. Usually the systems are large monolithic silos.
The code was changed many times by many different people.
2. lack of Agility and a long Change Backlog
The lack of Agility is an additional maintenance difficulty.
The Business result of the difficulty to change systems is a long list of unfulfilled change requests.
3. Skills unavailability
Young professional prefer to work with mainstream technologies and/or new innovative technologies. Gradual skills decline is a real problem in Mainframes environment.
Are there non-migration alternatives?
Basically there are two alternatives addressing Mainframes concerns without risky migration to other platforms:
1. Modernization
Systems modernization could be performed without migration.
The Modernized systems could be Service Oriented and may use advanced modern technologies, which are available on Mainframes.
It is not a Big Bang risky approach but it is still a long journey. Those who will decide to modernize their Mainframe Core Banking systems will use Mainframes for more than Short Term period.
However, after completing systems Modernization they will be capable of gradual and relatively smooth migration, if they will decide to migrate.
2. Core Banking Packages
Core Banking systems could be replaced by Core Banking packages. These packages resemble ERP products. Some of these packages can be deployed on Mainframes and on other platforms as well.
An endeavour of choosing a Core Banking Package and replacing current Core Banking Systems by it is also a long journey. Usually it is a longer journey than Modernization.
After completing the journey maintenance could be easier and cheaper, the dependency on employees is reduced and future gradual or complete migration from Mainframe is smoother and cheaper.
Migrated from Mainframe but not the Public Cloud
After long journeys to Modernization or Core Banking packages the last thing you would think of is another migration from Mainframes to another platform.
Few years later you may start migration to another platform. Even if someone will migrate to Linux or Windows the systems are still deployed in his Private Cloud (or not in any Cloud).
There are still significant barriers to Public Cloud based deployment.
I will name few major barriers: Local Regulation, International Regulation (e.g. Basel 3), Security and integration with other systems in the Data Center and in other Public Clouds.
Real World Case Studies? - Capital One
Amazon's leading Early Adopter is Capital One.
Capital One is a Credit Cards company and a Large Bank.
Capital Bank is using Open Source software, Microservices and Devops. Capital is performing transformation to Digital Banking.
Capital Bank's CIO Rob Alexander presented a Keynote presentation in last October at Amazon's re:Invent conference.
Alexander described how they start experimenting AWS in 2014 and how late in 2015, they launched production Mobile Banking applications based on Amazon's AWS.
I guess that the Mobile applications are using Mainframe Core Banking Applications and Data.
According to Capital One's CIO "the bank has been working closely with Amazon's team to develop the Security model".
For more details read:
AWS Case Study: Capital One
AWS reinvent 2015 keynote - Rob Alexander
The private Security model will be only the first step in a long process of development of industry Security standards and implementing these standards.
Me Bank
Me bank is a full fledged retail bank. The Melbourne-Headquartered company manages 20 billion $ in assets and has 800 employees who support 280,000 customers around Australia.
Amazon AWS is used for Development and Testing.
The Core Banking systems reside in the bank's Data Center.
For more details read:
AWS Case Study: ME Bank
ME Bank is not a large bank. I do not know if the Core Banking Systems were deployed on Mainframes.
If they were, I would not predict migration from Mainframe in the following 5 years.
Microsoft's partner: Capgemini
Capgemini partnered with Microsoft in order to provide Cloud based Services in Microsoft's Azure.
I did not find Case Studies in Capgemini's white paper Cloud Computing In Banking.
However, I found the following text: " Banks are expected to enter the cloud computing arena cautiously, with no single cloud services delivery model being a silver bullet for best meeting their demanding business needs".
Capgemini's white paper also discussing the first methodological step of choosing the right cloud model. The models are: SaaS, PaaS, IaaS and BPaaS (Business Process as a Service).
Microsoft's partner is preparing the methodology for banks entering the Cloud Computing arena. No Case Studies yet.
It should be remembered that the first banks that will use Azure will be smaller banks using Windows operating system and not Mainframe based large banks.
The Bottom Line
Mainframe was not dead in the 90ies and was not dead few years ago.
Large Banks will continue Core Banking systems deployment on Mainframes at least for the following 5 years.
Friday, March 18, 2016
Select the worst product in the Short List
The title of the post summarize the bottom line of my recommendation to a customer.
The Short List included three software products. Two of the products were owned by the same vendor.
Let call the best product product A, the worst product product C and the third product product B.
However, the same vendor was selling product B as well.
Due to overlapping products in companies acquired by the vendor he owned two competing products.
The key question was: Which product is the vendor's strategic product?
My answer to this question was: product B is the strategic product.
My customer was buying a significant product for Long Term. For the long term, the vendor will invest in Research and Development in product B.
He will invest as less as he can in product A. The support to this product's customers will be minimal.
Vendors do not tell you that one product is strategic and the other is maintenance fees engine.
The vendor told me both products are strategic.
I had reasons to believe that product B was the strategic products.
A friend of mine working in the IT Department of a large US based company, confirmed my opinion.
The company he worked for was probably one of the largest customers using product A.
According to my friend, the maintenance service was not good. No solutions for bugs were provided for long time.
The Bottom Line for product A:
Expect minimal future product development and low quality maintenance service. Do not select product A.
Product C's vendor was a lot larger. He has producing maintaining and selling many software and hardware products.
It is not the size that matters: Product C's vendor actually owned the Proprietary Platform the selected product should be deployed on.
This vendor was the leading hardware provider, the only Operating Systems provider for that hardware, The leading Integrated Development Environment (IDE) provider and the leading Database provider.
Many Customers prefer buying all strategic software from a single vendor and not Best of Breed approach. Product C's market share was higher than product B's market share.
The product selected should interface with Infrastructure Software products.
My prediction that for the Long Term product C will integrate better with other products built by the same vendor than product B built by another vendor, was gradually confirmed.
Historical perspective also supported selection of product C.
Five years before my customer selected a product, product C's functionality was very limited and the number of its bugs resembled the number of holes in a Swiss cheese.
During the five years until the selection process took place the gap between product B and product C was systematically narrowed.
The Bottom Line:
In the Long Term product C will be better than Product B and probably will dominate the market. Product C should be selected and implemented despite its functional and conceptual inferiority in comparison to product B.
Product C's enhanced integration with the Operating System and the de facto standard Database is a huge advantage.
Product C's functionality and features are broader than product B's functionality and features.
There were no new product B's customers and many users included in its installed base migrated to product C.
The Short List included three software products. Two of the products were owned by the same vendor.
Let call the best product product A, the worst product product C and the third product product B.
Why I recommended not to select the best product?
In my opinion, product A was better than the other two technically and conceptually.However, the same vendor was selling product B as well.
Due to overlapping products in companies acquired by the vendor he owned two competing products.
The key question was: Which product is the vendor's strategic product?
My answer to this question was: product B is the strategic product.
My customer was buying a significant product for Long Term. For the long term, the vendor will invest in Research and Development in product B.
He will invest as less as he can in product A. The support to this product's customers will be minimal.
Vendors do not tell you that one product is strategic and the other is maintenance fees engine.
The vendor told me both products are strategic.
I had reasons to believe that product B was the strategic products.
A friend of mine working in the IT Department of a large US based company, confirmed my opinion.
The company he worked for was probably one of the largest customers using product A.
According to my friend, the maintenance service was not good. No solutions for bugs were provided for long time.
The Bottom Line for product A:
Expect minimal future product development and low quality maintenance service. Do not select product A.
Comparing Products B and C
Product B's vendor was a large global vendor, who develops, maintain and sells variety of software products.Product C's vendor was a lot larger. He has producing maintaining and selling many software and hardware products.
It is not the size that matters: Product C's vendor actually owned the Proprietary Platform the selected product should be deployed on.
This vendor was the leading hardware provider, the only Operating Systems provider for that hardware, The leading Integrated Development Environment (IDE) provider and the leading Database provider.
Many Customers prefer buying all strategic software from a single vendor and not Best of Breed approach. Product C's market share was higher than product B's market share.
The product selected should interface with Infrastructure Software products.
My prediction that for the Long Term product C will integrate better with other products built by the same vendor than product B built by another vendor, was gradually confirmed.
Historical perspective also supported selection of product C.
Five years before my customer selected a product, product C's functionality was very limited and the number of its bugs resembled the number of holes in a Swiss cheese.
During the five years until the selection process took place the gap between product B and product C was systematically narrowed.
The Bottom Line:
In the Long Term product C will be better than Product B and probably will dominate the market. Product C should be selected and implemented despite its functional and conceptual inferiority in comparison to product B.
After ten years
More than ten years after my recommendation it is quite sure that my recommendation was correct.Product C's enhanced integration with the Operating System and the de facto standard Database is a huge advantage.
Product C's functionality and features are broader than product B's functionality and features.
There were no new product B's customers and many users included in its installed base migrated to product C.
Monday, January 25, 2016
Digital Loans and Banks: Current Status and Future Predictions
Few years ago I discussed the issue of Banking Channels and Customer Centric in a post titled: The Marriage of Customer Centric and Multi-Channel.
I argued that Customer Centric Bank It services should enable use of the preferred Channel or mixed Channels by each customer.
It looked like more valuable customers preferred Self Service Channels, mainly the Internet Channel.
A year ago, I wrote another post: Is Mobile Banking a unique Channel?
The bottom line was: It is not yes a unique Channel, however, it is enhancing the trend for usage of Self Service Channels.
Guess what, more valuable bank's customers prefer this Channel.
Recently, I read Business Insider's article titled: Digital lenders have a 1 trillion opportunity - this sidedeck has everything you want to know about them.
The article is based upon a research published by Autonomous Research. Autonomous Research is a financial specialist research company. The research notes topic is: the current status and future forecast of the Digital Loans market in USA and in Europe.
According to Autonomous Research research notes, their is 2 trillions USDs opportunity for the Digital Lenders.
The digital loans originated market volume could reach 100 billion USDs by 2020.
The banks should adapt to a new market: competing with non traditional competitors such as the Digital Lenders.
1. Customer Centric banking is a necessary condition, but is no longer sufficient.
In order to compete with Digital Lenders friendly lending processes, the banks should support Customers' Channels preferences. The digital channels such as the Mobile Channel and the Internet Channel should be as friendly as possible.
They should also support seamless Channel Integration allowing completion of one Channel transaction by usage of another Channel.
2.Efficiency is a must
In order to compete banks should have leaner and more efficient Information Technology Systems and Infrastructure services.
Hybrid Next generation Cloud could be a partial solution.
Efficiency is not limited to IT operations. The number of Branches should be reduced and Business Processes should be reinvented.
3. If you can't beat them join them?
Should banks invest in Digital lenders and cannibalize their short term profits or should they compete with Digital Lenders?
There is no correct answer to this question. The strategy and the timing could vary.
returning to Autonomous Research predictions
The Digital Loans landscape is changing. Big banks will enter into the market directly or indirectly (investing in Digital Lenders) and Market Consolidation will reduce the number of current Digital lenders.
I argued that Customer Centric Bank It services should enable use of the preferred Channel or mixed Channels by each customer.
It looked like more valuable customers preferred Self Service Channels, mainly the Internet Channel.
A year ago, I wrote another post: Is Mobile Banking a unique Channel?
The bottom line was: It is not yes a unique Channel, however, it is enhancing the trend for usage of Self Service Channels.
Guess what, more valuable bank's customers prefer this Channel.
Recently, I read Business Insider's article titled: Digital lenders have a 1 trillion opportunity - this sidedeck has everything you want to know about them.
The article is based upon a research published by Autonomous Research. Autonomous Research is a financial specialist research company. The research notes topic is: the current status and future forecast of the Digital Loans market in USA and in Europe.
According to Autonomous Research research notes, their is 2 trillions USDs opportunity for the Digital Lenders.
The digital loans originated market volume could reach 100 billion USDs by 2020.
The Challenge
The banks should adapt to a new market: competing with non traditional competitors such as the Digital Lenders.
The Digital Lenders services are consumed via an Internet site. Lending processes are performed digitally.
Unlike banks, they do not operate costly branches.
They do not have to cope with local banking regulations and international regulations such as Basel III.
They do not have to operate large Data Centers with hundreds or thousands workers.
The results are:
1. Lower prices than the banks prices.
2. Friendly and easy lending processes
3. Agility
Digital Lenders are a lot more flexible and adaptable than banks. For example, they are able to offer new loans types and P2P loans.
The issues and possible strategies
1. Customer Centric banking is a necessary condition, but is no longer sufficient.
In order to compete with Digital Lenders friendly lending processes, the banks should support Customers' Channels preferences. The digital channels such as the Mobile Channel and the Internet Channel should be as friendly as possible.
They should also support seamless Channel Integration allowing completion of one Channel transaction by usage of another Channel.
2.Efficiency is a must
In order to compete banks should have leaner and more efficient Information Technology Systems and Infrastructure services.
Hybrid Next generation Cloud could be a partial solution.
Efficiency is not limited to IT operations. The number of Branches should be reduced and Business Processes should be reinvented.
3. If you can't beat them join them?
Should banks invest in Digital lenders and cannibalize their short term profits or should they compete with Digital Lenders?
There is no correct answer to this question. The strategy and the timing could vary.
returning to Autonomous Research predictions
The Digital Loans landscape is changing. Big banks will enter into the market directly or indirectly (investing in Digital Lenders) and Market Consolidation will reduce the number of current Digital lenders.
Subscribe to:
Posts (Atom)
Public Cloud Core Banking: Hype or Reality? - Revisited
More than 4 years ago I was asked if Public Cloud Core Banking is a Hype or a Short Term Reality? If you had read the post, you would prob...
