Slalom Technology Magazine Cover 2 (Resized 6) · 2017-09-28 · Slalom Technology User Stories You re (probably) doing it wrong. Alexander Golden Scrum, and most agile methodologies,

SLALOMTECHNOLOGY

The 2.5%On Understanding Innovation

User StoriesYou’re (probably) doing it wrong.

Teaching Alexa to speak with a Boston accent

VOLUME 2 | SEPTEMBER 2017

2

Slalom Technology

WRITINGAlexander GoldenBruce CutlerIvan CamposJames AndersonJeff YeakleyKarl SchwirzRob Cavaliere

DESIGN & EDITORIAL STAFFIvan CamposJessica HopkinsKarl Schwirz

Find more content from Slalom Boston Application Developers

slalomtechboston.com

3

Volume 2

Copyright © 2017 by Slalom Consulting

All rights reserved. No part of this publication may be reproduced, distrib-uted, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses per-mitted by copyright law. For permission requests, write to the publisher, addressed “Attention: Permissions Coordinator,” at the address below.

Slalom ConsultingAttn: Slalom Tech Boston316 Stuart Street, Suite 300Boston, MA 02116617-316-5400slalomtechboston.com

Printed in the United States of America

AGILEUser Stories: You’re (probably) doing it wrong 10COMMUNICATION IN THE CLOUDTeaching Alexa to speak with a Boston accent 18Smarter team communication using ChatOps 22The Era of Voice: From keyboards to vocal cords 26INNOVATIONThe 2.5%: On Understanding Innovation 32DEVOPSTesting your Chef Code: It’s all about confidence 44Creating a Credible Candidate Experience 50ANALYTICSWhat is business intelligence? 56SECURITYStop Punishing Your Developers 62

CONT

ENTS

6

Slalom Technology

7

Volume 2

AWS CompetenciesWhether you need support migrating your legacy applications or transforming the way your teams work with DevOps, we can help — and we’ve got the AWS competencies to prove it.

Slalom Technology

AGILE

Volume 2

10

Slalom Technology

User StoriesYou’re (probably) doing it wrong.

Alexander Golden

Scrum, and most agile methodologies, are built on a fundamental construct: The user story, which specifies the smallest unit of development that provides value to the end user. Often expressed in the form “As a <<user>>, I want <<feature>, so that <<benefit to user>>”, the user story is a simple concept, but one that continues to confound even experienced agile practitioners.

The truth is that the ability to write great user stories — ones that are small, provide clear and distinct value to the end user, and can cleanly map to implementa-tion tasks for ease of estimation — is a skill that is developed and continually refined through practice. It helps to have a product with a clear vision of how it will benefit the user and an organizational structure that encourages agile best practices.

Do your user stories measure up? Put yourself to the test with the following checklist to see if you’re a user story all-star — or if you’ve been doing it wrong the whole time.

11

Volume 2

My user stories are always from the perspective of the end user

If your user story starts with “As a developer…”, or you’ve organized your teams by the type of code being produced (e.g., front/back end), you’re already off to a rocky start. User stories create value for the end user of the proposed functional-ity, period. “Stories” that do not meet these criteria include:

• “Stories” that refactor code but don’t actually produce any immediate benefit to the user

• “Stories” that produce code for other internal development teams, e.g., the creation of an API endpoint.

• “Stories” that are strictly research and do not actually involve producing functionality.

It’s tempting to write these types of stories: Sometimes the work to be done doesn’t fit neatly into a true user story, or the technical complexity is extremely high and the story may not be able to be completed in a single sprint. But resist the urge! You can usually address these in a more effective manner by creatively decomposing your story or performing any necessary refactoring incremen-tally over time.

For instance, instead of a story that says “As a user, I would like a quote on car insurance…” decom-pose it into several stories that segments your user base, e.g., ‘As a single driver with a single vehicle and no accident history, I would like a quote on car insurance…”. In extreme cases, reduce the scope of the story even further by identifying a single (po-tentially fictional) user: “As Sam Smith, a 42-year-

old living in Phoenix, AZ, with a 2007 Honda Civic EX, no accident history, and a bachelor’s degree…”. Getting creative in your user story decomposition allows you to maintain your focus on the end user without biting off more than the team can chew.

My user stories define the minimum amount of effort necessary to pro-vide value to the end user

I have yet to meet a (good) developer that has said “I prefer to do the absolute minimum necessary.” But, perhaps counterintuitively, this is exactly what you want with your user stories. If a story could be broken out into two or more stories which each provide independent value to the user, it should be split. By keeping individual stories small you can deliver value to your users faster and more reliably by ensuring that more code can be incrementally delivered at end-of-sprint.

As an example, think of a typical login screen for an application: It usually consists of a username field and a password field; there may be validation to ensure that the username and/or password follows certain patterns; there may be a checkbox allowing the user to stay logged in or save their username; there may be a way for the user to reset their password; there may be a way for the user to log in using another authentication method. It’s tempting to lump some or all of this functionality under a single user story, but keep it as granular as possible to prevent a situation where a release isn’t possible due to half-finished code.

12

Slalom Technology

Using the above example, keep the login field vali-dations separate from the login itself, since most users will type their e-mail address in the correct format anyway. Take this principle to the extreme by segmenting individual validations into separate stories, and prioritize them in order of likelihood to affect the user.

This example further demonstrates the need to have a clear understanding of the distinction between three key agile concepts: user stories, acceptance criteria, and development tasks.

A user story defines the minimum amount of effort necessary to create value for the user; acceptance criteria, by contrast, define the minimum condi-tions — from the perspective of the user— that must be met for the user to actually realize the value described in that user story. In other words, if ANY acceptance criterion fails, the user gets no value from the code developed. If this is not the case, and the user could get benefit from only a subset of the acceptance criteria being met, it is a sure sign that your story is too big and should be broken apart.

Development tasks, on the other hand, are just that: Tasks that need to be accomplished as part of the successful implementation of a given user story. Tasks, unlike user stories and acceptance criteria, are from the perspective of the developer, and do not provide independent value to the end user. The creation of an API endpoint is a classic example of a development task: An endpoint alone usually does not create value for the end user; only when combined with front-end code that allows the user to interact with the endpoint can the user actually benefit from the code created.

My user stories actually tell a story

I see a lot of user stories that go something like this: “As a user, I want to reset my password”.

Aside from the fact that the story is missing the why clause — which can help provide crucial context to the developer tasked with its implemen-tation — the story is so generic and bland that it’s almost certainly too broad. Does the software have multiple ways to login (e.g., username/password, OAuth, biometric, etc.)? Are there multiple reasons why a user might need a password reset (e.g., forgotten password, locked account, etc.)? Are there different types of users with different physi-cal capabilities (e.g., color-blindness)?

