Profile cover photo
Profile photo
FORCiVE- Information Operating System
1 follower -
FORCiVE- Information Operating System
FORCiVE- Information Operating System

1 follower
Communities and Collections
View all

Post has attachment

The IDC & FORCIVE study highlights how many BIG industry players are
rushing today into boosting their market offers through insightful and
innovative services leveraging on machine learning and big data, and
where and why the offered solutions’ majority is unsuccessful and

The analysis reveals some hurdles that are inherently connected to
big data projects together with the multitude of NoSQL databases and
Hadoop-based data lake management systems.

Watch the video:

Post has attachment
New Forcive User group launched

Post has attachment

Post has attachment

Post has attachment
Dear All,

we would like to share with you an article written by "FORCiVE" creator Carlo Stellati. Enjoy reading it!

Forcive Introduction

We are all familiar with the concept of Operating Systems, whether it is Windows, Mac OSX or Linux. All of these operating systems, can trace their origins to computing requirements that were defined over 30 years ago. They have been designed as a platform for executing business applications, with information representing just the raw material required by these applications.

In the last decade however, the role of information has changed dramatically, in terms of its structure (Multistructure), volume (Big Data) and significance to the organisation (Digital Company). Data and their related management and analysis, are in the centre of Digital Transformation driving company behaviour and growth.

Customer profiles, interactions and behavioral patterns, are used to drive go-to-market decisions and customer service. Sales intelligence and sensory metrics are driving product development and new offerings. Market analysis is driving mergers & acquisitions. In other words, information is driving corporate strategy, not applications. Yet, today’s Operating Systems are not designed to support these new data-driven business models. Data is organised and managed in a way that serves the business applications, not in a way that explores the value inherent in the information itself.

It has become clear that the approach needs to be reversed, so the main question becomes: What would be the “cornerstones” of a new Operating System, designed to promote information value?

Forcive’s Information Operating System is a completely redesigned new concept, architected explicitly to put data value in the core of all business operations. The design is based on the following four principles:

1. Dynamic Data Distribution: Data Lake technologies (Hadoop, NoSQL, Storage and Cloud) provide a grid of “communicating vessels” where data can move freely;
2. Dynamic Data Structures: Multi-structured data are complemented with dynamic metadata, dynamic information relationships and auditability.
3. Data Processes: Operational Processes are attached to the Data (not vice versa) in order to deliver, among many other advantages, Data Provenance as an inherent feature.
4. Access Control : Access control and security are directly associated with the data, metadata, data relationships and audit trails, in real-time, regardless of the physical location and logical organization of the data.

Post has attachment
We are proud to present you an opinion of George Parapadakis about our products:

IOS – A comet of Jurassic proportions

Every so often, an idea comes along that stops you in your tracks.

Innovation is happening at the speed of light all around us but most of of the time it consists only of incremental, evolutionary thinking, which takes us a little bit further in the same direction we were going all along. We have become fairly blazé about innovation.

And then you spot something that makes you sit up, pay attention, change direction, and re-think everything. I had one of these moments a few weeks back.

The name “EpyDoc” will probably mean nothing to most of you. Even looking at their existing website I would have dismissed it as a second or third-rate Document Management wannabe. Yet, EpyDoc is launching a new concept in April, that potentially re-defines the whole Data / Content / Information / Process Management industry, as we know it today. You know what happens when you mix comets and dinosaurs? It is that revolutionary.

I have lost track of the number of times over the years that I’ve moaned about the constraints that our current infrastructure is imposing on us:

The arbitrary segregation of structured and unstructured information [here]
The inherent synergy of Content and Process management [here]
The content granularity that stops at the file level [here]
The security models that protect the container rather than the information [here]
The lack of governance and lifecycle management of all information, not just records [here]
The impossibility of defining and predicting information value [here]
…etc. The list goes on. EpyDoc’s “Information Operating System” (a grand, but totally appropriate title), seeks to remove all of these barriers by re-thinking the way we manage information today. Not in small incremental steps, but in a giant leap.

