General availability of Jabatix Workbench

On Monday, 24 April 2017, the Jabatix Workbench will be generally released. The mission of the startup Jabatix is to provide a powerful software development environment; its components support enterprise solutions, which deal with large amounts of incoming data, must process information programmatically, and must provide fast reporting and drill-down for just-in-time decision support.

Jabatix is an all-you-need-toolset for business software developers. It encapsulates the core business flows that deal with data processing, from heterogeneous incoming data sources, to transformative processes, to information visualization (or input to further downstream processing). Jabatix leverages its open-source roots to provide a cost-effective solution for scalable business process challenges. Built on top of the Eclipse platform and using its Interactive Development Environment (IDE), the toolset has a short, flat learning curve and allows for iterative programming on the client side, before final deployment to the enterprise.

Jabatix functions have been used very successfully in Jabatix Finance, the engine behind FERNBACH FlexFinance, for some years. Large banking clients have used the finance-specific versions of these functions in their installations. They have now been extracted and abstracted, as well as further modularized, for application in any industry, where large data input and output streams and the need for fast, accurate reporting of deep analytics are mission-critical.

Jabatix is consistently object-oriented, with business objects as a central data management and manipulation tool and abstraction of core functions for data access, manipulation, transformation, and visualization. This object orientation envelops diverse data forms emerging from heterogeneous sources and supports custom programming of processing functions using the simple Jabatix scripting language, CANTOR.

Simple use

Figure 1 – Simple use of Jabatix Workbench

At every step of this process flow, additional options make software development with Jabatix very flexible and adaptable. The range of input sources and output destinations can be of any convertible format. Cantor scripts (Cantor is a domain-specific language implemented on top of Groovy) are used to insert functional processing logic, for purposes such as data cleansing, data mart aggregation, report generation. In addition, process flows can be assembled as sequences of steps; these process flows can then be run on the workbench, or deployed to the enterprise.

Jabatix can be used to simplify, accelerate, and automate a whole range of possible business functions. The workbench includes the Eclipse Business Intelligence and Reporting Tools (BIRT) for powerful reporting.

Adopting Jabatix is a non-risk affaire, as the workbench can be installed for free, and without strings attached. You will find instructions on the Jabatix website at www.jabatix.net. Jabatix Enterprise extends the functionality created in the Workbench and adds relevant management and monitoring services. All model projects developed on the Jabatix Workbench can be run on the server and fully automated. The costs of this Enterprise Environment can be computed from the price calculator available on the Jabatix website at www.jabatix.net.

So go ahead, download the workbench for free, experiment with it to your heart’s content, and let us know what you think, how you might use it, and how we can be of further service to you.

Advertisements

ERP Is Dead—Long Live erPL

The idea – or should we say, dream – that there can be a single, integrated enterprise resource planning (ERP) software system that supports all an organization’s business activities is one that should be left to deteriorate and die, much like a decaying and forgotten industrial city. The goal of ERP solutions, and of the vendors who have tried to build these great wonders of computing, has always been a worthy one. Billions of dollars and countless hours have been invested into creating massive ERP solutions with footprints that continue to expand. But much like the forgotten foundations of ancient cities, these mega-software ERP solutions are a dying breed.

erpl_1
Figure 1—RIP ERP

The Dawn of erPL

What is rising in place of the ERP system is the enterprise resource platform* (erPL). The software vendors taking over from the old guard are those that are building the application platform first, and the functionality (such as finance, human resources, or inventory management) on top. These platforms are being developed primarily in the cloud—many are not even available to buy and install on-premise. Companies like Salesforce and NetSuite are continuing to win at the expense of old-school ERP because the new erPL solutions deliver both the business functionality and a full suite of powerful business platform services all on top of the platform and infrastructure layers.

The business platform services offer more than the platform-as-a-service (PaaS) products, but not necessarily the end product delivered by software-as-a-service (SaaS) products. (It is a given that the platforms come with all the infrastructure to support it. In other words, erPLs supply all the infrastructure, including the computing power and storage.) ErPLs provide a more robust layer than what is commonly considered to be a software platform. Traditionally, the term “platform” is used to describe the layer that sits on top of the infrastructure layer and provides software tools and capabilities for developing applications. These platform services are usually things like the operating system, database management system, and application development tools. The cloud PaaS software layer providers deliver this level of platform services.

