Love that KPI, but let it go!

There is a saying that if you love something let it go, if it comes back it was meant to be. Sometimes companies tend to latch on to their KPIs for too long. The question is how long is too long? There are three ways to figure out if it is time to let go of a KPI:

The KPI has achieved a target and is stagnant

KPIs are meant for measuring very specific metrics and should have specific goals that define the purpose of the KPI. The basic idea behind this is to put into place improvement measures that help the team to achieve those goals. But, the fact is that not everything can be improved upon forever.

For some KPIs when they reach their goals the organization needs to take a step back and ask whether they are a priority anymore or not. If these KPIs have a lower priority since they have achieved their goals as opposed to KPIs that are still in progress then it is time to let those KPIs go.

It is better to pour resources into things that actually need to be improved instead of trying to improve something that has already reached the desired level of improvement.

Change of strategy

As a company grows and changes there are bound to be changes in the strategy and future goals. If the organization has a set of strong, well performing KPIs then their KPIs will be well aligned with their goals and strategies. As changes come about some of these KPIs will no longer be in alignment with the new strategies.

If a KPI no longer aligns with the goals of an organization or a team then it needs to be let go to make space for one that does.

Usefulness

Choosing KPIs is a science but also an art. There are times when a chosen KPI does not measure up to the expectations a team may have had. In the case where a KPI is found to not serve its purpose or found to affect other areas negatively it needs to be let go.

Letting go of KPIs does not mean to just discard them. It means that they do not have a place on your dashboard for the moment.

When letting go of a KPI the best practice is to archive the KPI so that it can be retrieved as and when needed.

Written By: Meghna Verma

 

Micro Services – Dealing With The Turf Wars

This past year we have witnessed how many companies have successfully integrated Micro Services into their architecture. In fact, 2015 has been touted as the year for Micro Services. It is all very fine for certain visionaries in an organization to push for Micro Services adoption from a strategic point of view but it is often found to be difficult to get people on board. Now, if it is indeed that great of an idea then why is it so difficult to convince teams to adopt them?

The answer is very simple – Turf!

Mostly the data in organizations exists in silos and is utilized as such. The problem that Micro Services present to such a way of functioning is that they represent a different way of doing things where managers often have to loosen their hold on their data. Thus, turf wars come into play.

There are some measures that can be taken to make a smooth transition in such a case:

  • Start by creating Micro Services for new application features to begin with. As development progresses work on refining and making changes where they need to be made.
  • To begin with keep the teams working on Micro Services separate from the team working on the monolithic architecture.
  • Provide the time and support to various teams to explore how Micro Services work and incorporate them into their work process.
  • As the Micro Services structure progresses encourage the teams to intermingle, have exchanges and facilitate cross training of skill sets.
  • As the skill differences become smaller and the comfort level of various teams increases start the breakdown of silos – both in terms of teams and data utilization.
  • As the Micro Services architecture expands start sliding slowly from the monolith to micro services.
  • Create standardized templates for development to make the creation of Micro Services easier.
  • As the architecture and the culture it brings get accepted across the organization start pruning the older Micro Services and replacing them with finer, more current ones.

While, it may be difficult to get everyone in an organization on board with Micro Services it is well worth a try as it can not only create better, more scalable software it can also help build better team dynamics.

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

Written By: Meghna Verma

If You Internet, You Micro Service!

If you are reading this post you use the Internet. You may be a developer with an interest in Micro Services or you may not be, but you use the Internet. Here is a secret I have for you, if you use the Internet then Micro Services are already a big part of your life.

The Internet as we knew it has changed significantly. You no longer have to be a developer to create a website, the maximum social interactions most people have today are via the Internet and an even more drastic change is that Apps are a bigger part of our lives than websites are.

We use Apps for everything: social websites, communication, photography, shopping, tracking our health, travelling, reading; the list is endless.

These Apps are further connected to their respective websites and backend elements to help us communicate seamlessly with our mobile devices, computers and clouds. All of this communication is very complex and as our devices and data grow the complexity increases. This is where Micro Services come in.

Micro Services and their respective APIs are what make it possible for this complexity to function in the first place. They make it possible for the developers behind them to create that seamless user experience.

But more than that what this revolution called Micro Services brings to the Internet is a break down of silos. They are not just allowing apps to communicate they are encouraging them. They make it possible for developers to connect, share and push the acceptable norms.

