What is the strategy to face the diversity of effectiveness measurements?

Effectiveness measurements are growing everyday. Not a day passes without having a new KPI emerge within companies, where each one of them is considered complementary or even more relevant than the other ones. So what kind of KPIs are relevant to measure the effectiveness of actions taken? Because KPIs are diverse, they must be considered as a whole, as the global vision of the company - its relationship and business story. In real time, KPIs should meet and if possible exceed expectations for simplicity. But choosing the right KPIs is essential as well as the correlation of those linked by the same goal. These KPIs together are critical for decision-making, we call them “super KPIs” as they carry the power to change companies. Those super KPIs are able to evaluate the relevancy of actions taken for new organizational modes in companies. They are, by definition, scalable and must be mastered in their analysis and representation.

Beyond the careful choice of KPIs and their assembling, their representation into dashboards is a stake by itself. In order to stay loyal to their power and diversity, dashboards have to be dynamic tools, able to adapt to all changes, evolutions or twists, it’s a must today. The simplicity and agility of the dashboards are key for efficient decision-making, they help organizations to rapidly grow in a constantly changing environment, by making it readable and understandable for everyone.

Good KPIs are those making you ask yourself the right questions, they are often easy to understand for the organization at all levels and allow you to realize what is necessary to positively impact results. For example, the NPS (Net Promoter Score) is often used to measure customer’s experience. Even if it’s a simple management KPI, it can help associates, who are directly in contact with customers, in changing their behaviors to improve the customer’s experience.

Another example would be to consolidate some KPIs to obtain an aggregate used as a baseline, a super KPI, like the time consumers spend online with the brand by adding the time spent on digital assets such as websites, videos, social media, or the advocacy (by collecting all positive content posted on social media platforms).

A good KPI is the one that is aligned with individual and collective performances and goals. By reaching goals, individuals and teams will feel valued and will be rewarded.

Captain Dash’s approach is based on this simplicity and agility. Our mission is to make the change of organizations a lever for performance. Contact us to know how we can help you!

Stay updated and learn more on Captain Dash, follow us on Twitter or subscribe to our blog.

Written by: Bruno Walther, CEO & Co-founder of Captain Dash

Faster, smarter, better: data for decisions and actions 

Decisions and actions are directly challenged by an absolute need: speed. Our world does not wait and every second counts. In the business world or in our everyday life with others, we need to act and make quick decisions in order to succeed. Data is in the heart of this phenomenon. It has a speed with no equals, which makes the decision making process more complex for companies.

We need to be faster but also smarter and more efficient, it’s a matter of survival.

Faster The data flow is constantly increasing. It is now a necessity to equip ourselves with solutions that are able to capture and master this data flow. This will help to analyze data in real time and make decisions based on this data. The goal is to make sense of this data, which is translated by taking actions. Data becomes then a real asset devoted to act faster simply because it is actually understood.

Smarter Understanding data and its essential role in a company’s life is key. It needs to be clear, with no silos and this, throughout the entire organization. The idea here is to make data available to everyone by giving them a smart understanding of the economic and general life of the company. By making it available to all, data with simple and efficient dashboards is putting the company under a positive and agile tension.

Better Being better serves efficiency and by being faster and smarter our organizations are on the best path to grow. Today, we constantly work on the move and in networks, that is why we need to be agile and pro-active. Steering our companies with the right KPIs is essential. KPIs give a true evaluation of actions and their impacts serving anticipation and progress.

Captain Dash’s value proposition is that and much more, so contact us now!

"The necessity for CEOs and their teams to implement a roadmap to anticipate their customers’ needs and to offer new services is essential. They no longer can slow down or have a “me too” strategy because of the risk it represents. Data and its transversal dashboard feed this need, they are the antidote for status quo and working in silos. Speed, customer experience, relevancy, growth, new customers… They all are linked to each other. You can open a bank account in 8 minutes with Number26 or book a place in 5 minutes with Airbnb. So why are you still being asked for your needs when you enter your bank or for your preferences at your favorite hotel? Legacy information systems were not designed to answer high-speed and agility needs, that is why you should leave them where they are but build around them with transverse data teams. They are the ones who, with a microservices architecture, will capture the data on legacy systems mixed with data from other sources - from customer accounts to social networks.  You don’t need another Watson but a simple dashboard with data that allows you to grow rapidly and efficiently."

Stay updated and learn more on Captain Dash, follow us on Twitter or subscribe to our blog.

Written by: Bertrand Verret, Chief Revenue Officer at Captain Dash

Three architectural strategies for Micro Services APIs

A good house is built on a strong foundation. The same holds true for systems architecture. How you build your Micro Services determines what they turn into.

Read More

Nous aimons l'échec

Echouer est le meilleur moyen de réussir. Notre choix d’architecture reflète cette philosophie.

Dans tout service il y a des erreurs. Qu’il soit monolithique ou construit à l'aide de micro services, il peut tomber en panne à tout moment. Le travail d'un éditeur est de détecter ces erreurs et les réparer rapidement.

La structure monolithique est complexe. Elle est par essence difficile à tester, déployer et maintenir.

