Sunday, October 11, 2015

Integration


A long time ago I studied industrial design engineering. In engineering, building models are central within the design process. These models can be 3D mock-ups.

Aren't we all excited to see a futuristic concept car at an auto show? These models won’t hit the market, but still we get an idea for the future will bring.

Let me start by defining what a prototype is:
“A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.”
“A prototype typically simulates only a few aspects of, and may be completely different from, the final product.”

In IT, I've always wondered why we don't use models more when designing new IT systems. User interface designers use prototypes to test their ideas. Everyone that participates in user interface labs during the design process can see how useful obtaining feedback can be. The prototypes tested can even be very primitive, like sketches on paper. They’re still valid enough to steer the design process in order to get the most effective design.

In IT the most common use for prototypes is to get user feedback. The proof is in the pudding.

Paper documents like functional designs, use cases, and class diagrams are difficult to understand for novice users. Making a prototype bridges the gap between IT and users. Seeing the system work, however limited creates a common understanding of the product -- leading to more fruitful discussions on the design.

When to use prototypes
I know lots of project managers who don't like prototypes. The clunky and primitive models might scare customers away. "Is this all what we'll get?" (No, it's a prototype.)

Industrial design engineers also work closely with their users and customers. But designers seem to be able to communicate that prototypes are models about ideas to be discussed, not instruments for setting promises about the final product.

Many people see prototypes as test models. Yes, prototypes can be tested -- tested in the sense of evaluating all relevant requirements in order to determine whether the prototype fulfills its purpose and can be taken into production (after some minor alterations). But that's a rather limited view. Designers make prototypes to illustrate their design that will never be taken into production, like concept cars:

“Prototypes are not meant to be perfect versions of the designed products. It is often impossible to use the same materials that will be put in the actual product, and there may be no factory process to build it yet. (…) This results in a prototype that is not exactly what the final design will contain, but that is close enough to let the designers see if it will work or not.”

So prototypes can be used for testing, but also for things like gathering new requirements (or eliminating existing ones), generating new ideas, visualizing ideas and concepts, or even predicting the soundness of a solution. Why aren't we using more prototypes in our IT design methods? Why don't we model the most critical parts of our design to see if it will work in real life?

Prototyping and Big Data
So if we take a broad view on prototyping and the use of models in the design process, how are we're going to tackle Big Data projects?

Large IT firms like IBM and Capgemini use “innovation labs” to educate users about what new tools and data, and what they can tell us about how it's different from existing reports.

These laboratory-like environments let users work with Big Data systems even before any final solution is conceived:
“Rather than developing requirements first, as you would for a traditional BI project, then building a business case for the tools and data needed to fulfill them, it makes more sense to let users experiment.”

In all the projects I've been in, there were always issues around communicating requirements and designs with users. They could not understand them in full scope. But project management expected the users to understand.

How can project managers gain consent if the users can’t really understand what's going on? Frankly, the problem becomes more eminent when the project introduces new technology, ways-of-working, or forms of interaction with the system. It's hard for non-experts to see what the consequences of the design will be.

Big data analytics projects are new – and disruptive – by nature. You can’t expect future users to see every consequence of using Big Data systems in their business’ context. Prototypes help determine what users want, how Big Data functions will work in their business, and most importantly create a common understanding between IT and users to start discussions on requirements and objectives.

Prototyping also fits in with agile development. Capgemini offers the Big Data Analytics Sandbox for Financial Services. This sandbox lets clients try ideas and deploy to production in a very short time. It also offers fast track analytical Big Data proof of concepts – or prototypes – in a contained environment before committing to a full scale solution. (A prototypes is a model "that tries to simulate the full system or at least a material part of it." A Proof of Concept (POC), however, is "a small exercise to test a discrete design idea or assumption".) Capgemini’s Big Data Analytics Sandbox can help your firm implement unique case-applications based on existing accelerators and already-developed proofs of concept.

Another approach is using tools like IBM Watson Analytics. The computing power of Watson will offer instantaneous insight into a data set. IBM suggests clients use Watson Analytics to analyze raw or partial data sets first, see what interesting insights come out, and which areas to explore further. Based on those insights, a traditional BI project can be started to dive deeper into areas of interest. When the data is cleaned, prepared, and reported on they then re-start Watson to explore the data further.

Both methods create prototypes first. But they don’t give exact results or give a complete truth. They will however, show users what Big Data can offer, the insights it will discover, and the way you can explore and present the data.

Believe me, while some users may nag about non-representative results, most will be excited about the preview of your Big Data analytics project they will produce. More prototypes, please!

Reinoud Kaasschieter
Solution Architect & ECM Consultant, Capgemini

No comments:

Post a Comment