All the Big Data that is floating around in cyber space is of use to us only if it is connected, channelized and shared. It is of use to us because Micro Services make it useful.

We can watch a Netflix movie chosen according to our preference on our phone because these tiny services make it possible. We can shop online using an app because Micro Services make the connection.

Without Micro Services channeling the data, creating and upgrading services quickly and communicating in a dynamic manner would be a big challenge. The way we interact with our devices and with the Internet in general would not be the same.

So, if you do indeed use the Internet then you definitely use Micro Services regardless of whether you know it or not.

In fact, at Captain Dash we believe that going forward doing business without Micro Services will not just get difficult but impossible!

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

Written By: Meghna Verma

Sexy Data = Smart Data + Beautiful Data

At Captain Dash we believe that data is sexy. Data is smart enough to tell a story and beautiful enough to delight your senses. Or at least it can be all those things. Smart Data

The world is already overwhelmed with data and the number of devices producing data outnumbers humans. This number is all set to explode by 2020.

What this means is that data is not going away and it IS the future.

As data has increased everyone has jumped on to the bandwagon of creating metrics. Everyone wants to know every possible thing that data can tell him or her.

As a generation we have become pros at adding performance metrics to as many things as possible – our health, our businesses, dating sites, even our social interactions!

But these metrics are just numbers again without the right context and the right vision. This is where story telling comes in. All the data that you or your business generate can tell a fascinating story when the right KPIs are applied to this data along with supporting facts, understandable charts and finally correlation.

Beautiful Data

Humans are visual beings. Not only do we judge people and things based on how they look but we digest information in matters of seconds when represented visually as opposed to the minutes or hours it would take to read it or listen to it. On top of that it is easier for us to retain a picture over a book.

So, of course visualizing data is key. But visualizations needn’t be boring pie charts. Visualizations should be harmonious, sleek and impactful!

They should make the viewer stop and spend time on them.

Sexy data

When you combine these two elements, the correct data with beautiful visual representations of it’s story, you have on your hands what we call sexy data.

This is the kind of data that is intuitive, hits the mark and is appealing to look at.

Going forward, the success of data depends entirely on turning the vastness and complexity of data into something simple and intuitive enough to attract its viewers.

Hence, how sexy your data is depends on how smart and beautiful you make it!

Written By: Meghna Verma

Micro Services - Preparing for the Transition

We have often talked about how working with Micro Services brings about changes at many levels in an organization. Today we will tackle the how to prepare for these changes to come and the transition can be made smoother.

The 3 main things to consider are services, dev-ops coordination and security.

Services:

Aside from changing network speed and construction, Micro Services tend to have a huge effect on the services associated with the applications. Given the loose coupling necessary to obtain a functional Micro Services architecture the dev and operations teams need to divide their network services between those directly associated with applications and those that are not.

Service discovery needs to be implemented as well. The tool used for this needs to be equally dynamic on and off cloud. The service discovery has a direct impact on your infrastructure since it affects how the services interact.

In addition to all this the rise of containerization services has led to a need for compatible management services to make the workflow smoother.

Dev-Ops coordination:

Making the transition to Micro Services is not especially easy on teams and because of this the development and operations teams need to work in synchronization to facilitate this transition.

Ideally in a Micro Services structure exclusively one team from start to finish handles each application, but often, if your team is small this does not happen. Instead the team is handling multiple applications and sometimes working with other teams. In such a scenario the operations and development schedules need to be synched to perfection to make for smooth deployment.

Security:

Security is not something one thinks of first hand when considering transitioning to Micro Services. The biggest advantage of this infrastructure is the agility it affords and every malicious attack that your security blocks, is one less stress on your application. Thus, a sound security system helps your applications to perform stress free and with the required agility.

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

Written By: Meghna Verma

The KPI Curse

KPIs have a way of turning many organizations on their heads. Sometimes this happens because there are too many KPIs and too much data being gathered but often times it is because KPIs are misunderstood.

KPI stands for Key Performance Indicator with the emphasis being on indicator though people often tend to put the emphasis on performance. Due to this, KPIs more often than not become very closely entangled with targets.

At Captain Dash when we consult with our clients over KPIs we advice them to narrow their KPIs down to metrics that are closely related to the global goals of the organization.