Their approach is so fundamentally different, that I would not do it credit by trying to summarise it here. And if I’m honest, I am still discovering more details behind it. But if you are interested in having a taste on what the future of information management might look like in 5-10 years, I would urge you to read this 10-segment blog set which sets the scene, and let me know your thoughts.

And if, while you are reading through, you are, like me, sceptical about the applicability or commercial viability of this approach, I will leave you with a quote that I saw this morning on the tube:

“The horse is here to stay but the automobile is only a novelty – a fad”
(President of the Michigan Savings Bank, 1903)

P.S. Before my pedant friends start correcting me: I know that dinosaurs became extinct at the end of the Cretaceous period, not the Jurassic…😉

Post has attachment
Post 8/10 - Content Storage by Value: how to maximize the effectiveness of a Multiple Storage Architecture
One mistake we must avoid by all means is the conclusion that information enjoys a steady value during its entire life cycle. Its protection and security levels, its business value, or the connection that the information clusters have with one another are parameters that can vary significantly, depending on time factors.
On the other side, there is a very wide range of technological proposals available for architectures (Cloud or On-Premise), for storage technologies (one for all, the NoSQL repositories) or for the offer of storage.
Considering the volume of the information (BigData) the true challenge we face is how to harmonise the fluctuation of the information value, linked to time factors, with the technological offer available on the market.
In the past, we witnessed some simplification ventures which aborted miserably.
We will cite just two of such attempts. The first consisted in analysing the information accesses in order to decide where to store or where to move something. Under this rationale, we would even store the data of a plant’s emergency procedure into a remote archive! Any comment would be superfluous.
The second, more frequent mistake consists in identifying one repository only, usually Hadoop, and in loading the whole lot of information onto it, regardless of the data’s life cycles; it would be difficult to list here all the “use cases” that could undermine such a simplification.
Now, let us explore the practicable solutions.
Ideally, we should be able to dynamically move the information into the most suitable architectures and technologies, depending on each single use required in every single phase of its life cycle, while guaranteeing the necessary security levels.
Indeed, this would happen while leaving untouched all the users’ and the business applications’ access rationales.
We believe that those two features are essential for tapping in full the enormous potential of the Big Data.
In order to meet such prerequisites, EpyDoc perfected one of the basic modules in its architecture. The Data Lake Manager.
By virtue of this revolutionary module of EpyDoc Suite, we will be able to define automatic or manual procedures to move the information dynamically, according to the changes in its life cycle and to the utilisation of the business applications. In the process, users will always be guaranteed an unvaried access rationale, based on our SDK and LQL (Linked Query Language), two other components of the EpyDoc Suite.
If you attach weight to this, just wait some more weeks and check up on the EpyDoc revolution with the product’s GA.