Without answers to any of these questions, the story can be widely interpreted. When this situation occurs, it’s not all that surprising that miscommunications occur and expectations are missed. Instead, improve your story by getting spe-cific about who your user is, what their particular situation is, and what they hope to achieve, both immediately and in the longer-term.

It’s easy to dismiss an exacting analysis of user stories as an exercise in arguing semantics. As long as the development team understands what needs to be done, after all, why should it matter if a user story follows “the rules”?

13

Volume 2

The answer, of course, is it’s a slippery slope down to user stories that are confusing, incomplete, and don’t actually provide value to the end user. What starts out as a little laziness in crafting user stories can quickly snowball into entire pieces of software that have to be shelved because they aren’t user-ready or fail to deliver the intended benefit.

Instead, lavish your user stories with the time and attention they deserve — and then revel in the great software that they will help create.

15

Volume 2

Slalom Building Community48in48 Hackathon

Jeff Yeakley

It’s 2:00 on a Sunday morning in early summer and a cross-functional Slalom team of design-ers, developers, and business analysts is hard at work putting the finishing touches on a new website to meet a hard deadline. Sounds like a familiar story to everyone used to the standard operating procedure of big consulting squeezing every drop out of consultants to meet unreasonable deadlines. That’s not how we do things at Slalom, however, and this was an entirely different story. You see, this was all part of the 48in48 hackathon where teams from local companies worked together with 48in48.org to design and build 48 websites for local non-profits in 48 hours. When one of our Slalom consultants brought this event to our attention, we broadcast the opportunity over our general interest slack channel and drove enough interest to field two full teams to donate their time, passion, and expertise to helping make our community that much stronger.

All told, 14 Slalom consultants worked together to create 4 full websites and significantly contribute to 5 other sites in the span of one weekend. This commitment to community, pas-sion for our work, and drive to build a better future are core to who we are and just some of the things that make Slalom such a great place to work.

Slalom Technology

COMMUNICATIONS IN THE CLOUD

Volume 2

18

Teaching Alexa to speak with a Boston accentIvan Campos

The Boston Accent

The Boston accent is more than just dropping the “R” sound ev-erywhere except before a vowel. It is the local accent of Eastern New England English. What bet-ter way to delight an entire user base than by speaking their lan-guage. To speak “Boston English”, we need a language for speech. Enter Speech Synthesis Markup Language — or SSML, for short.

A Language for Speech

SSML helps us generate speech from text. A Text-to-Speech (TTS) system, which supports SSML, solves for the creation of life-like speech. To generate natural sounding voices, SSML can control the following:

• Prosody: the rhythm (timing) and intonation (pitch) of speech

• Breaks: pauses in speech• Emphasis: adjusted rate and

volume of speech• Phonemes: phonetic pronuncia-

tions

19

Here’s some sample SSML markup:

A Pronunciation Alphabet

Another option to control the pronunciation of text is the Pronunciation Lexicon Specification (PLS). PLS aff ords us the ability to create a vocabulary of terms and their respective pronunciations. The pronunciations are spelled out using an alphabet. For our purposes, we will use the International Phonetic Alphabet (IPA).

Amazon Polly

To generate our synthetic Boston accent with SSML & PLS, we will utilize Amazon Polly. Polly is an Amazon Web Service (AWS) solution to convert text into life-like speech. Hosted in the AWS Cloud, Polly currently provides 47 voices in 24 languages.

Polly can:• Accurately process text (e.g. acronyms, ab-

breviations, numbers, measurements)• Infer context (i.e. words that are spelled the

same, but pronounced diff erently)• Produce highly intelligible, natural speech

The use cases of Polly vary from contact centers, educational materials, entertainment solutions, to the assistance of the blind.

PLS to Speech

Using the AWS SDK for JavaScript, we can output an MP3 file of some text using our PLS file (“boston”) and Polly. We then store the MP3 file (“harvard.mp3”) on a local file system.

20

Slalom Technology

SSML to Speech

Using the AWS SDK for JavaScript, we can output an MP3 file of some SSML using Polly. We then store the MP3 file (“blinkers.mp3”) in an AWS S3 bucket.

Lambda → Polly → S3

Upload the following GitHub project as a .zip file to AWS Lambda: https://github.com/IvanCampos/AmazonPolly*

*update creds.json to use your AWS credentials

When this code is triggered, it will upload a Polly generated speech file to an S3 bucket.

Alexa Skill → Lambda → S3

This S3 bucket’s MP3 file can then be read by AWS Lambda and output by an Amazon Echo with the following code:

21

Volume 2

To have Alexa trigger this code, visit the following site to wire up your Lambda Skill: https://devel-oper.amazon.com/edw/home.html#/skills

If this is your first Alexa Skill, the following docu-mentation should help get you going: https://de-veloper.amazon.com/public/solutions/alexa/alexa-skills-kit/overviews/steps-to-build-a-custom-skill

To test your skill inside a web browser, check out https://echosim.io

Bringing it all together

Now we can have some fun with our solution.

Feel free to mix and match everything we’ve learned so far to generate your own sentences for Alexa.

22

Smarter team communication with ChatOpsLeverage existing DevOps tools, and some new ones, to enable communication in a faster and enhanced fashion.

Karl Schwirz

Stop me if you’ve heard this before…

It ’s the middle of the weekend and you’re enjoying a little R&R when you’re unfortunately reminded that you’re on call for support by email notifications going off on your phone. An alert has gone out to the whole department with just a message indicating health checks for pro-duction systems have not passed and in all likelihood are offline.

You break away from your weekend activities, log onto your laptop, and start to investigate the issue. In the meantime, a slew of response emails are sent out and look something like this:

23

Emails, texts, and any number of status calls fly by and you find yourself switching between numer-ous tasks:

• Diagnosing and Fixing• Hunting down and waiting for the right

people to be available for their specialized task

• Generating reports and sending updates• Deploying fixes

… all for any number of people requesting they be done.

While you’re fixing, explaining, updating, and de-ploying you’re also losing precious seconds, min-utes and even hours trying to recover from what is amounting to be a costly outage. Think about this: for every time a person is forced to context switch in order to perform necessary collaboration with a team member they’ve cost [themselves] as much as 40 percent of [their] productive time.

There has to be a better way. Not just for recovery incidents, but for general collaboration. You’ve invested so much in your applications, tools, and

development practices (such as DevOps), why not take it one step further and integrate the power of automation into your team’s communication paradigm? When this is done properly, you can centralize your collaboration space, automation tools and processes to make them accessible to everyone on your team. Thus saving frustration,

time and cost. This practice is called ChatOps.

ChatOps?The goal of ChatOps is two fold — offer more transparency and receive faster feedback from our teams. We‘re provided a one stop shop for collaboration, issue resolution, process workflows, historical records and even training.