The erPL providers take the idea of the platform services to the next level—what we will term “business platform services.” The services available on this layer include capabilities such as enterprise social collaboration, document management, global text search, business process management, workflows, reporting, analytics, and other business services. The platform is also designed to deliver a consumer-grade user experience on any device, anywhere, at any time. The erPL is a combination of infrastructure, platform, business platform services, and the application services (see figure 2).

erpl_2
Figure 2—The erPL

When we at TEC certify our products, a large part of the product demonstration is dedicated to reviewing the business platform services offered by the software vendor. The reports on Infor LN, NetSuite (for Distribution), and Priority software provide good examples of what to look for when examining the business platform support provided by a solution.

Don’t need no stinking ERP—What Next-generation Entrepreneurs Are Using

Another trend in enterprise software is to ignore the single vendor, single solution approach altogether. In this case, a business uses a set of best-of-breed applications to meet its operating needs. TEC met with a young Dutch-Canadian entrepreneur, Quinn Roukema, who is the co-founder of a new type of wholesale distributor. His company, E-Retail Society, brings viable products to market in a very short time frame. For example, one of the summer’s top-selling products is the SmoothBag inflatable lay bag. His company was able to set up the branded website, Smoothbag.com, and begin selling online in little over a week.

Roukema runs his business using a combination of recent entries into the SaaS market for small and medium-sized businesses (SMBs). The online store for the products was built using Shopify, the Canadian e-commerce provider. TradeGecko, founded by three New Zealanders, was the choice for order processing and inventory management. Xero was the winner for the accounting software. The final piece of the puzzle is ShipStation, which handles all the company’s parcel and shipping needs. These SaaS solutions are all purchased with monthly subscriptions. The entire business has been set up and operated with virtually no capital expenditures for hardware and software to run the business. Only personal laptops and mobiles are used for the entire operation.

This new generation of best-of-breed applications differs from the previous generation of best-of-breed solutions. Previous best-of-breed solutions were usually built to handle a fairly complete portion of a business process, such as customer relationship management (CRM), human resources (HR), or financials. The new best-of-breed applications are built to provide a focused function and are not beholden to any particular idea of legacy ERP vendors. These discreet services can be easily subscribed to and even dropped or replaced as business needs change.

Did the Ideal ERP Ever Really Exist?

It has long been the dream of C-suite executives to have a single system to manage all of the company’s enterprise application needs. And every ERP vendor has sold the idea of that single, beautiful system in the sky that will meet every need that a company has in the present and for the rest of the company’s lifetime.
However, an all-encompassing ERP system that manages the entirety of a company’s business needs has never really existed. What company with more than a handful of employees doesn’t have more than one application either in-house or outsourced to manage the business? Even small companies find that they need to have a small ERP system for accounting, maybe leverage an external provider for payroll and benefits, and have some ad-hoc request system for managing internal products and/or services. Most large companies have hundreds of other applications that are either tightly or loosely connected to its corporate ERP system.

This isn’t to say that the ERP idea is a bad one. This author supports the concept of a single, unified software solution that would support all of an organization’s business processing needs. That single solution would provide a common user experience, a single data store where all information is updated and available across the organization in real time, etc. However, no matter how much the ERP vendors try, they have never quite been able to keep ahead of the march of innovation across all industries.

That the ERP dream never really panned out is not necessarily the fault of the vendors. In reality, a large portion of the data that has an impact on a company is generated outside of its four walls. For example, a manufacturer is heavily reliant on the suppliers across its supply chain. To be able to determine the precise date on which a complex product is going to be manufactured can require up-to-date information on hundreds of parts. Other industries, such as oil and gas, might be impacted by everything from a traffic accident on a bridge to the weather. ERP vendors have tried to bring in this other data and integrate it with the ERP data, but the number of data points and dependencies has always outpaced the speed of the ERP vendors.

The Power of Platform Business Models

It is no secret that platform business models built on technology have proven to be the biggest story of the 21st century. The platform businesses include social networking platforms like Facebook and LinkedIn. Skype and WhatsApp are examples of communication platforms. And Uber and Airbnb are probably the disruptive platform business models. A blog discussing Uber statistics notes that Uber now has more than 160,000 drivers and more than one million daily trips, on average. Airbnb’s website shows it operating in over 191 countries and more than 34,000 cities. It has grown to this size without owning a single property (other than those for its operations). The reason platform business models can grow at exponential rates is because of the multiplying effect of all parties on the platform who can participate and create additional value.

