devopsy.kinsta.cloud

Tag: Agility

  • In Product Development, Transparency is the New Agility

    In Product Development, Transparency is the New Agility

    The rise of DevOps has shown that agility and speed are key drivers for turning a business into a high-growth company. But as product managers, that’s not all we can take away from the DevOps culture. Those same methodologies that enable DevOps to function, such as having cross-functional teams and embracing a culture that embraces transparency, can also help product teams adopt experimentation.

    The product cycle should be an ongoing opportunity to try new ideas, gather data, make changes and celebrate failure. Teams with an experimentation mindset are better-suited to accept these goals, knowing that they lead to learning and succeeding quickly. Yet, experimentation and developing innovative products will succeed only when there’s a foundation of transparency—and not just about financial data and company successes, though that certainly helps. Everyone on the team needs the freedom, insight and tooling to make big bets, as well as the accountability to see them through.

    This is where DevOps comes in. Leaders at the C-suite and VP level need to apply DevOps systems to product development to stay agile. Here are three ways to do so:

    Make Development a Collaborative Process

    DevOps brings IT and engineers together to meet customer and business needs. Product development teams should adopt a similar cross-functional team culture to remove silos. When product managers, sales managers, success managers and developers have regular and open conversations about industry trends, customer requests and big successes, they’ll have more insights in the customer experience and product road map that can help each team be more effective. For example, sales managers interact with customers daily and bring a broad perspective about customer problems, while product managers can gauge whether the ideas align with the business goals and developers can assess whether ideas are feasible to implement.

    At Optimizely, I encourage my team to brainstorm several big bet ideas on a quarterly basis and discuss whether these ideas are new offerings we need to build or buy or whether we can build on into our current offerings. This collaborative process gives the product, sales and developer teams insight into what other teams are thinking about and encourages all of the teams to put their heads together to experiment with new ideas. Recurring brainstorm sessions that incorporate recent trends will ensure the team stays agile.

    We also have a collaborative product feedback process that allows go-to-market teams to suggest features to the product team at any time and have a conversation around the business benefits of feature delivery. This is accomplished with pods of product areas comprised of product, design, engineering, product marketing, success and sales. The members of the pod meet weekly at standups and biweekly at product reviews to ensure alignment between what is being built and what the go-to-market teams are hearing from customers and prospects.

    Shop Around Your Proof of Concept and Be Ready to Course-Correct

    Product development isn’t a one-and-done process. It requires building minimum viable product, collecting feedback and revising. At Optimizely, we try new ideas and first get feedback from our internal teams and around five trusted customers to start. We implement their feedback and updates before rolling the feature or product out with a slightly larger subset of beta customers, around 20 or 30. With even more feedback, we continue to improve and build on the product, rolling it out to larger and larger customer groups under beta before making it generally available.

    As feedback is collected, it’s important to bring our cross-functional teams together to analyze the comments and bring their different perspectives, whether it be customer-centric or developer-focused. We have to be willing to accept the feedback we get and make changes based on it. A recent example is when we rolled out Optimizely X Experimentation, which was built with reusability in mind to overcome some of the issues of Optimizely Classic. While this was a worthwhile goal and customers wanted reusability, we ended up overcorrecting and having to build new workflows after the fact. These ended up looking more like Classic and were more user-friendly but less reusable across experiments.

    Hire Product Managers who Prioritize Trust and Transparency

    People underestimate the importance of getting along with your colleagues and building trust with them. That doesn’t mean you can’t disagree or have different approaches. It simply means you’ve established trust and open communication—and you’re open to hearing and considering these differing opinions. These two elements are key for staying agile and quickly adapting to industry trends. You often heard the phrase “strong opinion, weakly held” at Optimizely, which encourages lively debate.

    At Optimizely, we evaluate trust and transparency by having engineers and marketers interview prospective product managers to make sure the candidate can build trust with different teams and see pain points and priorities from various perspectives. During the interview process, it’s equally important that people acknowledge their mistakes and are able to learn from them. If a candidate can’t think of a mistake or explain what they learned from one, they likely aren’t taking enough risks or reflecting on their failures. Opening up about failures creates trust that leads to better teamwork and ultimately better business decisions.

    Ultimately, we can all take a page from the DevOps playbook to make trust and transparency a priority on our teams. Those who do will see new business ideas flourish and team members work in a more cohesive way.

    About the Author / William Gradin

    William Gradin is the VP of product management at Optimizely and is responsible for building the Experimentation Platform to help businesses boldly test their assumptions and respond more quickly to ever-changing market dynamics and customer expectations. Prior to joining Optimizely in 2015, Will worked in Product Management at Salesforce, where he owned the Platform teams for the Salesforce Communities product. Connect with him on LinkedIn.

  • How IT is More Like an ATV Than a Sedan

    How IT is More Like an ATV Than a Sedan

    There is an analogy for IT being like a car and it often goes something like this:

    IT should run like a well-oiled machine. I don’t get in my car and think about how it works, I just work some controls and it does what I need it to and it goes where I need it to go. No assembly required!”

    When people think IT, it seems they’re hoping for their IT department to work like a Tesla luxury sedan that drives for you. They like to think of IT in this “it should just work” kind of mentality. The internal dialogue of some may be, “I have this goal, IT is this tool to get it done, and I have paid for it! It should just work by itself! Heaven knows, I have spent enough on it!” They want something that’s comfortable, doesn’t require much interaction and gets them where they need to be.

    The problem with the sedan metaphor is that sedans are not really what companies need.

    Sedans are built for paved roads, made to go to places that others often go. The average sedan can’t really explore much else other than what is well-paved and well-traveled by others. They’re a comfortable ride for drivers who want all the amenities of the home wherever they are. Anything too far off of the beaten path and the car is being torn to pieces by the rough terrain. Sedans perform consistently and reliably in consistent and reliable environments.

    This is not to say that IT should not be reliable. By all means, IT has to be reliable. If IT isn’t operating reliably, much like a broken car it should either be fixed or replaced. Why would anyone pay for something that can’t perform the tasks you need it to do?

    However, organizations know they have to take calculated risks, and the larger the risk, the larger the payout. This means going into unfamiliar territory and going down paths that are not mapped out. Even a Tesla is going to struggle over terrain that isn’t already mapped out.

    On top of that, we know customers and technologies are constantly changing. There is very little consistency from the world outside of the enterprise. Every day brings new fluctuations and challenges that companies need to anticipate and adjust to.

    So why do we expect IT to behave in a consistent way when the environment around us is constantly shifting? We can’t act as though our business can succeed riding around in a comfortable sedan! We need something that can be flexible and can still move us forward.

    Think ATV, Not Sedan

    The ATV fits this kind of unpredictability perfectly. ATVs can adjust to a variety of terrain. They don’t need paved roads nor beaten paths. They can go almost anywhere and can get there quickly. These machines are rugged; they can adjust to a variety of terrain and, most importantly, they can go anywhere—if the driver knows what they’re doing.

    But ATVs are not comfortable. An ATV takes knowledge to drive and it takes engagement. One can’t sit back disengaged and hope to have a smooth ride on an ATV that is going full speed. The places these machines are made to go are not for the complacent or for those seeking comfort.

    The business-IT relationship should look more like an autocross driver and his ATV than a suit in a Lexus. In this analogy, both machine and driver are adjusting in unison to the environment around them. The driver (the business) guiding the ATV (IT)  where to go and pushing through hills, mud and dirt to make sure both arrive safely and quickly despite the dangerous and uncertain environment around them. At the end, the driver and his machine will have pioneered places many feared to tread and will be rewarded appropriately.

    To extend the analogy, this is not a problem only between business and IT; this is the same attitude Dev often takes with Ops. Dev says, “Here’s a build, your environments should be good enough,” and Ops is expected to just make it work. Isn’t this the same disconnect as the IT and the business?

    It is so important to collaborate in a large enterprise. It takes investment of not just money but also time. If we have an agile team with no product owner, we essentially have a car with no driver. If we have Devs who don’t talk Ops, don’t we have a car body with no engine?

    In today’s world of Agile and DevOps, the companies that build that bridges between Devs, Ops and the business are the ones who take the calculated risks and succeed. These companies win bigger market shares and know confidently what their customers need. They can experiment fast with different business ideas, use the latest and the greatest technology and not comprise on security. These same companies can leverage their IT function to accurately monitor spending while minimizing waste.

    When businesses interact with IT, they shouldn’t just toss something at them like an external vendor and expect quality. Collaboration and engagement is the key. When all the necessary members in an organization are talking, communicating and engaged with one another, then we begin to see the true power of IT.

    The power of IT is the ability to go over terrain that would destroy other organizations. It is the ability to set any vision and know that your people will have the tools to tackle whatever comes their way. It is the ability to adapt, change and continuously improve while watching organizational goals become reality.

    About the Author / Caleb Wolfe

    Caleb is an IT professional with a passion for DevOps and transforming the way IT organizations work. As a member of Delta Air Lines, Caleb has a variety of experience from working as a baggage handler, business analyst, software developer and as a technical analyst in IT transformation. Caleb uses his multidiscipline experience to identify and remove constraints, create effective throughput and work to break down barriers both internally and externally. Caleb is a perpetual student of process improvement and IT technology and uses his knowledge for the betterment of Delta’s employees and customers worldwide.

  • In DevOps, Speed Isn’t Always the Point

    In DevOps, Speed Isn’t Always the Point

    The high-tech industry has fallen into a rut and seems to be struggling to get out of it. This rut is most fervently seen when talking about DevOps, but it exists across the board.

    We’ve fallen in love with the idea that faster is always better. That idea is provably false, and the assumption that everything needs to be faster is false, also.

    Early on, time to market and increased responsiveness to user needs were the driving market differentiators for agile development, DevOps and DevOps tools. There were indeed cases where IT was not responsive enough to business needs—I think most of us were acutely aware of this issue, so dwelling there for a while was not a terrible thing. But responsiveness to business needs is one piece of a much larger puzzle. And we seem to be stuck, with some lip service paid to other strengths of DevOps … as long as it’s still delivered yesterday.

    In my career I’ve worked in two industries where speed of delivery was a tertiary concern for core business systems. To be blunt, when you are putting together a system that will administer contracts expected to last a hundred years or more, you really don’t get that worked up about it being out there tomorrow and “good enough,” you worry about it being right when it does go out, so you’re not still paying for mistakes a century from now that were made by rushing today.

    Of course, there are vendors that don’t want to hear people like me say these things. Of course, there are products with other benefits that are more important than speed of delivery. But as an industry, we’re still too obsessed with speed.

    How we too often see priorities

    Most industries do not even fall into a neat category where they are all or nothing. For most, some teams need to be fast, using agile, CI/CD and fully automated deployment to drive out changes fast (not as fast as some talk—most don’t even need weekly, but fast, nonetheless), while other teams need to be more thorough and cautious and the cadence of releases really doesn’t matter as much as the final result.

    So my advice is similar to advice I’ve offered on similar “hot” topics for the last decade or so:

    You are the rock stars.

    No vendor, analyst, pundit or author knows your vertical market, organization, environment or team the way you do. Do not let them proxy their view of what is “right” over you. Yes, far too many act as though, “If you’re not doing X, you’re behind.” But again, you can look at your industry and get a better grasp of what the definition of “behind” is than someone talking in generalities.

    Know what you need, know what is most important, know how to get to what you need. Don’t do what “everyone” says you should.

    But don’t dismiss the need, either. There are other benefits to these technologies that we have only recently started discussing. Infrastructure as code is an astounding way to transfer knowledge should something happen to critical people, for example. You just have to choose the technologies for the right reasons, and what the right reasons are is dependent upon the organization, not what Vendor Y is selling today.

    We’ve come a long way, and are on the cusp of some very cool stuff, but make sure you know what you need, and how to get it, then keep doing your magic.

    — Don Macvittie

  • Bucking Bank Bureaucrats: From Convergent Thinking to Divergent Doing

    Bucking Bank Bureaucrats: From Convergent Thinking to Divergent Doing

    As customers, longstanding and new, the way we interact with banks and manage our personal spending, borrowing and saving is experiencing drastic change. New digital offerings in the form of apps and online banking show commitment to customer centricity, but overall, banks are slow to adapt to the pace of change. The vast majority of bankers do recognize the strategic need to respond to their industry’s digital disruption, and are busy assessing and developing transformative technologies such as mobile, blockchain and artificial intelligence, trying to find an emerging market need and a robust business model.

    How Should Banks Adapt?

    The operating environment of banks is unpredictable and, therefore, requires organizational agility. This agility requires a careful analysis of customer needs and (potential) capabilities. Bankers must ask, “How can my bank move from convergent thinking to divergent doing?”

    picture1

    From a strategic perspective, it’s essential to understand whether the person/organization wants to be a disruptor, innovator, ideator or bureaucrat. This differentiation defines the right strategic options available to them.

    N.B.: A quick proxy answer to the above question is the design of the bank’s reception and organization of the people working there, to see if it is like every other bank, or is in some way distinctive.

    Value Triangulation and Differentiation

    Every banking CEO needs a clear strategy that addresses their organization’s internal and external challenges. There is one global commonality for a strategic foundation: Every bank needs to deliver change rapidly and frequently. The better a bank is at improving customer experience, the more likely it will survive the onslaught of disruptors and innovators. Additionally, most banks must deliver cost reduction and drive income. Customer desire, the third corner of the triangle, is not a familiar banking concept, but a successful value triangulation delivers customer desire in the most efficient way possible.

    picture2

    This isn’t about value chain mapping and cost re-engineering; it’s about creating great customer experiences with adaptive capabilities and capital-light business models. All three values must be understood and practiced throughout the entire organization, especially among boards, chief executives and key decision makers to make adaptive banking possible.

    Customer Experience Comes First

    A culture of centralization, product-centricity and control-via-process stifles change. To be adaptive and create their own Digital DNA, banks must form new work spaces and ways of working. When bank employees don’t use their own company’s products, they are out of touch with the customer experience. They also may excuse customer complaints based on their organizational knowledge. Employees need to be the bank’s most critical customers, and ought to feel fully connected to other customers and their experiences.

    New, lean business models should flow through the organization and align to the desired customer experience. The business leaders who identify the “priority customer experience features” will focus the organization on accelerating delivery momentum. Rather than requesting large-scale, product-led programs, leaders need to focus on continually launching and redefining small-scale features.

    picture3

    Doing so moves away from the grand strategies or silver bullet approach so often prevalent during annual planning cycles and shifts toward agile, customer-centric strategies. Organizational change is fundamental for creating adaptive banks with Digital DNA.

    Fail Fast, Succeed Even Faster

    To accelerate growth, adaptive technology architectures and agile software delivery methods need to be available to deliver the relevant features. A “deliver, measure and learn” approach will amplify feedback across the organization to drive commercial decision-making. This will allow banks to fail fast, yet succeed even faster. The ongoing cycle—ideating, designing, building, shipping, measuring, learning and (of course) adjusting customer features—needs to become the norm.

    By becoming adaptive, the bank’s capabilities (people, methods, technologies, values) become more attuned to customer needs, making it far easier to deliver personalized offerings. For example, the bank’s data can be used to create feature personalization, allowing customers to pick and choose the right features for their needs. A customer should always be able to overwrite the choice an algorithm provides.

    Innovation, Transformation and Beyond

    Currently, the most apparent transformation desire and delivery exists in IT departments as opposed to business departments. Agile ways of working are often still alien to most bankers in product, finance, compliance, marketing and front-line teams.

    The banking playbook has already been rewritten for the digital age. It’s an exciting time to realize great change and how disruption/innovation can become commercial reality—this means bucking the system.

    About the Author / Darren Oddie

    Alistair Bayliss

    Darren Oddie is strategy director at Wipro Digital, where he works with global financial services companies on digital transformation and innovation. He’s had hands-on experience of designing and building financial services brands from a blank sheet of paper to industry leading propositions in both corporates and startups. He’s delighted that banking and customer experience are now regularly mentioned in the same sentence. Connect with him on Twitter.

  • Last-Mile DevOps: How to Keep Employees Happy

    Last-Mile DevOps: How to Keep Employees Happy

    Chances are that your company is embracing DevOps to make sure you can get fresh, new digital capabilities to your customers ASAP. That’s because in today’s market, you either have to be first—or quickly close any gaps between you and your more digitally innovative competitors.

    But when it comes to getting new capabilities into the hands of your own employees, things probably move much slower. That’s because your internally facing apps have to clear a hurdle that your customer-facing apps don’t: administration of access privileges that often are poorly defined and inadequately automated.

    That’s a problem. People can’t be productive if they don’t have access rights for the IT resources they need, when they need them. The growing Millennial workforce is going to be especially unhappy if IT is slow to meet their digital needs. And from a security perspective, slow administration of access privileges is also a problem—because your company must be able to automatically and immediately revoke employee access privileges the moment they’re fired or they quit.

    This automated, accelerated management of internal users’ access rights is the missing “last mile” for DevOps. And it’s something you have to address if you’re going to fulfill the needs of the business with the same excellence as you fulfill the expectations of your customers.

    What Makes the Last Mile So Tough?

    If you bank with Chase or ride with Uber, your access to your personal data is gated by your personal login. But, as a customer, you essentially use the same app as everyone else.

    Application privileges within your own company are entirely different for two reasons:

    • Privileges for your internal workforce are much more complex than for customers. Salespeople have sales apps. Your finance department uses finance systems. Your service reps may be allowed to see RMA numbers, but not SSNs. So you must quickly give each person access to only the resources appropriate to their specific role and responsibilities—or risk consequences that include lost productivity, security breaches, compliance failures and excess software licensing costs.
    • Management of internal privileges is an ongoing activity. Productivity, security and compliance demand that you provision each user account for each application with the right privileges at the right time. Privileges must be immediately and appropriately modified every time an employee is promoted or transferred. Privileges must be terminated immediately when someone leaves your company. Privileges may also have to be temporarily modified in real time due to session context—such as use of non-secure public WiFi or an access attempt from a questionable location or at a questionable time.

    Simply put, for internally facing apps, getting code onto a production server isn’t enough. You also need to automate and accelerate management of the “last mile” between servers and employees.

    What Are ‘Last-Mile’ DevOps Requirements?

    DevOps toolchains automate and monitor the software life cycle from design and development through testing and deployment on a production server. What’s missing is automated provisioning and governance of the “last mile” between the server and the individual worker.

    These tasks include:

    • Capture of current user role/responsibility profiles from HR
    • Provisioning of application-specific accounts with profile-appropriate privileges and controls
    • Self-service inputs from authorized LOB managers
    • Detection of session context (network connection, time of day, location, etc.)
    • Real-time modification of privileges based on that session context
    • Automated revocation of access privileges upon termination, transfer, etc.
    • Employee self-service for permitted optional applications and services
    • Monitoring and reporting on employee account activities and events

    Your team probably performs many of these “last mile” tasks manually. Some may also be automated using homegrown scripts. Excessive dependency on scripts is a bad practice, though. Scripts usually are poorly understood by anyone but the original writer—which makes them difficult to maintain and update over time. They also don’t typically integrate well with DevOps, HR systems or other key pieces of the app delivery puzzle. This lack of integration slows your processes down and opens the door for human error.

    Automation of last-mile DevOps makes much more sense. Automation speeds processes, reduces cost and optimizes accuracy. Integrated automation also gives you a dependable, centralized point-of-control for defining and editing policies—as well as for capturing the event logs necessary for compliance and security reporting. The right automation solution will also integrate with the rest of your operations environment (including directories, VDI, and mobile management tools) to ensure secure, reliable application access.

    Why is ‘Last-Mile’ DevOps Important?

    Most business leaders already understand why rapid rollout of customer-facing applications is so important. Unfortunately, many fail to recognize the importance of being just as fast and accurate when it comes to supporting their own workforce.

    The truth, however, is that automation of last-mile DevOps benefits your business in several important ways:

    • Improved employee productivity and engagement. Your workforce will be much more productive and more engaged when everyone has immediate access to the digital tools they need. That improved employee performance will benefit your customers as well.
    • Higher IT efficiency. The sooner you automate the many everyday service provisioning tasks that your skilled IT staff now performs manually, the sooner they can to shift their precious time and energy from routine work to higher-value projects.
    • Enhanced security and compliance. Well-defined access policies, diligent enforcement of those policies with rules-based automation and centralized logging of access provisioning activities all reduce your IT-related risks—as does immediate, automatic and complete revocation of all access privileges the moment any employee or contractor is terminated.
    • Reduced “Shadow IT.” When IT is more responsive to people’s needs, they are far less inclined to turn to alternative digital resources that aren’t properly monitored, governed or secured.
    • Greater business agility. M&A, reorgs and other organizational moves are chronically bottlenecked by manual execution of mass changes to the workforce’s digital access privileges. Rules-based automation of last-mile DevOps eliminates this agility-killing process friction.

    The bottom line: To achieve true digital agility, your company must automate the “last-mile” tasks that give your people access to the IT resources they need—when they need them.

    About the Author / Stacy Leidwinger

    stacy-leidwingerStacy is the VP of Products at RES where she is responsible for defining overall product direction, roadmap and positioning, to drive product excellence, company growth and customer success in the areas of end user computing and security. Her background is in both product marketing and product management helping to positioning B2B software companies for growth and market leadership. Prior to RES, Stacy led the product management team at Directworks, a cloud-based sourcing and supplier management solution. Before Directworks, she managed the roadmap, product positioning, and go-to-market strategy for Vivisimo, an enterprise search solution, which was acquired by IBM. While at IBM, Stacy was responsible for the integration of Vivisimo’s product line into IBM’s big data portfolio. Connect with her on LinkedIn / Twitter.

  • Mainframes and the Myth of Bimodal in DevOps

    Mainframes and the Myth of Bimodal in DevOps

    Rewind 20 years ago when we lived in a business world where big companies with unlimited resources beat out smaller, more strapped companies. The digital era—also known as the “age of the customer”—is changing all that. Where big once beat small, fast now beats slow. The DevOps approaches of startups often make them more adept at continuously delivering the innovations and conveniences that earn customer raves. Bigger, established companies often feel disadvantaged‚ shackled by an outdated culture and inflexible processes that haven’t kept up with the pace of change.

    Gartner coined the term “bimodal IT” as a way for older IT establishments to keep pace with agile startups. In the bimodal model, IT teams are separated into two distinct styles of work—one focused on supporting predictable, well-understood workloads with legacy systems and another that is more fast-moving, experimental and adaptable in meeting users’ constantly evolving demands and flourishing digital expectations.

    But the bimodal concept is not well-aligned to the spirit of innovation underlying modern application development and delivery. This is especially true for bigger organizations using mainframes. Here’s why.

    Successful DevOps Depends on Mainframe Agility

    The goal of DevOps is to roll out high-performing software and updates, ahead of the competition and with maximum speed, ease and cost-efficiency. In a DevOps model, software delivery can only happen as quickly as the slowest team. Modern web and mobile applications tend to span multiple platforms in their end-to-end transaction—from front-end web servers (systems of engagement) all the way back to mainframes (systems of record). IT places a lot of emphasis on systems of engagement, often taking back-end systems of record for granted. The reality is, the value in systems of engagement cannot be realized without the systems of record—making it essentially all one system. Developers supporting modern applications must be able to maneuver across and between all platforms, especially within mainframe code and data.

    Let’s look at a tactical example of this. According to industry research, 80 percent of the world’s corporate data—including customer data—continues to reside on mainframes. When a mobile web application is used to make a bank deposit, or purchase a product, for example, the transactional component of those applications typically is executed on back-end mainframes.

    This means mainframe applications are crucial to development efforts. What happens when mainframe developers and testers are locked into waterfall processes or don’t have the modern tools necessary to understand application logic or access mainframe data for testing? Frustration mounts and the overall innovative effort is unnecessarily stalled.

    Stability and Agility are not Mutually Exclusive

    The longstanding myth that stability and agile cannot co-exist is simply untrue. Unfortunately, it’s at the core of negative perceptions surrounding the mainframe today—people think the mainframe environment is too slow and cumbersome to support agile development. Development teams may think if they have mainframes, the only approach it can support is waterfall.

    The reality is, though, no customer will accept poor availability and performance in exchange for new features delivered quickly.  People with hands-on experience painfully understand that slow, waterfall delivery methods produce far greater quality issues and missed expectations, resulting in competitive risk. Additionally, large enterprises taking the “slow and stable” route give startups a head start in beating them to market, with offerings that customers want now.

    Alternatively, Agile process and DevOps tool chains enable scrum teams to test quality in terms of usability, function and stability early and often in the development cycle—when the time to remediate is the fastest and the cost the lowest. Agile process and DevOps tool chains build higher quality applications and enable continuous improvement in quality over time.

    Re-Platforming is not Necessarily the Answer

    Some DevOps proponents believe moving off the mainframe—to a supposedly more modern, commodity server-based distributed architecture—is the best way to circumvent perceived challenges to nimbleness and agility. But this is almost never the best answer. The mainframe retains its distinction as being the most powerful computing platform on the planet. It remains deeply embedded in large organizations, setting the standard for reliability, security and availability for mission-critical data and transactions. The new IBM z13 mainframe, for example, can handle the load of 100 Cyber Mondays every day, 365 days a year. Currently, mainframes process 30 billion business transactions per day. The post-modern mainframe is an engineering marvel unequaled as a system-of-record, business compute platform.

    The mainframe also offers cost advantages. Studies have shown that the mainframe is more cost-effective than commodity servers in handling the massive computing volume increases instigated by mobile applications. This is because decreases in commodity server pricing have not kept pace with the increase in computing volumes. In addition, leading vendors have worked together to deliver intelligent cost management on the mainframe, enabling workloads to be distributed in a way that keeps mainframe licensing costs (MLCs) down.

    In our view, “biomodal” advocates for the exact problem that must be solved. We think the answer is not replacing the mainframe, although if mainframe development is left unaddressed, this can present obstacles to DevOps. Rather, the answer is to evolve the mainframe to keep up with the pace of DevOps. There are mounting examples from large, high-performing organizations that it is possible to apply modern practices to the fullest extent, including mainframe applications. These organizations do this by giving developers the tools they need to work on mainframe code and data just as they would with any other programming language on any other platform, while meeting the escalating quality expectations of the digital age. For example:

    • Mainstreaming the Mainframe Environment – Mainframe users need to move away from the antiquated “green screen” mainframe environment, adopting state-of-the-art interfaces and tools. This is the first step enabling developers to work more fluidly on the mainframe, in an environment that’s much more familiar and comfortable to them. Organizations that fail in this adoption will have a very difficult time enabling the next generation of development talent to leverage invaluable and irreplaceable mainframe code and data. This will place a huge hindrance on DevOps success.
    • Leveraging Tools from the Java Development World – One example is visualization capabilities, which enable developers to quickly and easily identify critical interrelationships between apps and data. This helps them to sidestep unintended, undesirable impacts as they modify applications, increasing confidence and mitigating unnecessary delays.
    • Make it Easier to Identify Mainframe Code-Level Issues – Developers need tools that enable them to identify problems with mainframe code; for example, when it is the source of a widespread user performance issue, or when it is consuming too many resources and driving up costs unnecessarily.

    Conclusion

    In our view, “bimodal” is not the solution, but a broken state of disadvantaged affairs for too many organizations. From a competitive vantage point, bimodal will only hurt DevOps teams and hold back the innovative efforts of the organizations they support.

    The bimodal IT model is a road to inevitable failure for those enterprises seeking success in the digital economy. This is especially true for organizations that rely on mainframes. A smartly leveraged mainframe is an extremely valuable competitive asset that needs to be removed from its silo, evolved and smoothly integrated into modern, heterogeneous development environments.

    It is possible for big, established companies to adopt DevOps, become agile, and move as fast as startups. But the ability to think and act like a startup requires some major fundamental changes, particularly at the level of software development. The good news is, the legacy technologies that are often perceived as impediments can actually be a tremendous competitive advantage, if they are harnessed and evolved in the right manner.

    About the Author / Christopher O’Malley

    chris-omalley2Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.

  • 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.

  • 5 Leadership Keys to Enterprise Agility

    5 Leadership Keys to Enterprise Agility

    Much like living creatures, organizations that can best adapt to their surroundings are the organizations that are most likely to thrive. For enterprises, that means being able to adapt swiftly to business and market conditions—and at the very least adapt more swiftly than their competitors. For years, building an agile enterprise has been the focus of the C-suite and the boardroom. Yet, regardless of so much attention and despite the potential agile payoff, according to this McKinsey & Company study, relatively few organizations can maintain above average capabilities when it comes to maintaining agility while also maintaining stability in the organization.

    So how does an organization move from being rigid and unresponsive to changing market conditions to be more agile? It all starts at the top, and we’ve detailed some of the steps below. The five keys below are not meant to be all-inclusive, but a starting point for a team, business unit, division or enterprise:

    Leadership must make the commitment to build an agile organization

    When it comes to initiating an agile digital enterprise, building agility by focusing only within IT or development teams just isn’t enough. The commitment needs to come from the top, or any gains toward building a sustainable agile enterprise are going to be short-lived. Because change is difficult, and many people inherently are against any kind of change, sustained executive leadership is essential to push forward.

    Sell the transformation

    Because any kind of substantive organizational change is painful, it’s going to cause a lot of individual and organizational discomfort, conflict and arguments. The rest of the company needs to know why they are putting in the effort, and what the goals and designed payoff will be. To get universal buy-in, this requires sustained leadership and the setting of common goals, the aligning of interests and the accepting of feedback from the teams and incorporating what makes sense as efforts move forward.

    Remove barriers to agility

    Sometimes bureaucratic red tape is the biggest barrier to change. It’s not that all bureaucracy is automatically bad. It’s not. Bureaucracy often is put into place to protect the organization from some type of risk. An example could be something as simple as requiring sign-offs to provision new users to enterprise assets. Of course, this is important to protect the organization from fake user accounts being established, or users getting more privileges than they should be entitled. But something this simple and well-intentioned, when not done right, can create tremendous barriers to moving quickly: A user needs an executive sign-off to be added to a certain resource, but that necessary manager may be on vacation for a couple weeks.

    Not good. But there are always ways to work through these barriers, if only a little effort is put in.

    Rather than wait for a week in such instances, if the organization established an alternative sign-off to approve the new resources, and a notification is automatically sent to the vacationing manager for review later, the proper workflow is maintained without time lost.

    A simple example, for sure, but most enterprises are loaded with such instances. Add a few similar hurdles in a new initiative, and agility gives way to rigidity. Whenever possible, automate away and improve the processes that create friction.

    Deliver value with immediate, tangible wins

    Nothing feels better than setting goals and achieving them. At the beginning of the journey, hitting these goals will create momentum—and the more success, the more momentum. Measure the improvements that can be identified in the new ways of doing things and showcase the results. These results, plus moving more quickly and making peoples’ lives easier in the long run, will help to flip non-believers into believers.

    Continuous improvement

    Of course, by measuring results and showcasing successes failures and disappointments will be uncovered. (No, really, they will!). And when guiding the enterprise through rapidly evolving market conditions, there certainly are going to be efforts that don’t go as planned. Too many organizations tend to recognize their wins and shuffle the losses and missteps under the carpet. It’s important to flip that around and encourage team members to point out what isn’t working so that it can be improved.

  • Redefining Product Value in the Continuous Economy

    Redefining Product Value in the Continuous Economy

    The internet is now more than 20 years old. It’s older than my kids, which is a scary thought. It’s older than Kendall Jenner. It’s older than Uber, Grey’s Anatomy and the iPhone. And so now, after more than two decades of software and e-commerce, it’s high time we take stock of where consumers really are today.

    First, consumer expectations are shifting dramatically. The digital world has brought a whole host of changes in how people work, shop, interact and engage with businesses.

    Second, the notion of brand loyalty has dissolved, shattered beyond recognition.

    And, third, this utter lack and loss of loyalty puts companies at an insane disadvantage. We’re living with a “see you later” digital mindset, where it’s easy to say goodbye to something you know online for an opportunity with the newest, next-best thing.

    All of this means that companies must deliver a constant stream of software that is fluid, flexible and competitive to gain and retain customers.

    It also means that companies absolutely must understand how consumers weigh and determine product value today, because, quite clearly, buyers aren’t making product choices in the same ways anymore.

    Indeed, 20 years ago, customers chose products based on product features. Today’s modern consumers are continuously looking for new products, embracing them and then discarding them for something even more new. In fact, the willingness to switch is so strong, according to Harris Interactive, that 86 percent of consumers quit doing business with a company because of a single bad experience. And 90 percent say they would be willing to pay more for the same product if they received a more positive purchasing experience.

    This continuous process of discovery, adoption, discarding, discovery, adoption, discarding, discovery, adoption and discarding tells us—very loudly and unequivocally—that value isn’t in the actual product itself, but in our ability to continuously evolve the product.

    Shifting Consumer Expectations Require a Continuous Approach to Business

    If you can’t continuously transform the way you deploy your product, people and processes, there’s no way you can keep up with customers’ “see you later” mindset and their continuous discovering, adopting and discarding of products.

    Two decades ago, for example, you chose a car based on ideal product characteristics (make, size, etc.) and how much you could afford to spend. Your choice would live with you while you paid it off or until you could justify changing it.

    Now, software and the speed of innovation have allowed consumers the opportunity to make product choices at a greater frequency. Instead of only getting the newest features when you buy a new car every 10 years, car operating systems are updated wirelessly and provide the latest and greatest features to existing owners, without the need to buy a brand new vehicle. The car has become a software platform.

    Even the physical choice of platform (the car itself) is beginning to change. For those who wish to change their car regularly, there are many services (such as Zip Car) that allow you to rent access to a car and return it when you’re done. Or even not to drive at all, with the advent of software companies such as Uber and Lyft.

    Obviously, each product—software or otherwise—must have a set of threshold features, or else consumers won’t choose it. A car, for example, needs to be waterproof with airbags and ABS brakes. And a task app needs to allow you to add appointments and meetings to your calendar. But to be competitive today, products must now also include the ability to switch away from features and add new ones seamlessly.

    Value is Driven by Option

    This “optionality” drives product value in what has become the ‘continuous economy’ of 2016. Companies can deliver “optionality” only by eliminating barriers from their production processes.

    Companies need to adopt product development processes that are lean and high velocity to provide customers with an ongoing series of new product features and choices. That’s why you need to continuously deliver and continuously change your software.

    Keeping Pace with the Acceleration of the Continuous Economy

    If you can’t—or won’t—continuously transform innovative software products and the way you produce them, you won’t be able to compete in today’s quicksilver-fast marketplace.

    Or, to put it more broadly, software, as well as the organization and its people and processes, must be able to pivot with agility in what seems like a nanosecond to keep pace with the acceleration of the continuous economy.

    This is all very different than what we’ve experienced in the past.

    Two decades ago, an organization confronted a new competitor or change in the market, by developing and deploying new operations, organization adaptations or products to meet the challenge.

    Today, software is the primary route to market, so companies must continuously develop and deploy new software as part of an always-transforming organizational culture. If you’re unable to develop and deploy on a sustained basis in today’s continuous economy—if you only transform on a selective basis—you won’t be in business very long.

  • Hello, Security. Meet Agile

    Hello, Security. Meet Agile

    Illumio Chief Commercial Officer Alan S. Cohen recently wrote in his blog, “Go, Slow and No: Bringing DevOps Speed to IT Security,” “There are reasons why security and risk professionals often react with a ‘no.’ When you are tasked with assessing and reducing risk, going fast might not be the first instinct.”

    Many InfoSec practitioners adhere to accreditation and certification programs such as ISO27001, SSAE-16 SOC and PCI compliance. This ultimately means they follow strict policies and procedures for software development. These procedures go through many gates, including risk analysis, design and code reviews, penetration testing and ITIL-based change-management processes. InfoSec teams live in a world where they have to plan their changes months in advance, and this world often is in direct conflict with agile development and DevOps concepts.

    Agile is all about focusing on flow and end-to-end cycle time, releasing very small changes fast, early and often. It’s not about the number of things in each sprint, but rather what’s needed now for MVP and iterating. For agile and security to be in alignment, there needs to be a fundamental shift in the principles and values that enable the business over governance and process.

    In particular, security:

    • Embraces some uncertainty. You will never build a perfect piece of software. The key is to build guardrails and to have the required adaptive enforcement and monitoring in place to capture and correlate metrics that help you quickly respond, evaluate factors of compromise and leverage your deployment automation to remedy risk exposures quickly.
    • Is part of the project team, either embedded or as an adviser. There must be a dedicated resource that understands the team’s mission of delivering value. Somebody on the team should be wearing the security hat, helping to guide each project.
    • Is a risk adviser inside the organization. Don’t compartmentalize information. There needs to be a culture of trust, sharing and transparency about potential vulnerabilities to the service.
    • Trusts the decision-making of engineering teams. Informed and capable engineers aren’t reckless with security decisions.
    • Is part of everything. It’s the design of the entire service and therefore is the responsibility of the entire team, not just the security team.
    • Improvements do not add complexity to the user experience. Security that degrades the user experience will force people into insecure practices.

    Bringing Agility, Security Together

    Embracing agility and DevOps opens the door to new possibilities that can improve security posture without hindering the business. Security will quickly discover a new set of best practices:

    • Look to microsegmentation software that is adaptive and intelligent, to replace manual management of firewall rules and policy.
    • Decouple security from the infrastructure to gain a continuous enforcement pipeline that adapts to new hardware, with strong versioning that proceeds in lockstep with product releases, monitoring and infrastructure configuration.
    • Build security into the service stack; don’t bolt it on afterward.
    • For change auditing, don’t rely on the change management database alone. This is highly prone to error and discrepancies. Look at the the git history integrated with the automated deployment system. Change management databases should be integrated with the git pull requests and commit logs. Infrastructure automation tools such as Chef and Puppet keep logs for unapproved change drift. Make sure those logs are being captured and reported on.
    • In the area of developer support, DevOps is enabling the self-service/self-responsibility revolution by building wrapper abstraction layers for engineering teams to consume infrastructure across public and private data centers, using interfaces such as chat to trigger administrative actions and query metadata information on their instances. These wrappers can also be harnessed to present security grading for every server instance, promoting awareness and corrective action to each individual owner. You can quantify the grade by looking at patch vulnerabilities, images used to build, inbound/outbound port rules and configuration standards.
    • For data at rest, data in motion and data in transit, everything should be encrypted, everywhere. For example, use Illumio SecureConnect to encrypt data in transit via IPsec between workloads. Automation and the right secrets-management infrastructure can enable frequent rotating of SSL certs and keys.
    • Every time you commit to the code base, run a set of very basic security tests via your favorite continuous integration tool. Use automated tests to ensure common security mistakes don’t leak to production.
    • Perform red team exercises as an attempt to gain access to a system by any means necessary. Try to mimic the same processes that a motivated attacker would follow to map out an organization’s infrastructure, perform reconnaissance at key physical installations, and then test the physical, cyber and social defenses all at once through a staged exercise.

    Security can become an enabler. It no longer has to be stuck being the department of “No.” InfoSec can now be the team-building tools and systems that enable development teams to do what they want in a secure way.

    About the Author / Alfred Garcia

    alfredAlfred Garcia oversees DevOps for Illumio, where he is responsible for all preproduction and production cloud/infrastructure engineering and site reliability. A technology and operations executive with more than 18 years of experience, Alfred is an aggressive advocate of DevOps and of deep operations and engineering collaboration, from design to code/test and release to production support.