Who Is Cloud-Sliver?   Cloud-Sliver is a US-based software company that helps Fortune 500 companies utilize FractalWeb technology to digitally transform their businesses.

What business problems do you solve?   Cloud-Sliver enables our customers to improve the economics and capabilities of their IT organization:

• Eliminate legacy software platform costs such as Oracle or VMware.
• Make efficient use of hardware resources so that data center and cloud provider costs are dramatically reduced.
• Reduce the need for data centers both on premise and in the cloud.
• Integrate data from disparate sources inside and outside an organization to provide a unified 360-degree view of customers and how they interact with the business.
• Developed and deploy Apps in a single business quarter with business unit or department level Javascript programmer resources.
• Continuously absorb data from all sources and make it available in real-time to desktops and mobile devices.
• FractalWeb technology is secure. It uses a distributed microsegmented data architecture coupled with public/private key crypto-infrastructure. The massive large-scale data breaches that make the evening news are a physical and mathematical impossibility.

What industries have Fractal Web technology Apps been built for?   Utilities (electric, water, gas), telecommunications, social media, government, and manufacturing.

What Is the “best fit” application scenario?   The Fractal Web technology architecture is optimized for applications associated with repetitive business process.

• This is the majority of most core corporate applications today.
• Examples of such applications are: billing, provisioning, forecasting, variance detection, logistics, personnel etc.
• The common characteristics of these apps are the need to process large volumes of data at periodic intervals with repeatable processes or calculations.

What is Cloud-Sliver's licensing model?   We license per endpoint. An endpoint is a customer, a vehicle, a phone, or whatever the app is interacting with.

• We charge one price, $X per endpoint per year. Period. No other line items or extras. No charges for test systems, or backup sites, or other additional copies of the system.
• No charges if you want that app replicated in dozens, or thousands, or millions of locations.
• We work with you during the evaluation phase to determine app endpoints.
• We invoice yearly or monthly, whichever is most convenient for you.

How does Cloud-Sliver handle updates & maintenance?   We do not charge for updates or maintenance. New features, enhancements, tools, that are available to one customer are immediately available to all customers.

What does a Proof of Concept deployement look like?  

90 days   A proof of concept project typically takes 90 days. It requires a business person and a technical person as contact points in the customer's organization. The demand on their time is about 1 hour per week for the 3 months of the proof of concept project.

The business person   This should be a business person who can describe, from a user's perspective, what the proof of concept system should do. This is someone who can articulate 1) what are the inputs (data sources) that the system needs to consume and, 2) what are the outputs (reports or bills or analysis) that the system needs to generate. This person is typically needed for a few hours at the beginning of the project and then about an hour once a week to insure the project stays aligned with business needs.

The technical person   This should be someone who has the ability to extract data from the legacy systems that provide the sources of data for the proof of concept system. The technical task is generally to extract tables from a relational database(s). In some cases, this will be a complete table dump into a comma separated file (or something similar). In other cases, this will require writing some SQL scripts to generate a denormalized comma separated file extract of required data. In all cases, the goal is to keep the data extraction task as simple as possible and handle any data processing complexities with a sophisticated set of ETL utilities that are part of the Fractal Web™ technology framework.

Data sources   There are typically 3 types of data that need to be extracted:

1. Data tables that describe customers (names, account #'s, applicable billing rates, etc.)


2. Data tables that represent customer interactions (the "inputs" to the system). These are typically time-series in nature. They may be meter data files (for companies such as electric utilities), or call log files (for telco's), or Point of Sale terminal data (for retail stores), etc.


3. Data tables that represent desired "outputs" (the work that the proof of concept system is supposed to do). These are also typically time-series in nature. These may be monthly bills that need to be sent to customers, inventory reports, close-of-business reports, forecasts, etc.

Reconciliation   The proof of concept system usually needs to be checked against the legacy system to see if it produces results that make sense. Therefore, the last step of a proof of concept deployment is usually establishing a reconciliation process to check the "output" of the proof of concept system with the "output" of the legacy system. This reconciliation process can be used as a Q/A process where the Fractal App checks the output of the legacy system for accuracy (in the case where it is used to improve bill accuracy for example). The reconciliation process can also be used to ensure that the Fractal App is doing "the right thing" in the cases where the new Fractal system is intended to take over the work of, or replace, a legacy system.

What does a Proof of Concept deployement look like for an electric utility?  

Sizing the system   PicoTera needs the following information to size the system

1. The number of utility customer billing accounts


2. Approximate number of these accounts that have 15-minute interval meters vs daily read meters


3. Write-up on billing rate structures – This is typically a book in Acrobat format that is published on the utility’s web site and has been filed with the relevant public utility commission. Generally, the book is around 100 pages in length. If the utility has published any rate summaries for its customers these should also be included. The rate summary is typically a page or two in length, formatted as tables, and published on in customer support portion of the utility’s web site.

Extracting data   PicoTera Systems needs the following data extracts from the utility’s system of record. In the North American market, the system of record is usually a system such as CIS or CC&B.

"Input" customer data   Denormalized flat-file data table export that typically includes (at least) the following:

• service point ID
• account ID
• rate
• customer ID
• meter ID
• customer name
• customer address (street address, city, state, zip code – usually as individual fields)

• latitude / longitude
• bill cycle number
• customer email & cell phone (for alerting purposes)
• meter multiplier(s) - if they haven’t already been applied to the meter data

"Input" meter data   Data file(s) of at least 1-2 months of daily meter readings.

For data sources like L&G Command Center (CC) or UtiliNet (USC) these are ASCII human readable files that are in a comma separated (CSV) format or similar (the delimiters may be “|” instead of “,” for example). Typically it is only older MV-90 data format files that are in binary format.

Data file(s) of at least 1-2 months of interval (typically 15 minute) meter data.

"Output" bill data   Denormalized flat-file export of billing data. This typically includes (at least) the following:

• service point ID
• account ID
• bill segment ID
• bill ID
• energy data (kWh, kW, pf, KVAR, etc. required for line-item calculation)
• rate class
• meter multiplier(s)
• bill cycle meter reading start date & time and end date & time
• billed amount

Parallel system   With this information and these data files, PicoTera Systems can configure a system with both an internal facing web site that can be used by key accounts team, customer support, etc. and an external facing web site that can be used for customer engagement & support.

The system can run in parallel with the billing system of record and can be used to check and reconcile the system of record and can also be used for rate scenario analysis, financial forecasting, etc.

What skills do I need in order to develop Fractal Web Apps?   Full stack Javascript programming experience -- both server-side (Node.js) and client-side (jQuery and similar tools).

How secure is Fractal Web technology?   It uses a distributed microsegmented data security architecture coupled with distributed public/private key crypto-infrastructure. This approach provides two benefits: 1) It meets all of the security standards for high security applications such as financial transaction processing, and 2) It means, that in the unlikely event of a security breach, only the specific microsegmented data payload is compromised. The massive large-scale data breaches that makes the evening news are a physical impossibility.

How large a database can Fractal Web Apps handle?   The theoretical record limit for a Fractal is 2 to the 64th power to the 64th power which we are told is more than all the atoms that exist in the universe, but since we have not counted them, we are not sure. It is certainly larger than any app we know of in the commercial world.