As mentioned above, the Salesforce and NetSuite products were developed with the technology platform at the heart of the product. Most of the legacy ERP products have been developed with a specific function in mind, not the overall platform. The openness of the platform extends beyond the services delivered by the platform and needs to be open to developers and non-technical business users to create additional value for the overall platform. Most vendors do deliver the business platform services we discussed above as part of their solution stacks, but few deliver these on a unified platform in the cloud. Some have moved their legacy on-premises solutions to the cloud, but these weren’t built for the cloud first.

As shown in figure 2, this unified erPL needs to include the full stack of services, from infrastructure-as-a-service (IaaS) on up through to SaaS. Other vendors have been developing their erPLs in the same vein as Salesforce. For example, Infor has been very aggressive in recent years and has developed an entire suite of business platform services that are available in the cloud. Microsoft’s recent introduction of Dynamics 365 is further confirmation of the platform direction. Dynamics 365 brings ERP and CRM together with services for Office, Power BI, and Cortana in a single cloud platform. Other players such as Acumatica, Plex, and Priority software are delivering solutions in the cloud with more of a services approach.

ERP Software 2020 and Beyond

By the year 2020, the enterprise software landscape will look very different than it does today. The future will see Salesforce and NetSuite continue to grow as their platform ecosystems continue to grow. These players will continue to increase their market share and move more solidly into territory once dominated by what are currently the tier-one ERP software companies—SAP, Oracle, and Microsoft. Some tier-one solutions will still be around, but will exist only to support underlying financials, sales, or manufacturing transactions—much like an old building that is too costly to replace but is gutted and remodelled, leaving only the foundation and walls to remind people of the glories of the past.

The ERP software companies that will forge ahead in this paradigm shift will be those that can offer their products to consumers via the cloud in an easily consumable fashion. The products will be available on an open platform and accessed as services, where the services subscribed to are only what a company needs, not what the ERP vendor has thrust upon a business as a one-size-fits-all behemoth.

Of course, some of the legacy versions will still be operating, but the numbers will continue to decrease. As the baby boomers retire, so will the systems that they installed and grew up with. The new entrepreneurs will have never heard of these solutions and if they saw them, would laugh at them the same way they laugh at a flip phone. ERP as we know it will be long gone, and the solution providers who can build erPLs will be the ones who will dominate the next generation.

*Efrat Nakibly of Priority Software must be given credit for introducing the term “enterprise resource platform.” At a meeting this year, she told us that we should all stop using the term enterprise resource planning and start using enterprise resource platform. We can’t agree more.

 

Author: Ted Rohm – TEC Blog Post, 2016

A new release once a century

Do you use standard software from the major manufacturers? If you do, this surely operates perfectly and follows a well-organised procedure which may look like this:

  • Release deliveries are provided every three months. However, you cannot make use of each release because you always have to make sure that your own specific business transactions still operate properly with the software. Probably, you only accept a release once a year and possibly have small corrections and maintenance work delivered and installed once a month.
  • But let’s assume that we are dealing with a major functional enhancement. This would have to be released four weeks before the deadline so as to be integrated into the manufacturer’s programme.
  • To ensure good-quality programming, the rule of thumb is that the production time at least is incorporated into the delivery time. For example, production time of 20 days would result in a delivery period of four weeks. Of course, if more staff are involved, production time could undergo a linear reduction.
  • In order to create efficient programs, the IT department needs exact written instructions from the business unit in question. Two months could easily be required for a programming exercise of 20 days because a business unit often carries out this work as well as its daily routine tasks. In addition, the requirements have to be co-ordinated with other business units.
  • Once the IT department receives the written instructions, a consultant from the software company will be invited for discussions. However, since the software company’s products are very much in demand, four weeks can pass before this meeting takes place.
  • The consultant alone cannot decide if the enhancement required can be included in the release and to top it all, the Product Management Board only convenes every two weeks to decide on additions to releases.
  • If a positive decision is made, the enhancement is transferred to development planning.

In the company in our example, the new releases are installed in the annual company holidays in August when only a skeleton staff is working. Surely not the best time to implement new software?

Now have you been counting? In what month does the business unit in question have to start work, if it wants the delivery installed in August?