By this we mean that KPIs are not the goals themselves; instead they are indicators of said goals. For us, KPIs help us to measure certain data points that help us to determine the progress made towards achieving our goals and delivering on our key priorities. This thus implies that KPIs indicate whether we are on track or not. They exist to provide objective information, which helps us to strategize better.

If on the other hand when one uses KPIs as targets they end up as short-term numbers to be achieved by departments and just serve as a scorecard more than anything else.

There is of course a reason why KPIs and targets get mixed up together. Other than the fact that they are both metrics there is the fact that for KPIs to work they need targets or benchmarks. It is very easy to see these targets as the targets that the organization or departments need to achieve.

Do not let them confuse you, these benchmarks serve as a reference point to see if we are on track and how much adjustment is needed, if any, in our strategy.

If you use KPIs are the indicators they are meant to be and let them guide your strategy they end up as very powerful tools to guide improvements across the organization.

On the other hand, an indicator that you could implement to measure progress could be the Key Transformation Indicator or KTIs.

Written By: Meghna Verma

 

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

How to Read a Sankey Visualization

n dimensions + 1 metric

Shows the distribution of a metric on several dimensions, with the value of each dimension’s distribution shown on the next dimension.

Example : It’s possible to distribute the “visits” metric on a “types of visitors” dimension where the values could be “new” and “known”, then distribute the “new” and “known” on a dimension “sex” between male and female.

For Example: Let's say you want to track the entire journey of your visitors. Which channels do they come from? Which pages do they land and leave on?

You can clearly see that the majority of your visitors are new.

Sankey New visitors

Most of your new visitors come directly to your website via url, but a significant portion also come from referrals.

sankey referral

Your known visitors mostly come from organic search.

Sankey organic search

All of your organic search visitors accessed your website from google.com, and most of your referred viewers come from designmodo.com, designfestival.com or forum.vietdesigner.net.

sankey google

sankey designmodo

What about landing pages?

Direct and organic search visitors land on /the-company, /the-product or /home pages.

sankey companyUh oh...your referrals are landing on your /404 page.

sankey 404 You must have removed a page from your website which was referred to by an external link. Something must be done about your 404 page and your /511 page because people land on it and leave without ever finding your home page.

Is this the journey you had in mind for your visitors?

In order to play around some more with Sankey Visualizations you can head over to the visualization lair at Captaindash.com.

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 .

 

How to Read a Treemap Visualization

1 dimension (hierarchical or not) + 1 metric

A Treemap visualization represents a hierarchical dimension by encoding a metric on each node of the hierarchy.

Example : The hierarchical dimension of geography. On the first level, we can see the distribution of the metric between continents. We can then explore a continent to see the distribution between countries, etc.

Let’s say you want to check out where your visitors are located.

 

 

Treemap Captain Dash 1

Let's Analyze A Bit

At a mere glance, we can see that nearly have of your visitors are in Europe, a quarter in the Americas, the remainder in Asia, and but a few in Oceania and Africa. The “Explore” button gives us a closer look at Europe, revealing that half of those visitors are in the West and the rest are split evenly between North, East, and South.

Treemap Captain Dash 2

Another “Explore” click and we see that more than half of your Western Europe visitors are in France.

Treemap Captain Dash 3

A look at the Americas reveals that the United States accounts for 86% of viewers on the continent.

Treemap Captain Dash 4

Is that where you should open your new office?

In order to play around some more with Treemap visualizations you can head over to the visualization lair at Captaindash.com.

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

Streamlining KPIs

Measuring performance and aligning goals are synonymous today with KPIs. The most commonly heard complaint is how there are so many KPIs to measure. But, the way to make sure that you are on the right track is to pick out 5 to 10 KPIs.

Why? Because KPIs often have a way of getting confused with metrics. Yes, KPIs are metrics but not all metrics are KPIs.

Any activity that can be measured can be a metric but a KPI has to drive a competitive advantage.

So, what are the key points to be considered when you want to narrow down your metrics to just a few KPIs?

Know your starting point: Take a stock of where you stand with your objectives and metrics. Which metrics are still relevant, which ones are redundant and which ones are missing. What are you already doing at this point and where do you want to go from here.