Volume 2

24

Slalom Technology

At the core of ChatOps, you have a collection of bots, or application that executes automated tasks, working symbiotically with a messaging platform to listen for events that occur either within an infrastructure or chat. The trick is doing so in an organized and beneficial way.

Looking back at that alert, instead of triggering a mass email to IT_ALL, that same trigger can be utilized in a different way. A bot subscribing to the event can turn around and notify the Prod Sup-port channel. Alerting only the people who have subscribed to the channel and need to worry about and address the issue. At the same time, generate a status report and (here’s what you won’t get in email blasts) a solicitation for action to recovery in that very same medium. Tasks like recycling application pools, increasing server capacity, or re-verting to previous working versions of your code base are common remedies for these situations and can be invoked immediately by typing simple commands or executing on their own.

For scenarios that require more investigation, teammates can then collaborate to fix the issue within the platform and not have to worry about updating a late joining member, annoying others with 50 email dings, receiving updates in real time, and most importantly fix the issue in as little time as possible.

The uses here are limitless. Let’s look at another scenario that’s less frantic than production re-covery — Every week your team is responsible for generating reports for the Business Analysis team. This involves: • Taking site metrics• Gathering user data• Running it through some graphics libraries

to display the information in a reader friendly way.

Each of these tasks alone are easy enough but take an hour each week to compile and process. Not a big deal, right?

25

Volume 2

to go. Even better, since you’re using tools within your cloud provider’s environment, you won’t have to worry about that additional layer of integration.

Where to get started with ChatOpsFirst and foremost, find a good collaborative chat application that supports team channels. When GitHub coined the phrase, they said ChatOps is about “[Putting] tools in the middle of the con-versation”. That conversation needs to take place where everyone on the team can access it easily. As I’ve said, getting out of emails is one of the big-gest benefits here as you leave behind that extra

noise, nuisance and broken communication.

Find your painFind those tasks that you have to execute over and over. and follow the same processes. Then, try to automate them so you can complete the work in a few keystrokes with a bot command. Don’t go for a moonshot with your first bot using AI libraries and massive infrastructure scripts, but rather pick a small task and automate it. DevOps processes are perfect candidates for this. Once you have those bots in place, build on them. You’ll find that functionality compounds quickly and before you know it you’ll have a network of self serving bots that are available to you and your team.

Well, it adds up. Over the course of a year you’ve clocked well over a work week’s worth of time just generating this same report over and over again. What is the solution? Write a bot to do this for you. Or better yet, enable the BA team to request these reports and discuss them among themselves via the chat channel.

So instead of people needing information and you being their bottleneck, they can now request the report on demand, several times a week if they’d like, and your team has one less context switch. That is the goal of ChatOps. Bringing teams infor-mation and collaboration in a smart and efficient way.

What does this bot system look like?In the past, there were and still are great solu-tions that provided ‘out of the box’ functionality to common use cases and have excellent communi-ties supporting them. However, in order to have a bot fleet you would need to host and maintain a bot framework like you would any other applica-tion. This means in addition to the bots you write yourself, hosting resources, installing updates, and maintaining another platform which only adds complexity to your systems when you’re trying to remove it.

This is why I’m a huge fan of Microservice frame-works like AWS Lambda and Azure Functions that allow us to quickly develop bot functionality while host it on a low-cost Serverless environment. In a follow-up article I’ll provide a deep dive on what this configuration would look like, but at a high level all you have to do is write the functionality your aiming for, integrate with your chat applica-tion via commands or Webhooks, and you’re good

“Put tools in the middle of the conversation”— Jesse Newland, GitHub

26

Slalom Technology

The Era of VoiceFrom Keyboards to Vocal Cords

Ivan Campos

By 2018, 30% of our interactions with technology will be through “conversations” with smart machines. Product leaders at technology and service providers need to invest now to improve currently limited voice interfaces.— Gartner

We used to call them dumb and neglect them in isolated rooms. We now call them smart and interact with them in our living rooms. This Cinderella story is no fairy tale. It’s the evolution towards the charmed existence of modern machines. The smarts are derived from artificial intelligence and powered by the cloud. While the interactions are diverging from

27

Volume 2

The era of voice is the result of a confluence of factors:• On average, humans can speak 150 words per

minute vs. type 40 words per minute.• Automatic speech recognition is approaching

a 95% accuracy rate. By comparison, humans miss ~5% of words in a conversation.

• The proliferation of devices with microphones and speakers paired with low-latency cloud computing.

• Digital assistants (e.g. Siri, Alexa) have re-placed robotic speech with life-like speech.

Voice is now a simpler, more conve-nient, and faster alternative to the keyboard.

Voice-First“Design for the ear not the eye — throw away what we know about design today and start fresh…We need to focus on how things sound, not how they look.”— Paul Cutsinger, Amazon Developer Evangelist

28

Slalom Technology

Devices designed for voice input/output are grow-ing at an exponential rate. From hearables (Apple AirPods) to smart speakers (Amazon Echo), voice-first hardware is everywhere.

Speech DesignAs we shift from graphical workstations to conver-sations, end user experience remains paramount.

But without screens, how can we delight through a voice user interface (VUI)?

Here are some speech design considerations:• Add breaks in the speech for dramatic

effect• Vary volume, rate, and pitch to generate

natural sounding speech• Personalize speech with regional dialect

pronunciation (Amazon Echo), voice-first hardware is everywhere.

Voice-Next“This year, 35.6 million Americans will use a voice-activated assistant device at least once a month.”— eMarketer

29

Volume 2

Currently, the Amazon Echo is primarily used for simple tasks, such as setting a timer/alarm, play-ing a song, and reading the news.

The initial Amazon Echo smart speaker operates most effectively in a hands-free or eyes-free envi-ronment; however, the next iterations of the Echo (Echo Show and Echo Look) will incorporate:

• A screen to visually display voice responses and enable video chat in the Echo Show

• A camera that will initially serve as a styling assistant in the Echo Look

• The ability to opt-in to Push notifications to proactively alert users will come to all Echo versions

Hollywood InfluenceSpeaking to a machine for assistance is nothing new. Hollywood has been indoctrinating us for decades.• Digital Assitants: “2001: A Space Odyssey”

(HAL 9000), “Her” (Samantha), “Marvel’s Avengers” (Jarvis)

• Mobile Machines: “Star Wars” (R2-D2, C-3PO), “Knight Rider” (KITT), “Short Circuit” (Johnny 5), “Wall-E”, “Avengers” (Ultron)

• Organic Hybrids: “Star Trek” (Data), “Blade Runner” (Replicants), “Prometheus” (David), “Marvel’s Avengers” (Vision), “Terminator”, “Ex Machina”, “I, Robot” (Sunny), Ghost in the Shell (Major)