Les micro services sont eux construits pour supporter ce type d’échecs. La pluralité des services minimise leur interdépendance. La panne de l’un ne fait pas tomber l'ensemble du système.

Une architecture de micro service est structurellement sous surveillance. On peut ainsi, comme le fait le programme Simian Army de Netflix, tester ses limites et l’améliorer infiniment.

L'écriture minimaliste du code, la vitesse de déploiement, la capacité à réparer et modifier chaque application individuellement nous donne la flexibilité nécessaire pour innover et tester aussi souvent que nous le voulons.

Cette flexibilité nous permet d'assumer l'échec. Et l'échec est la source vive de l'innovation. Nous pouvons innover, tester, nous tromper sans perturber l’ordre des choses.

Ne pas avoir peur de l’échec permet aux équipes de repousser les limites et les normes et de réaliser l’impossible.

C’est cette capacité à accepter l'échec qui nous fait aimer les micro services.

Note : Captain Dash commence une nouvelle série d’articles sur les Microservices. Certains sont techniques, d’autres moins. Notre objectif est de considérer cette forme d’architecture que nous utilisons et de la rendre compréhensible pour le commun des mortels. Ces articles seront publiés tous les dimanches. Donc suivez-les sur Twitter ou abonnez-vous à notre blog et recevez votre mise à jour hebdomadaire sur cette fabuleuse architecture qui est en train de changer la façon de faire des affaires !

 

Micro Services - A Case for the Sidecar

One of the most fascinating traits of Micro Services is that they are polyglot or as we like to say here at Captain Dash – they are a Google translate that works.

There are obvious advantages of such an architecture, the biggest being that we can use the best tool for getting a job done.

On the other hand it has its fair share of challenges, the most prominent one being that separate libraries need to be maintained for each language used. While such an overhead seems acceptable for 2-3 languages, what happens when we are dealing with 6-8 of them?

Organizations traditionally used virtualization to tackle this issue but with the arrival of Docker on the scene most have moved to containers because of lower overheads. But, containers in Micro Services do exactly what they do in a home – they hide the mess not get rid of it! In this case the libraries still need to be built to facilitate communication except they are containerized.

Here is where sidecars come in. Named after the sidecars on a motorcycle a sidecar is a second application that runs alongside the Micro Service it is attached to and provides a language neutral interface for the micro service to communicate with. It can be said that a sidecar is a glue code that allows for the assembly of various Micro Services components.

Many teams are currently employing sidecars successfully for example Netflix and AirBnB.

They do, of course, come with certain disadvantages. The most obvious being that in process communication is smoother and less prone to bugging. Another issue being that sidecars cannot effectively access all the information inside the parent application.

There is also the point to consider that eventually sidecars will become obsolete because the Micro Services systems are evolving even as speak. Until that happens though the sidecar pattern is a great tool to add to your Micro Services set to facilitate communication and language neutrality.

To stay updated with our series on Micro services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma Meghna Verma is the CMO at Captain Dash.  You can reach her on Twitter @M3GV3RMa .

 

Micro Services are not a Silver Bullet

if you can’t build a well-structured Monolith, what makes you think you can build a well-structured Micro Services system?

Read More

Micro Services - Reasons For Partitioning?

A few posts back we spoke about how Microservices affect organizational structure and how the structure of an organization mirrors the structure of its architecture. By structure of an architecture we basically mean partitioning of that architecture and hence the organization.

So, now we are faced with the question of why should one partition the system? The simple answer, of course, is agility. The biggest reason for any organization to switch to Micro services is to be agile.

And agile is all about individuals; how they decide to work together and build software that are aligned with their business goals.

There are a few broad reasons why businesses partition either their organizational or their software structure:

Comparative Rates of Change

Different parts of a system often have different rates of change relative to each other. Some portions might need to be changed on a weekly basis while others annually. In a case such as this a partitioning is usually required so as to make the more frequently changed parts to be more independent.

Autonomy of Teams

Sometimes it is easier to split up teams and systems so that different teams can work independently on different parts of the system without being affected by each other’s work and speed. Here the teams are usually created so as to mimic the independently partitioned system parts.

Domain Boundaries

A complicated system often calls for extremely strict and independent boundaries of its business domains. This is to make it possible for each business unit to be completely self-sufficient and thus be independent of the functioning of any other unit. This is usually what we called decoupled business units. Having separate teams and modules taking care of these domains is usually a good idea.

Non-Functional Facets

Usually different parts of a system will have differing non-functional facets, which put them at odds where, needs and resources are concerned. This is the reason that Monoliths are difficult to scale since the entire system needs to be scaled even if only one single component needs it. This is another reason businesses consider partitioning their systems since doing so helps them to better assign their resources and invest their energies.

The bottom line? No matter what the reason for the partitioning maybe the goal is agility!

To stay updated with our series on Micro services architecture follow us on twitter or subscribe to our blog.

 

Written By: Meghna Verma Meghna Verma is the CMO at Captain Dash.  You can reach her on Twitter @M3GV3RMa .