Tag: diagrams

  • Making the Data Work for You: Data Visualization Techniques

    Making the Data Work for You: Data Visualization Techniques

    When Peter F. Drucker, the father of modern management, performed a two-year in-depth analysis of the General Motors corporation in the 1940s, he undertook what may have been the world’s most ambitious big data analysis ever at that time. However, when he gave the results to GM chairman Alfred Sloan, Al was not happy.

    In fact, Sloan refused to acknowledge Drucker’s work. He never mentioned it again and banished his colleagues from referencing the resultant book (Concept of the Corporation) around him.

    Alfred Sloan may not have been ready to act upon the harsh reality of his company’s data, but modern businesses thrive on this sort of analysis. Big data has consumed every industry on earth, from automobiles to cosmetics to hotels and far beyond.

    Businesses that use the power of data visualization will outperform the ones that don’t, every time. If you are responsible for the success of a B2B business, this article is going to show you why data visualization is one of the most powerful tools at your disposal.

    The Goal of Data Visualization

    There are two ways you can use big data visualization tools to make your data work for you. You’ll make it easier to parse your own data, identifying trends and finding opportunities to improve your business. You’ll also use it to convey your ideas to other people, improving your conversion rate for B2B sales that can make or break your bottom line.

    Understanding Your Data

    When it comes to better understanding your own data, visualization is everything. Even a small business has an incredible amount of data at its disposal. Social media statistics, front-end stats such as how long users spend on certain web pages, sales and refund statistics by time of day and product … the list goes on and on.

    You have to start by figuring what data is most relevant. Ed Baker, former head of growth at Uber, points out that every great business needs a “north star metric.” This is the single variable that, if it improves, the entire business does better. Once you identify your north star metric, you can see how other variables feed into that metric. Data visualization is crucial for parsing the information and making these big decisions.

    Conveying Ideas to Other Businesses

    You can use well-visualized data to convey ideas to other people that might be near-impossible to express otherwise. Have you ever sat in a meeting, desperately trying to show somebody why your idea makes sense, and yet completely failing to do so?

    I’ve had conversations where my brain is about to melt out of my ears, because I think I’m making perfect sense yet the other party simply does not grasp the idea. In a B2B context, this failure to communicate can cost hundreds of thousands of dollars. That’s a critical failure to get the job done. Data visualization is a very cost-effective way to improve your odds of making the sale.

    When you’re trying to sell a premium service or product to another business, don’t just tell them why it makes sense—show them. Use the visualization techniques in the rest of this article to remove all doubt that you’ve got the right idea.

    The 7 Basic Tools of Quality

    There are dozens of different ways to visualize data. It depends on what kind of information you want to look at. However, the best way to start is by understanding the “seven basic tools of quality.”

    Made famous in post-war japan by Kaoru Ishikawa, these tools are simple yet potent data visualization methods that most people can learn in a few hours. While not the most intricate or powerful visualizations available, they are elegant and widely understood. When you use one of these tools, you can rest assured that everybody at the table will be comfortable following along.

    You want to use these methods of visualization whenever it is possible. Only move into more esoteric or powerful tools when the situation necessitates it. By the time you are working with complex multi-variate data visualizations, you’ll probably need a dedicated data scientist to make it all work. These tools are an easy and cost-effective way to get started.

    Here are the seven basic tools, with a brief synopsis of how each one works:

    Cause-and-Effect/Fishbone Diagram

    A quick and simple method to use when you are working backwards from a known outcome, asking the question: “Why did it happen?” This tool is often too simple for detailed analysis, but can be great for mid-conversation visualizations on the back of a napkin.

    Check Sheet

    We’ve all used check sheets in our day-to-day lives. This is a great way for small groups to keep track of simple data, such as, “How often are the following conditions being met?”

    An example of a check sheet in action would be a coffee shop that wants to track common issues with customers. You could have the barista check a box whenever something goes wrong: Customer says drink tastes bad, customer leaves before drink is ready, customer gets confused while ordering and becomes agitated, etc.

    Control Chart

    This is a X & Y axis chart where the horizontal axis is the flow of time and the center of the vertical axis represents the average value of the other variable. The top and bottom of the vertical axis are the outer bounds for that variable. The control chart is a simple way to visualize data for a single variable moving through time.

    Histogram

    You’ve probably heard the word “Histogram” a lot, but may not know what it is. This is a chart where the horizontal axis consists of columns representing one variable and extending upwards to show the relationship with a second variable on the vertical axis.

    Pareto Chart

    A chart consisting of columns and a line, sort of like a blend between the Histogram and the Control Chart. However, Pareto charts do not necessarily reflect the passage of time. The columns are always ordered from largest to smallest and the line is the sum of the data represented by the columns.

    Scatter Diagram

    This is a simple diagram that plots two different variables with lines across an X and Y axis, meant to show correlations between them.

    Flow Chart

    Also known as an “if-than” chart, this shows the potential sequence of actions or thoughts within a mental or physical process. For example: If the client likes coffee, ask them how they like it. If not, offer them water. If the client says they like the coffee with cream, add cream. If not, prepare it black. This sort of data is awkward to express through pure language, but quite easy to grasp when placed in a flow chart.

    Advanced Data Visualization

    There are many, many forms of advanced data visualization. This is the stuff that Peter Drucker was trying to do back in the 1940’s—capturing huge amounts of data across an entire corporation and then synthesizing it into the most elegant possible form.

    If you want to go beyond the seven basic tools, you’ll need help. This isn’t the sort of thing that an employee or even an ambitious executive can tackle over the course of a few days. A team of data experts will need to spend a lot of time and energy to craft the perfect visualizations for you. With that said, here are a few advanced techniques to consider:

    Heat Maps

    Heat maps are used to show density of activity across a geographical space. This can be utilized to understand city traffic, or to look at where your employees spend time within an office building.

    Beyond the physical world, you can use heat maps on websites to see where users tend to move their mouse, or even where they tend to glance at. For example, video game developers and social media platforms use heat maps of user eye-gazing data to optimize their visual layouts.

    Word Clouds

    A word cloud is a visualization where many different words are scattered about in a “cloud,” with larger words being more common. You can use these to understand the most common sentiments being expressed in customer reviews, company emails or other text communication.

    While cheap word-cloud-generators exist, there are many reasons why they do not work. An effective word cloud needs to deal with factors ranging from color to glyph shape and beyond.

    Comparative Graphs

    Comparative graphs combine several copies of the basic power tool charts, by for example putting several control charts on top of each other to compare larger numbers of variables and factors. While comparative graphs are simple to understand in theory, they are difficult to put together in a way that is practical.

    Using Data Visualization for Your Business

    The best way to understand data visualization is to give it a try. You can get started with basic visualizations on your own, but you’ll want to contact an expert to really make your data work for you.

    After all, it isn’t enough to put a few variables into a chart. You need to understand how to collect the right data, compile it into useful visualizations, and then act upon that data in an effective way.

    About the Author / Alexey Semeney

    Alexey Semeney is the CEO of DevTeamSpace, where he leverages his knowledge and expertise in product design and remote team management to build a unique software development platform. Connect with him on LinkedIn.

  • Advancing DevOps with Diagrams

    Advancing DevOps with Diagrams

    The Application model can be incredibly useful to map out application features, planned changes and current flaws, and even for roadmapping. The model takes organizational time and effort, and can only be created and maintained when a universal language has been developed by a modeling team. The effort is well worth the cost, however, since it can lay the foundation for a better DevOps environment.

    The modeling team will represent various organizational backgrounds and must bridge gaps of understanding that are common between technical and non-technical personnel. The team also will include operations and development professionals so that collaborations produce not just deeper understandings, but also lay framework that meets, corporate, Dev and Ops needs from the beginning.

    Diagrams can be used by the modeling team to foster the understanding and creation of a universal language by adding more context to ideas and processes. Diagrams serve as a drill-down exercise and can be drawn on a whiteboard, sketched on a notepad or formalized with a UML tool.

    Diagrams become more technically correct as they are iterated on, and can be easily retained for future discussions. Further, the base of some diagrams often enable other types of diagrams that can be helpful to the development team (such as Class or ERD) and provide a level of technical documentation. They also provide a base of discussion for the modeling team to relay discussions back to their organizational units for feedback and improvement.

    Last, and perhaps most importantly, diagrams help to remove ambiguity that is inherent to narrative descriptions and discussions. Removing ambiguity is at the heart of the universal language and enables clear communication, a key tenant of DevOps.

    We can show this drill-down in diagramming by focusing on a small and simple operation: describing what happens when a new customer enters a banking system for a business loan.

    UseCase Diagram

    A common place to start is a UseCase Diagram like the one below.

    The diagram shows a few key points of data:

    • There are two types of employees (actors) that are involved: a Loan Officer and an Underwriter
    • The Loan Officer and the Underwriter interact with three business elements: Client Files, Credit Requests, Requested Information

    This diagram might not seem very useful to those outside of the discussion, but it is the first step to creating more in-depth and useful diagrams.

    Activity Diagram

    A logical and easy step from a UseCase Diagram is an Activity Diagram. It takes many of the same concepts and expands them to a step-by-step order of procedures, which are established by discussion of current procedures as well as compliance and regulatory needs.

    By partitioning procedures into vertical “swim lanes” we now have an order to the processes as well as who or what is responsible for it.

    The first partition, labeled Loan Officer, shows three processes (Create a Client File, Create a Credit Request, and Upload Financial Statements) that they are responsible for before the system can do anything. All three pieces must be present before moving beyond this first position.

    Once those items are taken care of, the system then notifies the second Actor, the Underwriter, that there is a credit review for him or her to perform as well as where to locate the needed data.

    The Underwriter then decides whether the loan is approved. Whether this is a semi-automated process or done entirely by humans is beyond the scope of this diagram; all we need to know is that a decision happens next. What we can see is that the Underwriter has two options. He or she can:

    1. Decide on the loan (approve or deny—again, beyond the scope), at which case the system takes over from there.
    2. Request more information from the Loan Officer (perhaps the wrong files were uploaded or more data from the client is needed). The system would then notify the Loan Officer and the process starts over.

    Activity Diagrams are useful for documentation because they start to add structure to the overall business process. They also start to define which processes are:

    • Managed by humans
    • Managed by the application being developed
    • Represent a system that the application will interact with, and operations will need to secure

    Even if not 100 percent technically correct (as our sample isn’t entirely correct), they still represent information in a meaningful way that anyone with little or no guidance can understand.

    Data Flow Diagram

    With Data Flow Diagrams (DFD) the diagrams start to map out the system and procedures that happen and the flow of data. DFDs, which are more involved than the other diagrams so far, become keenly useful in showing how different processes interact. Even though DFDs become more detailed as more layers are added, they are still understandable and explainable to any member of the modeling team no matter the background.

    Operations teams often find them helpful since they map out when sensitive data may be accessed or stored. In our example, things such as corporate tax returns will be stored and accessed; there obviously would need to be some security measures implemented to ensure only those with clearance can see them.

    Discussions are key when creating Data Flow Diagrams because it would be very rare for an individual to have all of the knowledge needed to create one without questions and answers. Based on our current diagrams and a few questions such as:

    • Are Client IDs manually created, or is it part of a system?
    • Do requests go to specific people or are they delivered via queue?
    • Is the credit decision part of the original application or saved as a separate file?

    A DFD can be drawn up:

    The DFD may look complex at first, but when taken piece by piece it is quite simple and understandable with very little (if any) explanation. It also can be helpful to the Dev team because it isolates specific processes at a granular level.

    For example, the Dev team may see the process “Get ID,” know that it’s a system process (non-manual) and realize that they already have a module like that in an existing application that they can use for this application.

    Of course, this would be one of many DFDs created during an Application Model, which is another key advantage of using DFDs. Data Flow Diagrams can be layered, starting with a context diagram and working down granularly to the smallest process needed. This layering also naturally helps to break down the application to discreet parts, helping both in creating different parts of the Application Model as well as having natural starting and stopping points for conversations.

    With the idea that there can be many diagrams used during these discussions, it can be useful to use a modeling tool to easily create, edit, layer and store the diagrams for future use.

    Other Diagrams

    Of course, these are only a few diagrams, but they demonstrate how a process of diagramming can be useful to help a modeling team communicate. While a team could start with a Data Flow Diagram, it would be a much more difficult process. However, by walking through a UseCase and an Activity, it becomes easier since it breaks a system down into digestible parts.

    It also provides the modeling team easy-to-understand diagrams when they go back to their business units. They can explain the Application Model and get quality feedback, as well as suggestions to be added into the Model.

    These diagrams also can be helpful for teams as a starting point for documentation. The DFD is a good starting point for:

    • The Development team to create a detailed class and component diagrams that outlines the application architecture.
    • A deployment diagram for Operations to note which data to isolate behind a firewall with limited access.

    While no process of diagramming can create a universal language by itself, diagrams are supremely helpful to create team clarity. They also serve as a memory of Application Model discussion so that human error and memory can be reduced. Last, by helping to eliminate ambiguity among the modeling team, they help drive better communication that is part of the essence of DevOps.

    Note diagrams were created in Astah Professional and used with permission. To learn more about Astah and modeling please visit the company’s website.

    About the Author / Scott Reece

    ReeceScott Reece is a huge fan of the greater visibility and communication enabled by DevOps. As a Friend of Astah Scott has been successfully closing project communication gaps by using models and team building. With more than 10 years of project management experience, Scott currently serves as a Partner Director at Inedo.