In a world where humans and machines coexist, the line between natural speech and synthetic speech becomes blurred.

While this may prove a challenge for some, most will adopt and embrace our robot assistants. Digital natives will lead the charge.

Today’s children expect to swipe on screens and converse with machines.

Towards Ambient Computing“As speech-recognition accuracy goes from 95% to 99%, we’ll go from barely using it to using all the time!”— Andrew Ng, co-founder/chairman of Coursera and former chief scientist at Baidu

The evolution of human-computer interactions is just beginning. As technological innovations bring about exponential improvements, synthetic interactions will become indistinguishable from human counterparts.

Slalom Technology

Volume 2

INNOVATION

32

Slalom Technology

The 2.5% On Understanding Innovation

Ivan Campos

If I had asked people what they wanted, they would have said faster horses.— Henry Ford

Are technological innovations predict-able? Yes…only if you embrace non-linear thought.

In this post, we will prove that an expo-nential mindset is the key to unlocking

innovation.

Linear Projection FallacyAs individuals settle into routines…• Sleep cycles• Commuting to work• Step-by-step career progression…, we foster a linear mindset.

Linear thought is the great inhibi-tor to the adoption of innovation before it becomes mainstream.

As we will learn, technological prog-ress does not occur linearly, it does so exponentially.

33

Volume 2

The Laws of Martec, Moore, and KurzweilThe ability to underestimate this unintuitive rate of change is not isolated to individuals — it also ap-plies to organizations. This gap is best understood through Martec’s Law, which states:

Technology changes exponentially; orga-nizations change logarithmically.

Martec’s Law outlines the fundamental challenge that organizations face — to explore or exploit new technologies. When confronted with this multi-armed bandit problem, the goal is to maximize the ROI earned through a sequence of technology lever pulls. In short, incumbents must endorse rapid innovation adoption (and failure) to avoid being eaten by hungry upstarts.

A more common law that captures this phenom-enon is Moore’s Law. In 1965, Intel co-founder Gordon Moore observed that the number of transistors per square inch on integrated circuits double approximately every two years — or in other words, the growth is exponential.

A modern take on this premise is author of The Singularity is Near, Ray Kurzweil’s “Law of Acceler-ating Returns”. It states:

…fundamental measures of information technology follow predictable and expo-nential trajectories, belying the conven-tional wisdom that you can’t predict the future.

These three laws have identified how technology takes shape over time. Our shape grows slowly, explodes sharply, and then slows again due to ubiquitous market penetration.

The Arc of Innovation Bends Exponen-tially

In mathematical terms, this “S” shaped curve resembles a sigmoid curve — or S-Curve, for short.

34

Slalom Technology

The S-CurveThe S-Curve is what separates the Segway from the iPhone. Over time, new tech faces an inflection point where its adoption matures or fades away. If we are experiencing the next big thing, a hockey stick moment will occur; else, the tech will be relegated to obsolescence.

The journey from novelty to commodity is fraught with uncertainty.

To achieve mass market adoption, innovations must go through an innovation adoption lifecycle.

Diff usion of Innovations TheoryTo explain why, how, and the rate at which technol-ogy spreads, the diff usion of innovations theory categorizes adopters into the following buckets:

• Innovators (2.5%)• Early Adopters (13.5%)• Early Majority (34%)• Late Majority (34%)• Laggards (16%)

When we plot this adoption theory over time, we receive a familiar shape — the S-Curve.

The intersection of the S-Curve and Diff usion of Innovations Theory depicts the point at which inflection points occur and when fads mature into utilities.

35

Volume 2

A major hurdle to mass adoption is what Geof-frey A. Moore coined as “the chasm”. Crossing the chasm is the only way to achieve your hockey stick moment.

Continuous DisruptionAs one technology crosses the chasm, competi-tors to its business model are not far behind in the innovation adoption lifecycle.

The incumbent’s S-Curve will inevitably be over-taken by an upstart’s S-Curve. A recent example of this is when the S-Curves of Blockbuster video and Netflix collided.

…and we all know how this story ended…

On a long enough time line, the adop-tion rate for every technology drops to zero.

36

Slalom Technology

The lesson to be learned is that S-Curves serve as the foundation for all human progress. As technol-ogy matures, we all benefit at an increasingly accelerated rate.

Digital DarwinismTechnology experiences waves of evolution. Cur-rently, the tsunami overtaking information technol-ogy is Cloud Computing.

As we review technologies over the past century, the S-Curves come into focus…

…and the velocity of S-Curve adoption rates is faster and more frequent over time.

This gift to human progress is a curse to organi-zations who attempt to keep pace with this rapid change.

What it Takes to be Part of the 2.5%Thankfully, there are several research and advisory firms that have developed graphical methodologies to help organizations separate technological hype from reality.

37

Volume 2

• Gartner Hype Cycle• Forrester Wave• Gartner Magic Quadrant• ThoughtWorks Radar

As organizations perform due diligence on their technology adoption decisions, these advisory models serve as great references.

The only caveat here is that advisory methodolo-gies are purposefully generic to be applicable to as many potential businesses as possible.

Fusing your specific business needs with innova-tive progress must be done so with exponential change in mind. With this knowledge, what actions can organizations take to avoid becoming the next Blockbuster video?

Market CannibalizationOne solution is to self-disrupt.

Apple has remained innovative by disrupting its own products. Apple thinks differently…and exponentially.

Market cannibalization is why Apple has been able to successfully transition through the Personal Computer (PC) and Mobile S-Curves. Is Augmented Reality (AR) next?

Time PerceptionKeep an open radar screen. Avoid the tempta-tion to perceive innovations as being 50–100 years away.

Project the Next Logical S-CurveNow that we understand the hazards of linear projection, we should break free and predict based on exponential change.

For instance, when it comes to computation, the field of study closest to its inflection point is Artificial Intelligence (AI).

More specifically, a breakout looks to be hap-pening in Deep Learning (DL). DL is a subset of Machine Learning (ML), which itself is a subset of AI.

38

Slalom Technology

Since we are projecting exponential change, a valuable exercise is take the next S-Curve and project its disruptor. In the case of machine intelligence, it’s merging the human brain with computers.

…and it should come as no surprise that the foremost innovator of this decade, Elon Musk, is already playing the innovator role in this space.

39

Volume 2

Slalom Technology

DEVOPS

Volume 2

42

Bruce Cutler

Before introducing any piece of code into a live environment, I’m sure we can all agree on the im-portance of testing it thoroughly to ensure it behaves as expected. By subjecting newly developed code to various types of testing, we can push it to any instance with a high degree of confidence. It seems simple — who wouldn’t want to be confident in their deployments?

Chef cookbooks are often treated differ-ently when it comes to testing, but this doesn’t have to be the case. The recipes, libraries, attribute files and other con-