October Use of the investment
September Introduction of the software to the business unit
August Installation and test in the IT department
July Frozen period/manufacturer test phase
June Development
May Development planning
April Product Management Board
March Meeting with the consultant
February Discussing the concept with the IT department
January No project work because of end-of-year tasks
December Business unit works on the concept
November Business unit works on the concept

A normal cycle lasts twelve months. However, if this only takes six months in your company, this could almost be considered as quick. The reaction to these lengthy cycles, which we are all aware of, is usually that the standard software cannot cover all urgent requirements. But what does urgent mean in this case? By definition, “urgent” means all requirements needed by the Board, the owner, the legislators and the supervisory bodies. When there are enough “urgent” requirements, the business units hardly have the time to write the functional concept/enhancement requirements for the standard software.

So what does this tell us?

Standard software is only adjusted to a company’s requirements to a minimum degree and essentially operates in the same way for the next five to ten years. The intended rationalisation has not come about, as was hoped, because more staff would inevitably be required to implement the “urgent” requirements in addition to the standard software. After five to ten years, a new IT manager comes along with a new tendering process which is verified by ROI calculations. Then the product is purchased from a major manufacturer because only major manufacturers can supply a lot of functions at a relatively low price. Ultimately, functional concepts/enhancement requirements are developed for those functions that do not satisfy your company’s needs.

Is the IT industry really so bleak and stagnant?

Unfortunately, it is. Thankfully however, a parallel world for mobile phones and devices has been in existence for some years now. Apps that update automatically and innovations that are provided on the basis of the user profile. Security measures are automatic, back-ups are always available and users often fail to realise that these devices are so user-friendly because of the software.

At this point, you might be thinking that you cannot really compare mobile apps to powerful software such as that for materials management, accounting or human resources. But this is indeed the case. Just have a look at how simple some functions for business software are: tax calculations, aggregation of positions and printing of invoices. In contrast, some games software is much more complicated. The reason for the existence of two software worlds is another. The designers of mobile apps had very limited computer resources, tiny monitors and a self-defined target group. App designers have to know exactly what they are doing so that the first application is a success. Nowadays, if users cannot operate the app after one minute, they will not download or use it. With major standard software, it’s a completely different story. Users are trained for four weeks until they master the art of writing an invoice while their employers insist on them using the software. Who has managed to operate standard software in just four weeks?

Can you see the difference?

As far as apps are concerned, users are in control of how they use them which is not true for standard software. For strategic reasons, a decision is made for or against a particular manufacturer. Would you like to know what these strategic reasons are?

  1. A release is guaranteed once a year
  2. Manufacturer’s Product Management Board
  3. Defined change processes
  4. Any number of others use the software

That’s how easy it is.

Why a Core Banking System Conversion is the Wrong Approach

Ah, remember the old days……, the days when you had to get to your bank or credit union branch before 2:00 PM in order to get a deposit recorded as a transaction for that day. Fast forward to today. As Tom Groenfeldt, contributor to Forbes so eloquently writes, “When 40-year old legacy banking systems meet the two-month old iPhone 6, the results aren’t pretty.”  The same thing that happened 20 years ago when a customer visited a branch still happens to you and your iPhone 6 or tablet today. It encounters batch processing. We are in the era of real-time transactions, real-time processing, and instant access to data, yet banks and credit unions cannot consistently deliver that experience to their customers or members.  So much time has passed yet so little modernization progress has been made with North American core banking systems. The very systems that drive your credit union or bank. How can you compete against the up-starts, neo-banks, and fintech companies that seek to take piece by piece your most profitable business and leave you with the burden of regulation and no profit transactions when your core banking system is so far behind?

Core banking systems, also known as core data processing systems were architected and built 30 to 40 years ago. They were designed more than 20 years before anyone heard of the Internet and their basic architecture has not changed since then. They were built to handle internally generated transactions from tellers, loan officers, CSRs and back-office support staff. They most definitely were not designed and still are not designed to meet the needs of external users such as customers and members. As a former executive of a core banking system company, I have seen the inside of the belly of the beast and it is not pretty. They say that if you see how sausage is made most people wouldn’t eat it. At least the finished product generally tastes good. If you saw how core banking systems are architected, enhanced and maintained, the spaghetti code cobbled together, and the lack of documentation you would not want to rely on it to run your bank or credit union. The worst part is many banks and credit unions have a hate/hate relationship with their core banking system and their provider. Why, because the core banking systems in use today, simply were not designed to meet the needs of today’s credit union and banks. As much as your core banking system provider may want to give you what you want, they can’t. Their core banking system solution simply was not designed to meet the needs of modern banking and their customer’s expectations, real time processing, transactions and data management. They are built on outdated technology, they were built around batch processing, and they have enhanced using Band-Aids and patchwork.

