Tag: customer experience

  • You’re Not Doing DevOps if You Can’t Pull the Cord

    You’re Not Doing DevOps if You Can’t Pull the Cord

    There are many concepts in Lean manufacturing that have applicability with software development “factories.” One example is the Andon Cord.

    The Andon Cord concept involves using signals and alerts to indicate that a station on the assembly line has a problem. Alarms are activated manually by workers pulling a physical cord or automatically by the equipment itself.

    Developed as one element of the Jidoka quality method and pioneered by Toyota and the Toyota Production System, the Andon Cord empowers workers to notify co-workers and management of quality and process problems across the assembly line—and even stop production.

    While pulling the cord to stop production sounds crazy, if a defect is found and can’t immediately be fixed, then pulling the cord means stopping the problem from flowing downstream, where it will be costlier to fix and have a severe impact on the customer experience.

    But the point of Andon Cord pulling isn’t only to fix problems. As part of a continuous improvement program, much of the “pulling power” comes from how it helps teams build quality into products and processes. When production stops, improvement begins.

    Many would argue that the application of Lean management concepts such as the Andon Cord is more challenging in software engineering. With software, there are many more opportunities for defects, and testing for problems only occurs late in the development cycle. So late, in fact, that in some cases customers end up doing most of the testing.

    But as the digital and physical world becomes inseparable, excuses and outdated practices are no longer acceptable. Just as we wouldn’t ask a customer to test air bag deployment in a car, we shouldn’t expect them to test whether a new software-enabled telemetry system is subject to security hijacks.

    So having the power stop software development production line to prevent defects, security problems and safety issues during the actual development process makes perfect sense. But how do you start?

    Automate Andon with Continuous Testing

    In many organizations people are often afraid to speak up about problems. Even if bugs are suspected, teams will cover up problems by coding around them, even fudging tests. Owning up to problems doesn’t come naturally, so defects and crippling technical debt accumulates. DevOps practitioners need their own version of the Andon Cord: fully automated testing.

    With DevOps promising software throughput at dizzying rates, quality must accompany the velocity. Fail here and the continuous delivery glass can only be half-empty. This is why the process must incorporate its own automated testing Andon Cord to prevent problems moving downstream. Automation must be comprehensive, providing maximum coverage at every stage in the software pipeline—from requirements definition to full production and including code quality, performance, security, compliance and test data. Then, when a test fails, the system must be capable of stopping everything until the problem isn’t just fixed but can’t happen again.

    Eliminate Waste at the Source

    If you’re pulling the cord but not making improvements you don’t have an Andon Cord. Consider a factory scenario where machine operators always have to sweep up dust that’s clogging production equipment—obviously, they should be eliminating the source of the dust.

    Unfortunately, many software engineering practices involve lots of dust-sweeping.

    When developers need access to dependent systems for testing, they might mock up test code. If QA needs test data in a hurry, it could copy production data but fail to mask sensitive customer details. In IT operations, staff console watch in the hope of gleaning signals from all the noise—the list goes on. Lots of sweeping without ever eliminating the source of the problem.

    Fortunately, tools with Andon-like capabilities can help. Service virtualization techniques can emulate dependent systems to remove testing constraints, while automatically generating synthetic test data helps eliminate the possibility of costly compliance breaches. Modern performance monitoring systems also play an essential role. By providing performance insights before, during and after every software build, they help cross-functional teams swarm problems when the cord has been pulled by an automated test.

    Build the Ultimate Cord – Customer Experience

    If an organization considers itself in any way customer-centric, it will be able to “pull the cord” when it detects anything that detracts from the customer experience as delivered across multiple channels—web, mobile, call-center. The winners go further, using these events as fuel for continuous improvement programs.

    This all requires some serious smarts, not at the least application analytics to monitor the customer experience in real time. Such advanced systems become the ultimate Andon Cord, since they treat every sub-optimal customer experience (e.g. functional issue, usage behavior, performance problem) as both a defect and opportunity for improvement. Through advanced analytics and integration this improvement could take many forms—such as immediately prescribing code improvements to developers, or support systems notifying customers when a poor experience is about to occur—maybe even (shock-horror) compensating them financially for any inconvenience.

    A strong DevOps culture thrives when individuals call out mistakes and inefficiencies. Fail in this respect and organizations risk paying a heavy price, such as broken customer trust and lost business. Seek out automated methods that help you metaphorically pull the cord and keep on pulling it. Only then can teams truly excel in driving real improvements that will help business gain and retain customers.

    — Peter Waterhouse

  • The 3 Secrets to Overcoming the Agility-Stability Paradox

    The 3 Secrets to Overcoming the Agility-Stability Paradox

    Regardless of whether an organization subscribes to a bimodal IT approach, one thing is clear: It’s more important, and more difficult, than ever to fight the agility-stability paradox. Today’s businesses must build on a delicate balance of being compliant, plan-driven and keeping the lights on while also seeking ways to become more fluid and agile with high customer touch. The barriers standing between these two key initiatives are numerous and complex; whether it’s mismatched technology or a lack of mutual understanding, the agility-stability paradox remains.

    In a lot of ways, this paradox comes down to a difference between traditional and new forms of IT. Traditional IT can be described as predictable–it’s compliant and plan-driven, with conventional processes and long-term cycles. But as the next generation of IT starts to take hold, today’s businesses must find ways to also fold in a new IT that’s dynamic, fluid, agile and continuous, with short cycles and high customer touchpoints. In this way, traditional IT and new IT are polar opposites, and many companies struggle to find a balance between the two. Competing attitudes, too much change at once and tooling challenges all stand in the way of harmony between the reliability of the traditional approach and the need for agility in the new way of doing things.

    Balance is Possible

    While there is no magic tool or wand that can solve for the incongruities so many organizations face, balance is possible. Enterprises don’t have to choose reliability, customer experience, uptime and performance over agility, release velocity, new markets and competitive response. The real secret to overcoming the agility/stability paradox lies in establishing who, what and how. What this means is that with the right people, processes and tools in place, any company can achieve the balance between agility and stability needed for success.

    Who? People

    People serve as the “who” of finding balance between reliability and agility. This is the chance to integrate your culture into solving the agility/stability paradox. Start by identifying how each member of the team needs to adapt and shift to accommodate changes. The real trick to getting the people aspect of things right is communication. Define a communication path and be really clear about why your organization needs to transform, how it will be transformed and when everyone can start expecting to see some real adjustments take shape. Orchestrate a response mechanism across your teams and enable social operations collaboration to facilitate execution. Be sure to provide ongoing updates and encourage feedback.

    What? Process

    Now that you’ve established who needs to play a role in overcoming the agility/stability paradox, it’s time to talk about what exactly needs to change. Process is absolutely crucial here. There are a few keys to establishing the right process for balancing traditional and new IT models. The first is to identify, and not dictate. Dictating change from the top down is never going to be effective. Instead, work together to determine areas of weakness and highlight them. Use your observations as a guide, not a mandate.

    From a more tactical perspective, be sure to streamline workflows wherever you can. Define instead of inheriting urgencies and alerts. Don’t be afraid to rely on automation wherever possible, either. By automating processes that help out on the people side of things, you can free up your team to spend less time on tedious, manual tasks and focus more on innovation.

    How? Tools

    Tools are your best friend when it comes down to actually making all this change happen. Considering the vast number of tools in the market, choosing a toolset may appear daunting at first. But if you start with strong integration across the operational modes already in place, then you’re already in good shape. In particular, to bring new, agile IT into the fold, you’ll want to incorporate IT service management (ITSM) solutions and establish a DevOps tool chain.

    Don’t Boil the Ocean

    The most important thing to remember is to start small—you don’t have to boil the ocean. Build a culture where traditional and new IT environments are encouraged to work closely together, where you can build and run software that addresses both agility and reliability to respond to the pressures on the business. Start by defining what is is right for your team and organization and acknowledge the existing culture and people. Don’t be afraid to experiment and create isolated learning environments, either. Just make sure to maintain a clear connection to customer value and use this as your North Star. Finally, don’t forget to celebrate. Celebrate your failures and learn quickly from them.

    About the Author / Manish Kalra

    manishManish Kalra is director of Product Marketing at PagerDuty. He is responsible for driving product marketing strategy, product positioning, launches and collateral development for the PagerDuty incident management platform. Prior to PagerDuty, he served as Director of Product Marketing at companies like Sumo Logic and Splunk.

  • Using MongoDB for a Product Catalog Application

    Using MongoDB for a Product Catalog Application

    In today’s era of data-driven business, enterprises are continuously adopting new technologies to gain a competitive advantage. Distributed and cloud databases is one such technology. These databases are fundamentally different from relational databases, offering scalability, availability and flexible data models that are beyond the capabilities of traditional relational databases.

    MongoDB is one of the leading next-generation scale-out databases. It is a document-oriented database that provides dynamic schemas, making the integration of data in certain types of applications easier and faster. MongoDB also provides easy scaling through auto-sharding, tunable consistency for reads and built-in replication.

    In this blog, I will describe an application, product catalog management, that distinctly benefits from features MongoDB offers.

    Most e-commerce enterprises need a product catalog with the ability to store varied types of objects with different sets of attributes. These kinds of data collections are quite compatible with MongoDB, which can offer dynamic queries on a constantly changing dataset.  However, it is important to understand the major requirements of industry verticals such as retail, media and entertainment, insurance, health care and e-commerce that are addressed by MongoDB before designing an optimal data model and for your own product catalog.

    For example, Ebay offers several use cases in which MongoDB has been implemented successfully and has delivered much value for its product catalog:

    • Product Availability – Being a JSON document store, not only can MongoDB help in complex querying of a product catalog in real time but it also can keep track of placed orders to accurately calculate the available quantity for popular products. The data is important from customer service point of view, as it keeps them aware of available choices at the time of order placement and prevents order cancellations later due to non fulfillment.
    • Dynamic Pricing – Product prices change quite frequently in the online world. E-commerce enterprises need to keep pace with these fluctuations and dynamically adjust product prices to retain their existing customer base. MongoDB helps tremendously through its ability to update data on live sites without shutting down/restarting any systems. On top of that, ability to run geospatial queries using geospatial index allows the sites to show converted pricing and taxes based on the location of their customers. The example below shows how to find all theatres within 10 miles of a location using a geospatial query.

    db.theatres.find({ location:
    { $geoWithin:
    { $centerSphere: [ [ <longitude> , <latitude> ], 10 / 3963.2 ] } } })

    • Shipping Estimation – Today’s customers enjoy the convenience of shopping online at home but also demand the flexibility to control the delivery of their products. Some customers will pay extra money for expedited delivery while others are content with waiting longer to pay no shipping costs. The ability to provide correct shipping costs and time estimates is a critical functionality for e-commerce applications. Again, MongoDB comes to rescue with its geospatial queries to calculate correct shipping estimates based on the locations of the user and the inventory.
    • Personalized experience – E-commerce enterprises want their customers to enjoy the online shopping experience by understanding their needs as well as their social profile. This allows them to provide every single user with a personalized version of the site, which can be based on their past order history and their interaction with the company via stores, customer service and social media. Not only that, e-commerce enterprises run applications that recommend new products based on customers’ indicated preferences. MongoDB is being used by online retailers such as Otto to consume data from multiple sources and build customized catalog experiences for individual e-commerce customers.
    • Sales/Discounts – To engage their customers at the next level, e-commerce enterprises have built capabilities to develop customized discount offerings. This can be done via “flash sales” that allow customers to buy their coveted products at lower prices within the constraints of quantity, time and minimum spend. MongoDB has been the with technology of choice here as well (for example GILT Groupe) because it can keep track of time-bound and volume-bound parameters in real time to make such deals successful.

    ecommerceIt can be argued that e-commerce industry and dynamic product catalogs have been in existence for a long time. So, how is MongoDB changing the landscape? The answer lies in the rapidly evolving landscape of customer buying patterns. Today, a wait of an extra minute often means losing customers and revenue to the next best online competitor. Always-on applications are a norm and scalable infrastructure is a must-have requirement. Hence, MongoDB is helping enterprises to meet their changing business needs.

    However, product catalog applications generally require consolidating data from disparate sources and present a uniform view to customers. This also makes the underlying database, MongoDB, prone to logical and human errors. Hence, a highly available data protection infrastructure that can guarantee minimal data loss (low recovery point objective and recovery time objective) is required to keep online retail engines running. Further, certain catalog portions could be updated more frequently such as perishable goods; hence, those databases need to be backed up every hour versus the slow-moving goods.

    The data protection system should provide enough flexibility to set backup policies per the business requirements (granularity, etc.).