Testing your Chef Code It’s all about confidence

figurations you create should be handled just like any other piece of application code. Chef offers a number of tools within its Development Kit (ChefDK) that make it possible to develop a thorough and consistent testing strategy for your cookbooks. Using a combination of these tools, there’s no reason why your Chef cookbooks can’t be subjected to the same level of rigorous testing that you apply to other parts of your application.

The goal of the following sections is to provide more of the “what” and less of the “how” with regard to implementing an effective Chef testing strategy. I’ll be introducing you to three key types of testing that can and should be included as part of your Chef testing strategy. As I do so, I’ll discuss their respective benefits along with a number of do’s, dont’s and pitfalls.

43

Finally, I’ll discuss how automation can be used to increase adoption of these testing best practices within your organization.

Lint TestingIn a nutshell, lint testing is used to check your Chef cookbook for correct structure and syntax. Lint testing is an important first step in Chef development as it ensures you are writing clean, efficient code following both Ruby and Chef best practices.

Within the Chef community, the two most commonly employed tools for performing lint testing are Rubocop and Foodcritic. Based on the community driven Ruby Style Guide, Rubocop is a command-line tool that performs static code analysis of all files within your cookbook, including attribute files, recipes, library helpers and custom resources. In a similar vein, Foodcritic is a command-line tool that will identify Chef specific syntax/structural problems within your cookbook. Both

Rubocop and Foodcritic are included as part of the Chef Development Kit (ChefDK) and are executed using simple commands, so getting started is easy.

Ensuring that your cookbook passes both Rubocop and Foodcritic testing is just the first step towards a robust testing strategy, but provides you with a consistent foundation upon which to test the functionality of your code.

Unit TestingUnit testing is a well known concept within the software testing space, designed to quickly validate the behavior and performance of individual compo-nents (units) of your source code. As an example of how this can be applied to Chef, you might want to validate that the correct version of a specific package was installed for each operating system that your recipe supports.

44

Slalom Technology

ChefSpec is a framework provided as part of the ChefDK to help create and execute unit tests for your cookbooks. An extension of RSpec, a behavior driven development (BDD) framework for Ruby, ChefSpec allows you to quickly test resources and recipes as part of a simulated chef-client run.

There’s a common misconception about the purpose of unit testing with ChefSpec. Consider the following Chef recipe to install the apache web server package (see: right)

... and a ChefSpec unit test for that recipe (see: below)

45

Volume 2

Examining the ChefSpec test above, this may seem like it’s designed to validate that the package was installed correctly. However, what it’s really testing is “Did I tell Chef to install the package?”, rather than “Did Chef install the package?”. The key point to realize here is that the simulated chef-client run executed by ChefSpec would have failed if Chef had not been able to successfully install the speci-fied package. Like any piece of well developed software, Chef has been thoroughly tested to en-sure that it functions exactly as we would expect.

So if the goal isn’t to test the functionality of the underlying Chef resources, you’re probably won-dering why we should unit test at all. The answer: regressions.

To be precise, the true value in Chef unit testing is to protect against mistakes (think typo’s or accidental deletions) in your code that could be difficult to detect otherwise. Misspelling a file path, creating a user with an incorrect name or acciden-tally removing a line from your recipe are just a few realistic examples. All three of these scenarios might still result in a successful execution of chef-client, but will leave your instance in an undesired state. In such cases, a detailed and accurate unit test will help you to detect these hidden errors before they get anywhere near to production. To summarize, the main benefit of unit testing is the protection that it offers you from the most common source of errors, yourself.

Integration TestingWhile unit testing is designed to test individual components, integration testing builds upon this to test these units collectively as a group. Within the Chef domain, integration testing allows you to run

chef-client with a specific runlist of cookbooks and recipes on a target operating system version.

Integration testing in the Chef domain is performed using Test Kitchen, a tool also included as part of the ChefDK. To use Test Kitchen, you create a YAML configuration file which outlines properties such as operating systems to test against, runlists and cookbook attributes. When executed by Test Kitchen, this configuration file generates on-demand test instances running the specified OS versions. Once available for use, these instances are automatically converged with chef-client using the runlists and attributes specified within your YAML config file.

Test Kitchen employs a driver plugin architecture, making it easy to test your configured code on instances created in a variety of popular cloud providers or virtualization technologies such as Amazon AWS, Microsoft Azure, Vagrant and Docker.

Even if you’ve put together a solid suite of lint and unit tests, I cannot overstate the importance of investing time to configure integration tests for your cookbooks.

Being able to examine how your cookbooks work together to converge a real instance hosted by your chosen cloud or virtualization provider is extremely beneficial. As a developer, successful integration tests allow you to feel confident that your proposed changes will execute successfully when introduced in a real environment.

46

Slalom Technology

Consolidate and AutomateHaving covered lint, unit and integration testing, some of you may be thinking that executing each of these tests one by one could become a burden. However, employing tools to help you automate will make things a whole lot easier.

Instead of running each test individually, utilizing tools such as Rake or Thor will simplify the execu-tion of a testing suite. Generating a Rakefile or Thorfile respectively will allow you to run lint, unit and integration tests as a series of consecutive steps from a single command. The obvious benefit of simplified execution will in turn help to drive adoption among team members.

Configuring your testing suite for a particular cookbook to run as a job within your chosen build system software (Jenkins, TeamCity, TFS etc.) is also highly recommended. These tools work closely with your chosen source control system and can be used to help automate the execution of Chef tests. For example, you could set up a trigger to automatically execute a testing job whenever a pull request is opened for a specific repository in GitHub. To ensure that proposed changes have been tested thoroughly, you could also enforce a condition which does not allow a pull request to be merged until all tests within it’s associated job have passed successfully.

Putting It All TogetherWe’ve covered three distinct types of testing that can and should be applied when performing any kind of Chef development. The initial time invest-ment required to write and configure tests for your cookbook is far outweighed by the long term benefits of consistent code structure and known functionality. As detailed in the previous section, using tools to help you consolidate and automate the execution of these tests will greatly reduce the effort required to execute them. In the end it’s all about confidence: implementing lint, unit and in-tegration tests as part of a testing suite will propel you and your organization towards predictable and consistently successful deployments.

47

Volume 2

49

Volume 2

QCon New York 2017 Recapivan Campos

After digesting the QCon New York experience, I distilled the takeaways into three themes — ephemeral, chaotic, and secure.

The rise of serverless architectures, microservices, containers, and cloud computing was at the heart of the following sessions:• Google’s Matt Sakaguchi kicked off the