So what are banks and credit unions that do not have the resources of the major national and super-regional banks to do in this situation? Converting from one core data processing system to another core data processing system is like adding internet radio to your 300,000 mile 15 year old car. It may provide you with a feature you are missing, but what happens when the engine blows up?

Fortunately, there are options, and the best part is the options come with far less enterprise risk than a core banking system conversion and will add long-term functionality and architecture that will allow your credit union or bank to move into the world of real-time processing, transactions and data management, and personalization.

Components, APIs, standards and the cloud allow banks and credit unions the opportunity to explore true alternatives to the zero sum game of a core banking system conversion. Componentization, APIs along with emerging standards such as BAIN (banks) and CUFX (credit unions) and internal or external cloud  environments allow banking systems to more effectively communicate with each other and allow banks and credit unions an opportunity to create their own Services Orientated Architecture. An SOA will modernize the technology environment by allowing credit unions and banks to mix and match technology solutions they need to adjust and drive their business model and the ability to quickly adjust and implement new solutions.

Combining a presentation platform on top of a security layer, an integration layer with business and workflow engines, data analytics tied to back-end and stripped down core banking legacy systems will provide credit unions and banks with the flexibility, agility and lower risk profile necessary to offer members and customers the solutions they demand in order to compete in the rapidly changing retail financial services market.

Before your bank or credit union considers a core banking system change evaluate the alternatives which will be less expensive, have a lower risk profile and can be operational much faster and positions your bank or credit you to be agile in the quickly evolving retail financial services market.

Why a Core Banking System Conversion is the Wrong ApproachAuthor: David Gibbard – OmniChannel & Digital Banking, 2014

Automation in banks – where do the incentives come from?

When you use one of the terminals in a bank or make a transfer using online banking facilities, you are quickly given the impression that the banking industry operates on a widely automatic basis. Thus you might just ask yourself, what do the 50,000-strong workforce at Commerzbank or the 270,000 employees at HSBC still do exactly?

The impression you obtain at the terminal results from the fact that bank-internal processes are often based on document management processes (ECM, DMS), i.e. all correspondence but not the money transfers, accounting entries or the bank’s actual core business. Try to guess the number of times that you have already completed a contract or a document at the same bank which always included the same data. In our opinion, ECM and DMS deal with roughly 5% of business transactions.

The regulatory requirements for banks worldwide are the cause of everlasting projects that often have to be mapped in a bank’s different IT landscapes. For example, KonTrag, MaK, MiFID, Basel II, IFRS and Liquidity Risk number among the legal regulations most recently issued, to name just a few. Many global requirements are often extended to include national requirements such as FATCA, which affects US citizens who have accounts abroad, or regulations issued by the Monetary Authority of Singapore, Hong Kong etc.

For this reason, the IT and project staff in a bank are kept back from their actual tasks such as ensuring that processes are efficient or automated etc., particularly because regulatory requirements have to be implemented within a specific time frame.  In larger banks, up to 20 software manufacturers or suppliers can be involved in implementing regulatory requirements, resulting in a huge amount of coordination.

IT departments worldwide face major challenges because they have to ensure that the requirements are coordinated and implemented professionally and on time, that the latest releases are installed everywhere at the same time and that coordination between the business units for testing purposes is effective.

Therefore, it is hardly surprising that, after nearly 40 years of electronic information processing, there are roughly 4000 software providers worldwide. The potential for optimisation can be seen by looking at the example of a large Nordic bank that wanted to implement a five-year optimisation project to reduce its IT providers from 4,000 to 250.

In view of this, many banks are hoping for a “panacea” from the manufacturers of core banking systems. The best-known providers are first and foremost SAP, followed by Temenos, TCS, Misys, FLEXCUBE/Oracle or the smaller companies such as ERI / OLYMPIC or Avaloq. In theory, this would reduce the risk involved in timely implementation dramatically because there would be no need for reconciliation work between the different IT solutions.

