Analytics dashboards are interfaces for viewing, interpreting, and exploring summaries of complex data. Dashboards may be used to report on the status of complex systems such as those found in large scale business, scientific, or logistical operations. Dashboards often combine multiple charts in a single view to be printed or viewed on a screen. Charts are named patterns for ways to create graphics to represent data. Different types of charts (line, bar, pie charts), and components of charts (title, legend, axis) are easy to create using software packages. Certain of these ways of representing data are widely useful in a variety of applications, so we call these “patterns”. However, there are many commonly used charts and chart components that are poor at accomplishing their intended purpose, or are often abused by using them for the wrong purpose. We call these “anti-patterns”. What follows are some examples of anti-patterns for analytics dashboards, and some suggested alternatives.
Please note, though, that all of these patterns and anti-patterns have situations where their usage is merited. These are simply some cases where there are some other alternatives that should be considered.
Strengths: Emphasizes data is normalized, and highlights partitions of data (“slices”) with largest share
Weaknesses: Difficult to compare partitions of data (“slices”) to each other, difficult to label and compare smaller partitions, particularly with large number of partitions
Try Instead: Bar chart
Pie charts are some of the most commonly used data visualizations in business settings. However, this type of visualization is almost always suboptimal for a given task, or abused to the extent that it should
IT infrastructure for financial institutions is becoming increasingly complex. Modern banking infrastructure combines mainframe applications, monolithic applications based on Service Oriented Architecture, relational databases, and big data platforms. This complexity has led to “brittleness”. Under certain conditions, a failure in a subsystem of the infrastructure can lead to catastrophic failure of an entire business function such as clearing and settlement (see below).
BNY Lost Payments Capability for 19 Hours
In addition to lacking resiliency, these systems lack robustness. Robustness in the face of resiliency means that services degrade gracefully as subsystems become unavailable in a manner that is consistent with business needs. Finally, disaster recovery mechanisms must be put in place that allow full capabilities to be restored in a timely manner after subsystems have failed.
The key question is: What best practices can be employed to ensure greater resiliency and robustness for IT infrastructure?
Problem Description
System is Heterogeneous
Financial institutions today use a combination of mainframes, monolithic applications, relational databases, microservices, and big data platforms. Communication between these subsystems is done across a variety of different channels. These include mainframe communication fabrics, enterprise service buses, lightweight message queues, and integration middleware. Each of these have different ways of storing and transmitting state changes, transforming data, maintaining consistency, and queuing transactions and messages.
This makes it difficult to debug and restore systems when there are problems. There may be no central repository for debug information. Subsystems may have unknown dependencies. Messages and transactions lost in-flight may not be recoverable in the event of system failure.
Legacy Systems
Banks and other institutions employ a wide range of infrastructure, some of it legacy in nature. Mainframes, in particular, have maintained backwards compatibility from generation to generation. This implies that some code may still be used in production after having been written fifty years ago! This code may be poorly documented, as well as difficult and expensive to re-engineer.
Centralized Databases
Many different applications and services may all be storing and retrieving state information from a single centralized relational database. This can cause a single point of failure and coupling between subsystems. The use of centralized databases are often mandated to reduce licensing and administration costs. However, in the era of FoSS (free and open source software), this restriction is no longer necessary.
Architectures Not Aligned to Business
The SOA, or Service-Oriented Architecture, decomposes enterprise software into business processes, services, service components, and operational systems. SOA architecture was designed to maximize re-use of software and hardware components. This design was driven by a desire to minimize software licensing costs (such as those for commercial relational databases and operating systems), and maximize hardware utilization. However, this created some undesirable consequences. If a business requirement changed, it would impact a large number of layers and components. The architecture makes it difficult to optimize components for each business, since they are shared. There are also problems caused by a misalignment of ownership between lines of business and projects for creating and maintaining various services and components.
Best Practices
Centralized Logging
All services and subsystems should subscribe to a central logging facility for debugging and monitoring purposes. This makes information available in a central location for analysis. Modern logging platforms allow for streaming and batch processing of data, and extensive analytics to be performed on log data across data sources.
Correlation IDs
Correlation IDs are identifiers that are passed between processes, programs, and subsystems in order to trace dependencies in the system. This design pattern is particularly important in microservices architectures where a business activity may be carried out by hundreds of microservices, and other applications, acting in concert. Centralized logs can be searched for specific correlation IDs to debug specific errors, and diagnose overall system behavior.
Bounded Context
As mentioned above, using centralized databases to store state information can create a single point of failure in the system. The microservices architecture dictates that context be bounded to each microservice. This means that each microservice is responsible for maintaining its own state. This shifts responsibility from a centralized, shared DBA team to the team delivering the microservices themselves. Bounded contexts reduce coupling between services, making systemic failures less likely.
Employ Domain Driven Design
As mentioned above, one of the main weaknesses of the SOA was difficulty in adapting services to needs that are specific to certain businesses. Adoptees of microservices architectures are attempting to change that by recognizing the importance of domain driven design in best practices. DDD should be used to determine how best to partition services along business lines. In addition, DDD can drive definition of what behavior should be exhibited in the event of subsystem failure or degradation in performance. For instance, if an AML (anti-money laundering) service fails to respond, perhaps a manual approval user interface should be presented to administrators. It is important to keep in mind that failures can be partial, can cascade to other applications and services, and may only show up when a service is interacting with other parts of the system. Resiliency and disaster-recovery requirements cannot come purely from a technical understanding of the system. These requirements must be driven by business requirements from the domain.
Reengineer Legacy Subsystems as Appropriate
Legacy code and systems are often portrayed as the immovable object of IT. Rather than assuming that legacy code cannot be changed or replaced, changes should be prioritized based on business requirements. Legacy programs may have static routing, have inadequate logging, or may have bugs that can put business continuity at risk. If legacy code shows any of these weaknesses, and is a high priority to fix given business considerations, it may be warranted to migrate them to a new architecture or fix the bugs in the current program.
Are you learning about Agile software methods, but aren’t sure how to apply them to global software? This article explains how to do globalization in an organization using Scrum as a methodology.
The primary activities of software globalization are internationalization, localization, and testing. We will describe how each activity maps to the Scrum process.
Software Internationalization (I18n)
Software internationalization is the process of architecting and writing software so it will function properly in multiple countries. It involves designing software in a modular fashion so new countries can be easily supported by swapping out language packs and software libraries, rather than rewriting lots of code. This is a primary engineering task, and is well-suited to being done with Scrum. Requirements from international customers tend to change rapidly, so using Scrum to address these requirements in an agile fashion is a great idea.
Functional Testing
This is functional testing that is specific to the internationalization process. This verifies that generic features can be used by international customers, and also verifies features that are specific to certain international market segments.
Data on 3G subscribers is from Mary Meeker’s ‘Internet Trends 2010’ presentation from Morgan Stanley. Created using Tableau Public visualization software.
What can we learn from these charts? First, let’s look at ARPU growth. It seems there is fairly broad pressure on ARPU across the board. The big players, however, are holding their own around 0% change in ARPU YoY. The highest ARPU is concentrated among US and European service providers. Note that AT&T’s wireline business is listed separately from the wireless business. The greatest drop in ARPU last year was felt by the smaller regional players in Asia and India.
Now let’s look at market cap for service providers versus blended ARPU and number of subscribers. It is interesting to see that firms with the highest market cap are placed along a line that maximizes either ARPU or number of subscribers. The small players in the previous chart likewise show up with low market cap, ARPU, and subscribers. They clearly have a long way to go to reach the profitable horizon of the big players.
Why is this important? Adapting a product for international markets requires checking your assumptions about the current product definition. If you know why you are doing something today for your current market, it will be easier to check if that will still be true in the new market. This way, the internationalization team will be able to adapt the existing product to the new market in a systematic way. Having a process for internationalizing a product saves both time and cost.
Segmentation
How do you define your current market segments? How do you group customers? By industry, sector, geography, job title, age? What are the unique challenges faced by each segment?
Use Cases
A use case is a specific way that customers get value from your product. Why do your current customers use your product? What problems are they trying to solve? Key use cases should be fully documented, including steps the customer takes to complete the use case. Many use cases are specific to a particular segment.
There are only two fields where it is legitimate to prove that something is true: law andmathematics. True scientific fields can legitimately prove that a categorical statement is not true, but should never attempt to prove a universal positive statement.
Nassim Nicholas Taleb discusses this at great length in his new book The Black Swan.
What is the point of science if it cannot be used to prove things? In The Structure of Scientific Revolutions, Thomas Kuhn argues that the entire concepts of proof and progress are problematic.
What is the point of thinking of things if we cannot prove that our ideas are true? Because ideas are useful. Science seeks not to prove things, but rather to build useful models.Models, such as the idea of the atom, are useful because they correctly predict observations. As we adopt new models and cast aside our old ones, the scope of observations we can predict increase. What matters is not the individual conclusions, but rather the method.
This is also true in the world of business. The received knowledge of market segments, product strategies, business models, etc can be limiting. If we apply some rigor to the problem, we may be able to tease out some insights that were not obvious before.
If we ignore our current assumptions and ask questions like:
Why do we group customers together the way we do currently?
Are there profitable segments hidden inside of submarkets or segment we have been serving more generically?
Could a particular product offering be split or combined with other offering to better address needs?
Is there a different distribution method that may be better suited to a submarket, promoting it to a full segment?
A personal pet peeve of mine is that many people in the technology business do not have mastery of even the basics of marketing theory.
I still have not met a technology marketing person that could correctly tell me the difference between a segment and a submarket.
Here are my definitions of the two terms:
submarket: a distinct group of customers
market segment: a group of customers that may be addressed by the same marketing mix
marketing mix: an offering to the market composed of a product or service and its associated price, promotion methods, and method of distribution
We start our market segmentation above by simply listing the different submarkets in columns. Any definition for submarkets are fine, as long as the members of each submarket are distinct from those in another. Next, we list the range of product or service attributes that we may want to offer. Then we populate the table by noting what attributes are applicable to each submarket. What we discover is that often certain product attributes are applicable to multiple submarkets! Submarkets that may be addressed in by the same product attributes are what we call segments. We can assign a name to a segment that encompasses each its submarkets.
Most often what happens is when I ask someone what a segment is, they recite a list of submarkets. When I ask them why those are segments versus submarkets, they say “everyone knows those are segments”. This can limit one’s thinking and prevent insights into the right marketing mix for the market.
I’ll discuss some ways to use segmentation to generate new ideas in later posts.
In the past few months I’ve adopted a radically different approach to communication than my peers in high tech marketing…
By definition, the approach most people take yields average results. The most popular techniques for doing things are those that yield some useful result with a minimum of effort. We all tend to sing or take snapshots or cook in a similar manner and achieve similar results. We can refine those techniques, but that just makes us better at being average. This makes us first tenor in the choir, helps us make eggs in the morning, or keeps us from crashing into things on our drive into work.
To go beyond the norm, you must take a radically different approach to the same problem.
That is why Ansel Adams prints are different from our summer snapshots, Mario Andretti drives differently from us, and why Whitney Houston isn’t in our church choir.
There are several drawbacks to taking the ‘differentiated approach’. The first is that by doing things very differently, we will achieve results that are either vastly better or vastly worse than the average person.
.
, Thomas Kuhn argues that the entire concepts of proof and progress are problematic.