conference with the most powerful keynote I’ve ever attended in over 15 years. The main messages were simple, yet powerful: Make differences in people’s lives and live life to the fullest. While the presentation made it clear that life is more important than work, it also posited that you can make an impact at work by improving the effectiveness of teams. Backed by empirical data, Google identified that the foundation of team effectiveness is psychological safety. This wasn’t the only reference to safety and security. Prior to working at Google, Sakaguchi served as a SWAT team member before severe back issues forced his career as a police officer to be short-lived. This wasn’t the only reference to ephemerality. Sakaguchi also revealed that he will not have a full life span as he’s currently battling Stage 4 cancer. Thus, his message bears repeating, make differences in people’s lives and live life to the fullest.

• NETFLIX, known for their Chaos Monkey tool,

provided insight into Chaos Engineering. As defined by principles of chaos, “Chaos Engineering is the discipline of experiment-ing on a distributed system in order to build confidence in the system’s capability to with-stand turbulent conditions in production.” The main takeaway from chaos engineering is that the strategy doesn’t cause problems, it reveals them.

• Coinbase has a 30 day plan which stipu-lates that no server should live longer than 30 days. Their median fleet age is ~9 days. This means that each and every AWS VM is rebuilt within a month’s time. By rebuilding their entire fleet of servers so often, they are ensuring that their servers are patched frequently to mitigate exposure to published vulnerabilities. Having servers updated and reconfigured via rebuilds is all part of an even larger plan to codify and automate everything. Over the past 12 months, they have launched nearly 150k servers.

• Hillary for America went into the chaotic scenario caused by what they named, the Frankenbump. When Senator Al Franken unexpectedly flooded the HFA site with traffic (148k requests per minute), their architecture remained resilient. The campaign’s website consisted of 150 serverless front-ends and 100 immutable backends. HFA also discussed some security tactics employed against script kiddies and DDoS attempts.

50

Slalom Technology

51

Volume 2

DevOps: Creating a Credible Candidate ExperienceRob Cavaliere

DevOps practices are less de-fined than most, and has an ever-evolving eco-system that both recruiters and technologists need to keep up with. For this reason, I quickly learned that my messag-ing needed to move beyond the buzzwords or else my message would be pushed aside.

Since joining Slalom, I realized that by defining DevOps, I could better tailor my messaging towards the candidates I am interested in speaking with, and have a better chance of having a meaningful conversation with them. Due in part to the evolving landscape, and ecosystem, it is fair to say that no community has held my attention or interest quite like the DevOps community has.

DevOps Defined-Context for the RecruiterThe definition of DevOps is evolving, but from a talent acquisition perspective, understanding the basics as it pertains to business operations is crucial to creating a better candidate experience.First, there must be a focus on the cultural aspect of DevOps, and recognize the adoption of a DevOps methodology. Without buying into the cultural shift, an organization will never be successful. DevOps is a term that points to the practices that promote collaboration across development and IT operations groups within an organization. The goal is to communicate actively to get things done more efficiently, while simultaneously breaking down silos (development, quality assurance, and infrastructure). This is accomplished by automat-ing software delivery and infrastructure operations and leveraging many of the tools and buzzwords that most recruiters tend to get caught up hunt-ing for in resumes and LinkedIn profiles. If you understand the purpose behind “why DevOps?” and look beyond the buzzwords, you will only add depth to your conversation with an experienced DevOps candidate. I discovered that it is key to form a definition of what DevOps is as it pertains to the specific organization(s) I support, and then use that definition to create a foundation for my messaging.

52

Slalom Technology

Feel Empowered to Make the CallCandidates often dread calls with a recruiter and in many instances this is a deserved stereotype. That said, there are also times when recruiters may be hesitant to take a phone call or a meeting with a potential candidate. Whether the candidate does not look like the perfect fit for a role on paper, or perhaps does not have enough years of experience under his or her belt. In many situations, those reasons would be adequate disqualifiers, but in DevOps recruiting I have learned to always take the call.

With demand so high and the candidate pool so small, excuses should be limited to avoid letting good candidates slip through the cracks. By no means am I looking to waste a candidate’s time, nor mine, but for fringe candidates it never hurts to pick up the phone and make the 5–10-minute call. Fringe candidates are individuals who don’t have a traditional background, or you are on the fence about engaging with.

It is paramount to cultivate a relation-ship with a candidate, that is built on all the components above to ensure the candidate walks away from that initial discussion wanting more.

With so many different DevOps tools, methodolo-gies, and various industry backgrounds, the reality is you will be hard-pressed to find that perfect candidate. This is where passive recruiting comes in to play. Don’t just recruit with present needs in mind. Worst case scenario, it is a learning experi-ence for both parties involved, and could pay off in

Establishing Credibility Through MessagingToo often, a recruiter sends the initial message to a candidate and fails to establish credibility. I have learned it is paramount to customize that first impression as much as possible to come across as sincere and relevant.

The candidate wants to know what they are building, why it is important to the company, and ultimately, what impact the solution or product is going to have.

Regardless of the organization I am supporting, it always serves me well to learn as much about the role so that I can explain the environment and the type of work at a high level to the candidate- often this is what the candidate truly cares about. Candi-dates are less concerned about Chef vs. Puppet, or that the client is using Docker, because those tech-nologies, or comparable ones, are being used in most DevOps environments. The candidate wants to know what they are building, why it is important to the company, and ultimately, what impact the solution or product is going to have. Make sure this is apparent in the messaging. Using project examples in messaging is a great way to show that recruiting is less about matching buzzwords, and more about connecting with the candidates’ interest in impactful DevOps projects. Successful messaging will help a recruiter establish credibility leading into a candidate call, and have an insight-ful conversation with a DevOps candidate.

53

Volume 2

the future when that candidate comes back around with more relevant skills.

It is paramount to cultivate a relationship with a candidate, that is built on all the components I’ve discussed to ensure the candidate walks away from that initial discussion wanting more. Gone are the days when people stay at one company for the duration of their career, and if you are willing to pick up the phone and make the call, it could create a positive candidate experience that a candidate will remember years in the future.

Slalom Technology

ANALYTICS

Volume 2

56

Slalom Technology

James Anderson

Business intelligence has multiple interpretations between individuals and even within orga-nizations. Some believe it is tied to the visual aspect, some the analytical, while others are just trying to access their data. As an analytics consultant, it ’s one of the toughest questions to answer with any concise statement. The true answer to the question is less about the technology, and more about the final objective: How can an organization trans-form itself and begin to make more data-driven decisions?

What is ?Definitions and SolutionsTrusty Wikipedia defines Business Intelli-gence as “ the set of strategies, process-es, applications, data, technologies and technical architectures which are used to support the collection, data analysis, presentation and dissemination of busi-ness information.” What exactly does that mean? To a UX designer, it might be more about how to create beautiful and informative dashboards.To a DBA it might be more about the normalization (or de-normalization) of a data model. They would both be right. Ultimately, this is a very vague way of saying that Business Intelligence is not just a reporting tool or platform, but rather a business strategy to enable an organization to act and make decisions in a more proactive way.