Build downwards: Start to review your architecture from top down. From goals and results to the methods of achieving them and then down to the measures. When you reach the KPI level you should be able to distribute and allocate them easily.

Vet any new metric: With the amount of data we have coming our way it is very easy to have new metrics all the time and they all seem important to some stakeholder or another. You need to start vetting any proposed metric with a checklist so as not to add senselessly to your core.

Perform maintenance: Periodically go through your KPIs and see if they still serve the same purpose. See if they need to be looked into with the same frequency or can the frequency be reduced. This helps to make sure that no unnecessary components remain on your dashboards. Do not be afraid to replace one KPI with another if that is what works for you.

kpi-298x300.jpg

Of course the cliché of it all being industry related holds true in the end. The thing to remember is that while there is no golden rule the alignment of KPIs with goals is the formula to work with.

Read about Choosing the KPI that works for you.

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

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 .

4 great videos to watch on Micro Services

1. Practice Considerations for Micro Services Architecture By Sam Newman, tech consultant @ ThoughtWorks

Screen Shot 2015-07-07 at 15.59.38

 

A great talk on the practical aspects of the Micro Services architecture. Sam Newton talks about things you need to learn along with the challenges you can face and how to go about navigating your team through the implementation of such architecture. He talks about his own experiences and what he learnt from his own failures.

2. Services and Rails: The Shit They Don’t Tell You

By Brian Morton , software engineer @ Yammer

Screen Shot 2015-07-07 at 16.08.49

Brian Morton from Yammer talks about how to build services and integrate them into rails. This talk looks into mistakes made, solutions that worked for Yammer, monitoring cost versus viability, teams and how Yammer has ben able to move quickly. Overall a comprehensive talk that is easy to follow even for non-engineers.

3. Microservices

By Martin Fowler, programmer @ ThoughtWorks

Screen Shot 2015-07-07 at 16.01.44

A video by Martin Fowler has to be included in this list. This video discusses what are Micro Services, what they do, how they differ from monoliths and whether they are such a new concept after all or not. This is a basic, introductory talk on the subject by one of the people who has explored it in great depth. His blog is a great read too for someone interested in further information.

4. The Business Benefits of Micro Services

By Russ Miles, chief scientist @ Simplicity Itself

Screen Shot 2015-07-07 at 16.02.24

A short, to the point video on how Micro Services can benefit a business beyond the dev team. This talk is for everyone whose company has invested in or is thinking of investing in a Micro Services architecture. It helps people who are the most removed from technology in an organization understand exactly how Micro Services can help a business compete and stay alive.

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 - Communication Between Services

Applications change with time and need but the business capabilities stay the same. Aligning our services and thus, the teams around our capabilities help us ensure that communication is not a hindrance.

Read More

Le côté obscure des Micro Services

the-dark-side1Les Micro Services fonctionnent car ils réduisent la friction; ils permettent flexibilité et innovation.

Mais ils augmentent aussi le risque !

Avec les Micro Services, les responsabilités sont multipliées.

Les équipes doivent travailler sur des produits plutôt sur sur des projets. Les ingénieurs doivent être bien renseignés en outils de DevOps.

A priori lorsqu'une structure informatique est divisée en une multitude de micro-applications les choses sont plus simples.

A première vue seulement, car connecter entre elles et produire les interfaces liant ces composants peut recréer une complexité conceptuelle et technique. Il suffit que le processus ne soit pas bien pensé et manque de réversibilité pour que surviennent des latence dans le réseau, des problèmes de synchronisation et des pannes contextuelles.

Avec les Micro Services il faut rester simples. L'informatique est par essence complexe. Il ne sert à rien d'inventer des services superflus ou de modifier des éléments qui fonctionnaient correctement.

Le vrai risque des Micro Services est d'exporter la complexité d'une informatique Monolitique en dehors du système, la rendant ainsi plus dure à contrôler et superviser.

Une approche pragmatique, orientée "produit", peut limiter les problèmes posés par les micro-services. L'enjeu est de penser "produit" et "métier" avant de penser "services" et "informatique".

Chez Captain Dash nous adorons travailler avec des micro-services et croyons qu’ils représentent la vrai révolution de la data. Mais nous ne perdons jamais de vue la vision du client et le but final car c’est ce qui est le plus important au final.

Note : Captain Dash commence une nouvelle série d’articles sur les Micro Services. 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 !