When the extensive list of partners associated with providers of core banking systems is considered, it quickly becomes obvious that these providers will not supply or be able to supply all the functions needed. It could be discussed at length which functions belong to a core banking system and which functions providers of core banking systems should buy from elsewhere.

Is a core banking system the correct strategy for achieving sustainable automation based on the premise “Quality enhancement at reduced cost”? Is it possible for a software provider to create an overall core bank management system?

Or to put it another way: How can an external software provider develop all banking-related functions when numerous banks have failed to achieve this in recent decades even by deploying huge IT departments with many thousand employees?

The question is justified; however, it seems hard to believe.

The fact that, in this “ideal scenario”, a bank would become dependent on just one provider, in the true sense, should also deter an IT decision maker from this strategy.

Quite a different development can be seen in other industrial sectors such as the fashion, car or sports industries. It would appear that by concentrating skills on sales, customers and product design is what makes outperformers such as Apple, Volkswagen, Samsung etc. so successful. Component production is mostly taken on by specialised subcontractors who provide entire structural units such as brakes, fittings, interiors etc. In some (famous) cases, even the entire, ready-for-sale end-product such as trainers or mobile phones are provided!

Focussing on one core banking system provider would seem to be contrary to what the rest of the German and international industrial sector is doing. A core banking system provider is defined as being the central point of all systems – whatever that central point may be – with all other functions and providers grouped around this. Other providers can really only stay in business if the core banking system provider fails to provide a certain function.

Can you imagine a bank not using functions supplied by a core banking system provider because these are in the wrong position in the architecture and prevent radical optimisation of automation on the long term although this has been included in the price of the package?

Who at the bank would be in a position to assess this?

It would not be possible without a general master plan or without the design. This might have given SAP the incentive to set up BIAN (Banking Industry Architecture Network).

Below is a statement from the BIAN website:

BIAN’s mission is to assist and guide the banking industry towards a consensus-based approach to achieving the vision of a flexible architecture which is closely aligned with increased agility and reduced costs. To achieve this goal, leading banks were asked to share their requirements for core services and leading software and services vendors to implement these services based on formally defined semantics.

In July 2012 Hans Tesselaar, Executive Director at BIAN, published the following:

According to research released a few months ago by Infosys and Ovum, around three quarters of European banks are using outdated core systems. Given the great costs associated with core system renewal, this will come as no surprise to banking IT professionals.

We should, however, be concerned at the survey’s findings that suggest these systems are affecting the ability of European banks to innovate and accelerate growth.

80% of respondents see these outdated systems as barriers to bringing new products to market, whilst 75% say these systems hinder, rather than enable, process change.

At a time when European banks need more than ever to be focusing on achieving growth, these findings make for difficult reading. For as long as out-of-date legacy systems continue to hinder speed to market, European banking will also remain out-of-date, slow to respond and inefficient.

Cf. http://bian.org/participate/bian-blog/shaking-shackles-outdated-legacy-systems/

Therefore, what is the right strategy?

IT providers and banks should imitate other successful (!) industrial sectors by firstly drawing up a functional master plan that is not linked to providers and manufacturers. However, expenditure is by far not as high as would first seem if a sensible, practical top-down approach is implemented. Similar to the architect, who clearly defines the size of the shower unit in the bathroom but only specifies the fittings for the shower when this is necessary.

The following stage focusses on finding the providers for the components if these are not to be developed in-house. Finally the components and functions are connected to a workflow/process flow/BPM system. If the visual aspects are then separated from the processes and data storage, the most important design rules have been observed in order to scale the organisation. What was the rule in this case?

“Scale up in good times and scale down in bad times”.

Scalable organisation for staff, time zones, countries, languages and locations: this is the challenge facing a modern IT organisation.

Of course, the most difficult aspect will be to implement the architectural phases besides the planning phases for new requirements in order integrate these appropriately into the master plan. Integrating “modern” ways of thinking and approaches into future IT planning procedure is a process that can be started at any time. Particularly because the transition is always smooth. Arguments that claim that these sorts of changes can only be “mastered” by radical broad-brush methods do not represent the facts.

Automation can be defined as the technical and economic processes in industrial production as well as the mechanical  generation of goods and services. It is essential to know what needs to be produced and how. The financial services providers that exemplify automation are included in the following list. Most of them are not banks.

http://www.fintech50watchlist.com/