The most common issue that we hear about when it comes to reporting and

57

Volume 2

analyzing data is the number of disparate sources that data is pulled from. Sometimes data lives in a single database, sometimes in manual labor intensive Excel files, sometimes a more EDW-type platform — which leads to many different answers to the same question depending on logic and source. There is nothing worse than walking into a meeting with numbers that you think are correct only to have someone else have different answers to the same question. So, how do you deal with this problem?

Front-End vs. Back-EndThere is an argument that says database archi-tecture is as much an art as dashboard design. A single bad join between two key tables and an entire system can lock up. Too many columns in one table can make it borderline unusable in the future. While I am open to this argument, I would state that they are different types of art. What is more important to understand is the harmony be-tween these two aspects of business intelligence as a whole. Without a good database architecture underneath, no matter how attractive a dashboard is, it will not be effective. The same can be said for the inverse for dashboard design — the best grapes in the world can still make a terrible bottle of wine.

While single organizations sit differently along the maturity curve of data reporting, a great deal can be done on both the front and back end. Many times, an organization has put a lot of energy into one side or the other. For example, an organiza-tion might have one of the best data warehouses in the business, but it is locked down by the IT organization and all reporting comes from flat data files sent out by IT and analyzed in Excel. Another organization might have some of the best visuals

and dashboards but still have a fairly segmented data model. The best case scenario is an orga-nization operating a model with IT opening the data to analytics teams, who are empowered to create strong visual dashboards with business user support. But, in order to get there, you have to look at how the business functions as a whole.

The most important step in implementing BI in an org is not only to evaluate the current architecture, but how individuals interact with data. As a UX designer might survey people to see how they like to see and interact with the dashboards, a DBA might survey people on what metrics mean most to them, and what types of decisions are they making with the data. All this information will help a Business Intelligence architect make the best possible decisions on what type of platform is needed for an organiza-tion.

Plug-and-Play vs. VisualizationThe next step in a Business Intelligence journey is understanding more about what type of plat-form fits best within a particular organization. Obviously, every organization will have different needs when it comes to Business Intelligence. Some are very data driven organizations and are really just looking for help bringing the entire platform together with a strong visualization tool. Some have no idea what to do when it comes to their data, but are working on a shoestring budget. Then there are the big companies, always looking to innovate and put themselves in a position for success, no matter the cost. And there are different strategies and platforms for each type of need.

58

Slalom Technology

Some tools market themselves as a one stop shop for all things Business Intelligence, such as Birst or Qlik. From data warehousing to data modeling and visualization, these platforms can (theoretically) cover all the bases needed for a strong Business Intelligence strategy (also known as “Plug-and-Play). In truth, these platforms are developed to be very sticky within an organization, and can be in-flexible if you try to develop outside of the platform. For a smaller company, this might be a good thing, because it allows them to streamline their data organization and focus on building their business. It also could fit at an enterprise who have different data sources for different arms of the company, and the platform is used as a data consolidation tool for more executive level reporting.

Other tools, like Tableau, Microstrategy, or PowerBI, require a data architecture to be built around the tool, but truly excel at dashboarding and visualiza-tion. However, if your organization already has a very strong data strategy, but just needs the capability to build some truly engaging dash-boards, these tools fit perfectly. This type of tool enables analysts to pull away from simple Excel pivot tables and vlookups and truly engage in data discovery.

What does this mean for my organization?

So, what is the point of this whole blog? How can you take this and apply it to your organization?

Business Intelligence, ultimately, is not a series of tools and dashboards that hopefully mean something to someone somewhere. Rather, it’s

a platform, and ultimately, a strategy. One that can enable an organization to move from making reactive decisions based on some descriptive story they are told, to making proactive decisions based on data-driven analytics. Decisions that enable a decision maker to feel confident in the results they are seeing. This strategy is unique to every single organization, and must be decided upon not by coming up with requirements and comparing tools against what they can do, but instead looking at the organization itself, and committing to making a (potentially fundamental) change in how business users interact with data. Because Business Intel-ligence isn’t solely defined by the IT organization, or even the analysts who supply the information. The strategy is defined in large part by the end users and how they interact with data every single day. Without their adoption, and ultimately, their approval, you cannot have a successful Business Intelligence strategy. The dissemination of informa-tion stops with the last adopter.

59

Volume 2

Slalom Technology

SECURITY

Volume 2

62

Slalom Technology

Stop punishing your developersThe arguments for an inter-nally managed and secured development pipelineIT and risk managers everywhere will be quick to point out that development environment complexity is sometimes in place for important reasons, not least of which is software security.

After all, we’re not just talking about meaningless 1’s and 0’s: The software be-ing created may be intellectual property that makes or breaks the company. For software-intensive companies, a source code leakage to competitors or hackers could destroy the company’s competi-tive advantage and ultimately doom it to failure. Similarly, inadvertent or mali-cious injection of code could expose the company to catastrophic liability or a loss of consumer confidence.

Having an internally managed and secured development pipeline, propo-nents argue, is the only way to counter these risks. Doing so relies on two basic tenets: First, all parts of the development pipeline should be secured on company-managed and -secured environments; second, software should be developed on company machines that securely connect

Alexander Golden

Go to any medium-to-large size company and you’ll likely see the same story: A complex web of networks, VPNs, environments, access credentials, and domains. Each of these represent an addi-tional hurdle for developers looking to create soft-ware for the company: Access must be granted, credentials issued, environments made accessible, and firewall ports opened before the developer will have the resources he or she needs to succeed. The whole process may take weeks before a single line of code can be written. Now ask yourself: Does it have to be this way? Let’s take a look at a common enterprise scenario to understand why this situation might occur — and whether or not the insanity is truly warranted..

63

Volume 2

A case study in developer frustrationThe problem, of course, is that the benefits of “secure” software development come with a price. Let’s take a fictitious e-commerce company (let’s call it Acme Online) to demonstrate the ways in which a strict development pipeline can end up punishing developers and the company at large.

At Acme Online, they’re looking to create a cutting-edge redesign of their online shopping experience. They’ve hired a crack team of well-paid contract developers to get started on this ambitious project. Team members are scouring the backlog and preparing to start development on this exciting project. Unfortunately, the roadblocks to the team start popping up fast and furiously:• Acme corporate security mandates that only

company-secured computers can access the network, and so the developers’ shiny latest-generation MacBooks are shelved in favor of company-issued laptops. As contractors, these developers get the leftover previous-generation laptops that are large and slow, limiting their productivity.

• Part of the team is overseas, so some of the Acme-issued laptops will be shipped. Half of the team loses a sprint when the laptops are unexpectedly caught up in customs.