Post has attachment
Post 7/10 - The Dynamic Content Allocation (without Synchronization) among Multiple Architectures
The issue is as simple as this: companies suddenly have to decide how to handle an enormous mass of unstructured data, and this before understanding its real value and without knowing its potential future use.
This is exactly the opposite of what happens in the management of structured data, when the applications are the start and the data organisation represents the outcome.
What we have just described is one of the main issues in the management of Big Data.
And let us explore how to handle the problem: if we grasp the potential of such precious resources (the data) but we cannot understand how they will be used, then the correct approach is to get equipped with specific tools that can ensure the maximum possible flexibility for the future.
Such tools fall into two different categories.
The first type must make it feasible to investigate deeper and deeper on the content values and on the mutual bonds linking unstructured data.
With the second type of tools, we enable the whole range of the potential applications to optimise the use of Big Data; ie. applications varying from statistical data to transactional applications, up to IoT and to the applications for the Document Management and BPM.
Let us discover how.
Data must undergo a first, real-time inventory to evaluate their uniqueness and to provide them with a first security level and a life cycle.
Later on – in batch mode – data are analysed by specific tools that examine their structure and find their links with other different data.
Then, it is possible to add more metadata and to define data classes that were not apparent beforehand.
In such a way, we keep improving our knowledge about the value of the Big Data we manage. Now we are to understand how to optimise their accessibility for our business.
It is a matter of exploiting efficaciously the resources we have, from architectures (Cloud and On Premises), or from the various repositories (mainly NoSQL) up to storage technologies….
An efficient PaS architecture (PaS=Platform as a Service) must be able to dynamically move data onto architectures and technologies suitable for the business applications using them.
For example data being the object of transactional applications can be used in MongoDB, while data with statistical value must be allocated onto Hadoop.
These are the basic functions; EpyDoc provides them all.
On-Line Normalizers and Batch Normalizers deal with the classification of the data and finalise the links between them, if necessary.
The Dynamic Content Allocation is tasked with moving data Clusters onto those technologies and architectures optimised for the business applications using them.
Let us imagine a Data Lake made by several Clouds and NoSQL repositories. Inside such a Data Lake, our data receive a first classification; then, the Batch Normalizer continues to survey them, while data are dynamically allocated into partitions according to the business requirements.
At last we can extract all the potential of the Big Data; a potential that is made available for the business.

Post has attachment
Post 6/10 - The Data Lake Manager: how to transform the wide offer of No-SQL repositories into a business opportunity
One of the many effects that Big Data have on IT infrastructures is the imperative requirement to use data-management tools differing from relational databases.
These tools, conveniently named NoSQL, were designed and developed almost at the same speed that we see on the generation of the Big Data
The site identifies more than 225 of such tools, listed under the following twelve categories:
1. Wide Column Store / Column Families
2. Document Store
3. Key Value / Tuple Store
4. Graph Databases
5. Multimodel Databases
6. Object Databases
7. Grid & Cloud Database Solutions
8. XML Databases
9. Multidimensional Databases
10.Multivalue Databases
11.Time Series / Streaming Databases
12.Scientific and Specialized DBs
Obviously, such a proliferation of technologies and products is rather puzzling for whoever must actually use such tools.
Let us start with the most natural question:
Are we really certain that, in spite of the marketing pressures made by some producers, there is one single product that can really meet all the present and future requirements of my organisation?
The answer sounds obvious to us. We just have to read the products’ features to understand that a tool designed to support statistical analyses on big amounts of data will never effectively support real-time transactional applications, just like a tool optimised for the management of Graphs cannot offer the same performances when it is used for the management of the Time Series.
We must then evaluate and choose several different repositories, depending on how we will use the data they are to manage.
However, this brings about other equally important questions.
We have always tried to struggle against the creation of information siloses about relational databases; why is it that now we make the same mistake with NoSQL repositories?
In order not to repeat such a mistake, first of all we must recognise that the use of a document depends on its life cycle, just like its life cycle determines the various range of security levels it must pass.
Hence, to prevent the data redundance and the creation of siloses, we must envisage that in their lifetime data can move from one repository to the other, according to the use that business applications will make of them.
To sum up: we must use several different repositories, according to the needs of the business, and we must adopt systems envisaging a dynamic movement of data between the repositories.
In order to perfect the architecture, such repositories are to be embodied into Cloud, Hybrid or On-Promise architectures.
The basic question is: which tools can manage such data flows?
EpyDoc’s answer comes through another strategic component of its architecture: the Data Lake Manager.
EpyDoc’s Data Lake Manager manages the transactional and dynamic movements of all Normalized Data (see previous Posts) between the various repositories, storages and clouds.
The Data Lake Manager becomes the basic tool to handle the complex architectures linked to Big Data, and, together with LQL (see Post #3), it permits to split completely the users’ requirements (ie. the access to data only based on access permits and on the semantic knowledge of data) and the IT managers’ needs (ie. to optimise technologies and archiectures according to the costs and the level of the service required).
Wait while more posts are being loaded