• The VPN is old and slow, and the connec-tion sometimes drops during times of peak volume. Overseas developers, who rely exclusively on the VPN, are at its mercy.

• The developers are not given administrative access on their computers, so software tools that the team is accustomed to using must

go through a lengthy security review and approval process. Some tools (e.g., Slack) are ultimately rejected entirely because they are hosted outside the Acme company firewall, and the team is forced to find alternatives.

• Setting up the team’s development envi-ronment involves submitting a ticket to a centralized queue. The service level agree-ment specifies 3–5 days before the request is addressed, and the team will spend several more days in back-and-forth discussions with the systems engineer who didn’t quite understand the original request.

• Integrations with 3rd party tools (e.g., remote testing services) require opening ports in the firewall, another submit-ticket-and-wait proposition.

• Integrations with 3rd party tools (e.g., remote testing services) require opening ports in the firewall, another submit-ticket-and-wait proposition.

• The internally managed Acme pipeline doesn’t yet support the latest version of Node.js, which is needed to support some cutting-edge libraries that will allow for a better customer experience. Instead, the user experience is watered down to accommodate the limitation.

64

Slalom Technology

Just weeks into the project, the scope has already been cut, the developers are struggling without the tools they need to succeed, the development environment still isn’t fully configured, and the pro-jected cost and duration of the project is exceed-ing original estimates. It probably isn’t surprising, then, that the morale of the development team is low.

Was it worth it?On the plus side, none of the (somewhat crippled) source code created by the developers could leak into the wrong hands… until it is deployed to Production, that is. The front-end source code cre-ated by this team consists of HTML and JavaScript libraries that are minimally compiled and can be easily downloaded, read and appropriated by the company’s competitors.

Meanwhile, like all good developers, the team sought to speed development and lower costs by leveraging several free, 3rd-party-developed user interface components and software development kits. While the use of these libraries helped keep the project on-track, it exposed the company to the potential for malicious code injection, a risk that the company’s “secure” pipeline could not effectively address on its own.

The end result is that, despite the burdensome pro-cess foisted upon the development team, Acme’s security measures failed to provide the intended security benefits.

Protect what mattersThe lesson is clear: Security matters, but only when you secure the “right” things. In the case of

Acme Online, their real competitive value comes not from their front-end user interface code, but from the back-end services code that codifies their business processes for pricing, inventory, product recommendations, and sales.

In this particular case, the contractors don’t actually need access to this highly proprietary back-end source code to achieve their objectives. What they do need, however, is access to secure, well-documented, and highly accessible develop-ment web services. This requirement could have been satisfied with far less onerous security:• A publicly-facing set of web services that

is accessible outside the company firewall, allowing development from anywhere

• SSL certificate authentication, ensuring that those services are accessible to only company-approved developers

• IP whitelisting, to minimize the chances of a denial-of-service attack from unauthorized computers

• API rate limiting, to ensure that no one de-veloper (or malicious actor that has obtained a developer’s credentials) can attempt to reverse-engineer back-end algorithms by issuing thousands of API requests.

Finally, a clear company policy on the use of 3rd-party components, rigorous validation of the completed code, and appropriate safeguards for Acme’s IT and API infrastructure could be effective at combating the risks of malicious front-end code injection without impeding the progress of the development team.

65

Volume 2

With these security measures in place, the devel-opers could have set up their own development pipeline, used the tools that they are comfortable using, and developed software anywhere and anytime they had an Internet connection.

This approach would also have significant security benefits by implementing the principle of least privilege: Developers would have access to only those resources necessary to complete their work, with no broader access to internal company systems or networks. The use of external-facing APIs in this manner replaces the outmoded and ul-timately ineffective concept of a “company firewall” that does little more than divide network traffic into internal (‘good’) and external (‘bad’) sources.

When red tape is a good thingThe example above is no doubt a simplification of software development: Not all projects produce relatively non-proprietary front-end web code. When, then, is a highly-secured development pipeline, and the regulated and lengthy processes that come with them, a necessary evil? Situations that may meet these criteria include those where the code to be developed:• Contains highly proprietary algorithms — Code

that codifies an insurer’s rating algorithm or an investment bank’s investing strategy may call for a tightly controlled development pipeline. In these cases, the algorithm itself is a major source of the company’s business value.

• Must be strictly traceable— HIPAA-compliant software, among others, must undergo rigor-ous validation that maps directly to system specifications. A single, highly-secure, fully

traceable development pipeline may be nec-essary when the development process must comply with certain laws and regulations.

• Exposes the company to significant risk — Certain types of software — such as that responsible for managing financial transactions— can have real-world impacts that expose a company to significant liability risk. Managing and effectively delegating accountability for this risk is especially necessary when the risk is high, contractors are involved, and the software to be devel-oped lacks clear boundaries of ownership. A highly-regulated development pipeline can help a company effectively assess, manage, and mitigate this risk.

Development ops is not one-size-fits-allThe lesson to be learned is that no single devel-opment pipeline is right in every situation. For mission-critical software that requires the highest levels of security, processes and rules that incon-venience developers may be absolutely necessary. For some software, though, a more hands-off approach that gives the team greater flexibility is warranted.

Only by truly understanding a company’s com-petitive advantage and risk profile — and by being willing to tailor development processes based on the particular software being created — can an organization achieve the most effective balance between security and flexibility.

66

67

Volume 2

Slalom OverviewSlalom designs and builds strategies and systems to help our clients solve some of their most complex and interesting business challenges. Every individu-al who joins us becomes part of our fabric, weaving their talents and perspective into the greater whole of who we are.

Visit slalom.com to learn more.

Each day Slalom helps 1,000 of the world’s most influential orga-nizations bring their strategies to life. We craft custom solutions that help those we serve fulfill their purpose and vision. The real measure of our success is the actual realization of theirs.

What’s our key diff erentiator? We pair competencies with an overarching focus on getting things done. We combine the intimacy of a local boutique partner, the industry and domain savvy of a strategic think-tank, the creativity of a digital agency, the technical acumen of a software developer and the insights of data analytics.

Why Slalom?We’re a purpose-driven consult-ing firm that helps companies solve business problems and build for the future. We’ll help you find your why, we’ll help you embrace change, and we’ll part-ner with you to design and build the solution that’s right for you.

ServicesCustomer Engagement

Delivery Leadership

Experience Design

Information Management & Analytics

Organizational Eff ectiveness

Strategy and Operations

Technology Enablement

69

Volume 2

Slalom Partners

70

Slalom Technology

SLALOMTECHNOLOGY

The 2.5%On Understanding Innovation

User StoriesYou’re (probably) doing it wrong.

Teaching Alexa to speak with a Boston accent

VOLUME 2 | SEPTEMBER 2017